Summary Across a wide array of decentralized app, service, and protocol scenarios there exists a need for entities to expose various interactions to the public and shape interactions that adhere to expected schemas, data relationships, and protocol flows (e.g. tbDex). The following proposal describes a mechanism for defining protocols and associated logic DWeb Nodes use to address these needs in an extensible way that covers the vast majority of app and service use cases. Motivation When thinking about apps and services as protocols, most apps and services have some aspects of interactions between participants that is open to the public and must follow certain business rules for how data is related and handled. Being able to expose open initiation of app or service flows is something you see with Twitter (anyone can reply to your tweets), credential issuance (anyone can apply for a credential), and tbDEX (anyone can submit an Ask), to name a few. Additionally, in virtually all apps and services there exist relationships between data/objects that define what objects are attached to others, and who can perform certain actions within a flow. Due to the fact both credential issuance and tbDEX require both of the technical capabilities outlined above, we need to put such a mechanism in place to enable them. Goals Enable DWeb Nodes to intake messages from the wider internet that fall within a set of protocol-specific constraints. Enable developers to define a set of messages under a given protocol definition, their relationships with each other, and the conditions for which external entities are able to interact/affect them.

ipfs.send(['/dns6/foo.com/tcp/443/https', SECOND_MULTIADDR], CID, BLOCKSTORE) ipfs.retrieve(['/dns6/foo.com/tcp/443/https', SECOND_MULTIADDR], CID) IPFS CAT Swarm.connect();

{ // message PROCESSING: { nonce: 12345..., recipient: Bob }, AUTHZ: { signer: Alice, target: Lawyer } }

Created: August 9, 2022 Status: Draft Summary Across a wide array of decentralized app, service, and protocol scenarios there exists a need for entities to expose various interactions to the public and shape interactions that adhere to expected schemas, data relationships, and protocol flows (e.g. tbDex). The following proposal describes a mechanism for defining protocols and associated logic DWeb Nodes use to address these needs in an extensible way that covers the vast majority of app and service use cases. Motivation When thinking about apps and services as protocols, most apps and services have some aspects of interactions between participants that is open to the public and must follow certain business rules for how data is related and handled. Being able to expose open initiation of app or service flows is something you see with Twitter (anyone can reply to your tweets), credential issuance (anyone can apply for a credential), and tbDEX (anyone can submit an Ask), to name a few. Additionally, in virtually all apps and services there exist relationships between data/objects that define what objects are attached to others, and who can perform certain actions within a flow. Due to the fact both credential issuance and tbDEX require both of the technical capabilities outlined above, we need to put such a mechanism in place to enable them. Goals

# Hub Specification Planning An exhaustive list of all the things members believe Hubs should support. ## High-Level Feature Areas | |Description|MVP| |:-------------|:----------|:-:| |Profile Discovery|Mechanism to expose a basic profile object|✔| |Semantic Data CRUD/Discovery|Storage and retrieval of discoverable semantic data|✔| |Action Inbox for Agents|Intake and relay messages that are prompts to do something|✔| ### Items pending assessment: - Peer DID Support: Ability to