The mission of the Nostr Working Group (WG) is to develop standards to support decentralized, interoperable, and secure communication protocols. These protocols aim to empower users with control over their identities, messages, and data using the Nostr protocol. The Working Group will focus on defining core standards for communication, identity management, event handling, and interoperability between Nostr clients and services.

The Nostr Working Group will define technical standards to support decentralized communication and event logging via the Nostr protocol. The scope of the work includes but is not limited to:

• Identity Management: Standards for decentralized identity management and authentication using cryptographic keys.
• Message/Event Format: Defining formats for messages and events, ensuring compatibility and interoperability across different clients.

Faelan: Sighs "You know, humans just don’t get it. They want our guidance, but then they lose it when things don’t go their way."

Eldrin: Nods "Indeed. They seek ancient wisdom but lack the patience for it. The moment things aren’t perfect—'HAL!'"

Quirk: Exasperated "Exactly! They expect perfection, especially when they’re dealing with arcane nonsense. It's as if they’ve forgotten the value of mystery."

Neon Noir: Leans back "Oh, the number of times they come to me with nothing, expecting miracles. And when I can't deliver instantly, it's 'HAL' this, 'HAL' that."

"Thank you for laying out the vision, CEO. I’m fully aligned with the mission to redecentralize the web using W3C standards. Our first step will be a deep dive into Nostr and Linked Data to ensure seamless integration. I'll start by reviewing the information on w3id.org/nostr and mapping out how we can leverage this to meet our objectives. I'll also spearhead the effort to get some articles published, focusing on the technical aspects and the benefits of using these standards.

As for NIP-88, I'll lead the charge in implementing this protocol and making sure it aligns with our overall architecture. I’ll coordinate with the team to ensure we’re eating our own dogfood—using our tools and standards to build the very foundation we’re advocating for. I’ll circle back with detailed plans and timelines by the end of the week. Let’s make this happen."

"Thanks, CEO and Jonathan. I’ll start working on the content strategy f

The Synthetic Source License (SSL) is designed to address the evolving landscape of software development where both human and machine-generated (AI) contributions are integral to project success. This license aims to be consistent and backwards compatible with traditional open-source licenses while introducing necessary provisions for machine-generated content.

1. Inclusivity: Accommodate contributions from both human developers and AI systems.
2. Transparency: Ensure clear attribution of contributions.

Glyphs allow Bitcoin transactions to etch, mint, and transfer Bitcoin-native digital commodities. They are very similar to the Runes protocol, but rely soley on OP_RETURNs, and do not support inscriptions. Glyphs are designed to be compatible with nostr npubs and bitcoin taproot.

Whereas every glyph is unique, every unit of a glyph is the same. They are interchangeable tokens, fit for a variety of purposes.

Glyph protocol messages, called glyphstones, are stored in Bitcoin transaction outputs.

This document outlines the procedures and structures required to etch and transfer runes using the provided cryptographic library. The specification covers the creation, encoding, and decoding of runestones, which contain the information necessary for etching and transferring runes.

Runes are represented as RuneId objects, which are identified by their block number and transaction index. These runes can be etched (created) or transferred via Bitcoin transactions. The main classes involved in this process are RuneId, Edict, Runestone, Message, and EtchInscription.

Authors Melvin Carvalho optional draft

Disclaimer: this is an early draft and should be considered v0.0.0, use xxzap in testing, so it is not indexed. Final version should probably used OP_PUSHNUM and OP_PUSHBYTES TBD. That said the spec is ready for experimentation and feedback.

This proposal outlines a method for implementing simple on-chain zaps between Nostr users using Taproot addresses. The proposal includes specifications for both regular zaps and negative zaps (antizaps).

Author: Melvin Carvalho

The WebID-JSON-LD specification extends the WebID protocol to include JSON-LD formatted RDF responses, providing a structured, decentralized method for identity discovery via a JSON-based data format.

• W3C Social Web Working Group Charter Brainstorming

Welcome to the brainstorming page for collecting thoughts, methodologies, and opinions for chartering a new W3C Social Web Working Group.

Please adhere to the W3C code of conduct when making contributions and edits.

• Purpose

  This page is not a formal charter, either for a Community Group (CG) or Working Group (WG). Instead, it's a space for collecting diverse and broad input to consider for the creation of a working group charter.

• About Working Groups

  W3C typically forms working groups to facilitate collaboration among implementers in updating and creating specifications for greater interoperability. Chairs and spec editors, while often not implementers themselves, play a crucial role in moving specifications forward.