Skip to content

Commit

Permalink
Define and describe DSNP operations.
Browse files Browse the repository at this point in the history
  • Loading branch information
wilwade authored and wesbiggs committed Jan 6, 2023
1 parent 21b6744 commit e1dde24
Show file tree
Hide file tree
Showing 8 changed files with 201 additions and 3 deletions.
3 changes: 2 additions & 1 deletion .yaspellerrc.json
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,8 @@
"Whitepaper",
"allowlist[s]?",
"announcementType",
"blockchain",
"archiveEntryID",
"(a )?blockchain",
"blocklist[s]?",
"changeType",
"contentHash",
Expand Down
5 changes: 5 additions & 0 deletions pages/DSNP/Announcements.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,11 @@ Additional duplicate Announcements MUST be rejected or ignored.
Announcements may not be deleted, but may be marked invalid by using a [Tombstone Announcement](Types/Tombstone.md), or updated by using an [Update Announcement](Types/Update.md).
For example, if a user creates a Reaction Announcement, they may remove that reaction by creating a Tombstone Announcement.

## Related Operations

* [Publish Announcement](Operations.md#PublishAnnouncement)
* [Publish Batch](Operations.md#PublishBatch)

## Non-Normative

### Duplicate Announcements
Expand Down
2 changes: 1 addition & 1 deletion pages/DSNP/Identifiers.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ Graph connections are formed through the DSNP User Id.
- MUST be a [keccak-256 hash](https://keccak.team/files/Keccak-submission-3.pdf) of the bytes of the content
- MUST be serialized as [hexadecimal](Serializations.md#hexadecimal)

### DSNP Protocol Scheme
## DSNP Protocol Scheme

- MUST always be the string `dsnp://`

Expand Down
14 changes: 14 additions & 0 deletions pages/DSNP/Identity.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,13 +19,27 @@ A user's ownership of their identity is expressed via ownership and control of t
Control entails the power to announce content associated with the identifier and
the ability to delegate permission to others to announce content on the user's behalf.

## Retirement

A user may choose to retire their identity at any time.
Once an identifier is retired, an implementation MAY remove all state data associated with that identifier, provided that an indication that the identifier is retired remains, so it may not be reused in the future.
This means that all data previously sent from the identifier, the control keys associated with the identifier, and the delegations (see next section) associated with the identifier may be removed.

### Delegation

* An owner MUST be able to delegate permission to announce on their behalf to other parties.
* A user MUST be able to revoke delegated permissions.
* Announcements from a delegate MUST be able to be verify which delegate made the specific announcement.
* Delegation revocation MUST NOT be retroactive.

## Related Operations

* [Create Identifier](Operations.md#CreateIdentifier)
* [Retire Identifier](Operations.md#RetireIdentifier)
* [Define Delegation](Operations.md#DefineDelegation)
* [Revoke Delegation](Operations.md#RevokeDelegation)
* [Add Control Key](Operations.md#AddControlKey)
* [Remove Control Key](Operations.md#RemoveControlKey)

## Non-normative

Expand Down
35 changes: 35 additions & 0 deletions pages/DSNP/Operations.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# Operations

DSNP implementations perform well-defined DSNP Operations and generate DSNP State Change Records.

## Control Keys and Proofs

Each invocation of a DSNP Operation MUST have verifiable approval of the acting principal(s) via a Control Key Ownership Proof.
The precise data type and representation of both the Control Key and the Control Key Ownership Proof MUST be defined by each DSNP implementation.
For example, an implementation might use the public key of an asymmetric key pair as a control key, and provide a proof for each operation by producing a cryptographic signature of the user's DSNP Identifier and some nonce value.

Where operations are listed as using control keys or ownership proofs as input parameters, this indicates that they should be provided in addition to those providing invocation authentication.

## Transaction Identifiers

Each invocation of a DSNP Operation should be associated with a transaction identifier. The precise data type and usage pattern of a transaction identifier is left implementation-dependent.
Transaction identifiers are useful for association of operations with asynchronously emitted state change records. It MUST be possible to associate a DSNP State Change Record with a transaction identifier from a particular DSNP Operation invocation.

## Failure Handling

Compliant implementations may respond to error conditions either synchronously, as a response to the invocation request, or asynchronously, by emitting a [Failure Record](Records.md#failure).

## List of Operations

| Operation | Optional? | Principal(s) | Inputs | State Change Record |
|---------- |---------- |------------- |------- |-------------- |
| <a id="CreateIdentifier">Create Identifier</a> | no | None | Control Key, Control Key Ownership Proof | [Identifier Creation Record](Records.md#identifier-creation) |
| <a id="RetireIdentifier">Retire Identifier</a> | no | User | None | [Identifier Retirement Record](Records.md#identifier-retirement) |
| <a id="DefineDelegation">Define Delegation</a> | no | User AND Delegate | User's Identifier, Delegate's Identifier, Set of Allowed [Announcement Types](Announcements.md#announcement-types) | [Delegation Definition Record](Records.md#delegation-definition) |
| <a id="RevokeDelegation">Revoke Delegation</a> | no | User OR Delegate | User's Identifier, Delegate's Identifier | [Delegation Revocation Record](Records.md#delegation-revocation) |
| <a id="AddControlKey">Add Control Key</a> | YES | User | Control Key, Control Key Ownership Proof | [Control Key Addition Record](Records.md#control-key-addition) |
| <a id="RemoveControlKey">Remove Control Key</a> | YES | User | Control Key | [Control Key Removal Record](Records.md#control-key-removal) |
| <a id="PublishAnnouncement">Publish Announcement</a> | no[^1] | User OR Delegate | [Announcement](Announcements.md) | [Announcement Published Record](Records.md#announcement-published) |
| <a id="PublishBatch">Publish Batch</a> | no[^1] | User OR Delegate | [Announcement Type](Announcements.md#announcement-types), [Batch Publication](BatchPublications.md) URL, Batch Publication Content Hash | [Batch Published Record](Records.md#batch-published) |

[^1]: For each Announcement Type, an implementation may support one or both of these operations. Implementations MUST document which of the operations is available for each announcement type.
23 changes: 22 additions & 1 deletion pages/DSNP/Overview.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,31 @@
# DSNP Specification
__Version pre-1.2.0__

DSNP is a social networking protocol designed to run on a blockchain.
DSNP (Decentralized Social Networking Protocol) is a social networking protocol designed to run on a blockchain.
It specifies a set of social primitives along with requirements for interoperability.
Go to [Implementations](../Implementations.md) for specifics on how DSNP is implemented on a specific blockchain.

## Overview

### What is a DSNP System?

A DSNP system is a state machine which generates an ongoing, publicly observable and verifiable stream of state change records in response to public input.
This specification defines a set of operations (the DSNP [Operations](Operations.md)) that a compliant DSNP implementation MUST make available.
For each DSNP Operation, the DSNP specification defines the data to be provided as input, the data that will be generated as output, and the state change records (the DSNP [State Change Records](Records.md)) that will be observable as a result of the Operation, depending on the input and prior state of the system.

The nature of blockchain technology means that all DSNP Operations are potentially asynchronous; that is, DSNP State Change Records need not be created immediately upon invoking a DSNP Operation, and may appear in the stream of state changes at any time subsequently.
A DSNP Operation can therefore only be confirmed to have completed successfully by observing the stream of newly generated DSNP Records.

All state changes MUST be visible to all participants in a DSNP system.
In practical terms, this means that all users of a given DSNP system exist within a single overarching social graph, and must be able to see and participate in all public discourse on the network.

Finally, to ensure decentralization, a DSNP system MUST avoid having any single point of failure (many nodes) and MUST avoid having any single entity that can override its consensus mechanisms (many operators).

### Implementation Compliance

Compliant DSNP implementations MUST document how each of the required DSNP Operations (for a given version of the DSNP specification) can be invoked, including, for example, what wire protocols should be used for discovery, authentication and operation execution, and how inputs and outputs will be serialized.
A compliant implementation MUST also specify a mapping from its implementation-specific state change data (for example, the events emitted by a blockchain) to the DSNP State Change Records that data represents.

<!--- Uncomment for pre-release changes and prefix the version with `pre-[next version]` --->
## Prerelease Changelog

Expand Down
120 changes: 120 additions & 0 deletions pages/DSNP/Records.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,120 @@
# State Change Records

State Change Records constitute the observable output of a DSNP system.
Implementations MUST specify how applications can translate implementation-specific output into State Change Records.

Each Record is associated with a transaction identifier, which allows [Operations](Operations.md) to be associated with their results asynchronously.

Records consists of one or more fields.

<!-- Raw HTML is required to do rowspans -->
<div class="table-wrapper">
<table>
<thead>

<tr>
<th align="left">Record Type</th>
<th>Field</th>
<th>Field Data Type</th>
</tr>

</thead>
<tbody>

<tr>
<td rowspan="2"><a id="identifier-creation">Identifier Creation Record</a></td>
<td>Control Key</td>
<td><i>Implementation dependent</i></td>
</tr>
<tr>
<td>Control Key Ownership Proof</td>
<td><i>Implementation dependent</i></td>
</tr>

<tr>
<td rowspan="1"><a id="identifier-retirement">Identifier Retirement Record</a></td>
<td>User's Identifier</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>

<tr>
<td rowspan="3"><a id="delegation-definition">Delegation Definition Record</a></td>
<td>User Id</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>
<tr>
<td>Delegate Id</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>
<tr>
<td>Allowed Announcement Types</td>
<td>List of <a href="Announcements.html#announcement-types">enum values</a></td>
</tr>

<tr>
<td rowspan="2"><a id="delegation-revocation">Delegation Revocation Record</a></td>
<td>User Id</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>
<tr>
<td>Delegate Id</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>

<tr>
<td rowspan="3"><a id="control-key-addition">Control Key Addition Record</a></td>
<td>User Id</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>
<tr>
<td>Control Key</td>
<td><i>Implementation dependent</i></td>
</tr>
<tr>
<td>Control Key Ownership Proof</td>
<td><i>Implementation dependent</i></td>
</tr>

<tr>
<td rowspan="2"><a id="control-key-removal">Control Key Removal Record</a></td>
<td>User Id</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>
<tr>
<td>Control Key</td>
<td><i>Implementation dependent</i></td>
</tr>

<tr>
<td rowspan="1"><a id="announcement-published">Announcement Published Record</a></td>
<td>Announcement</td>
<td><i>One of the types described in</i> <a href="Announcements.html">Announcements</a></td>
</tr>

<tr>
<td rowspan="4"><a id="batch-published">Batch Published Record</a></td>
<td>From Id</td>
<td><a href="Identifiers.html#dsnp-user-id">DSNP User Id</a></td>
</tr>
<tr>
<td>Announcement Type</td>
<td><a href="Announcements.html#announcement-types">Enum value</a></td>
</tr>
<tr>
<td>URL</td>
<td>String</td>
</tr>
<tr>
<td>Content Hash</td>
<td><a href="Identifiers.html#dsnp-content-hash">DSNP Content Hash</a></td>
</tr>

<tr>
<td rowspan="1"><a id="failure">Failure Record</a></td>
<td>Message</td>
<td>String</td>
</tr>

</tbody>
</table>
</div>
2 changes: 2 additions & 0 deletions pages/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,8 @@
- [Reaction](DSNP/Types/Reaction.md)
- [Profile](DSNP/Types/Profile.md)
- [Update](DSNP/Types/Update.md)
- [Operations](DSNP/Operations.md)
- [State Change Records](DSNP/Records.md)
- [Serializations](DSNP/Serializations.md)
- [DSNP Implementation Specs](Implementations.md)
- [Frequency](Frequency/Overview.md)
Expand Down

0 comments on commit e1dde24

Please sign in to comment.