Future supported message types

[aneyzberg]

Future Supported DSNP message types

There are several DSNP message types that are not yet currently supported but will be supported at some point in the future

Drop

A dead drop message.

dsnpData field	description	type	bloom
deadDropID	The Dead Drop ID (See DeadDrops	bytes32	YES
uri	content uri	string	no
contentHash	keccak-256 hash of content	bytes32	no

KeyList, PrivateGraphKeyList, EncryptionKeyList

A KeyList rotation.

dsnpData field	description	type	bloom
fromId	DSNP ID	bytes8	YES
keyList	new list of valid keys	bytes[]	no

EncryptedInbox

An encrypted direct message.
This describes the format once decrypted.
Possibly combine both of these and expect that all Inbox messages are encrypted.

dsnpData field	description	type	bloom
toAddress	ID of the recipient	bytes20	YES
fromId	DSNP ID	bytes8	YES
contentHash	keccak-256 hash of content	bytes32	no
uri	content uri	string	no
Tell us how to reproduce this issue.

[aneyzberg]

There are other messaging formats we considered before deciding on the format in Messaging Overview.

There potential formats that we chose not to use are described below.

Variable Announcement Format

• All actions are posted to chain with some or all pertinent information about the action
• Different information is posted depending on the action.
• Advantages
  • can index all actions without requesting off-chain data
  • can validate most actions without requesting off-chain data
  • can archive some actions without requesting off-chain data
• Disadvantages
  • more data (likely more costly up front) than a simple URI

Some other options:

• Emit no topic, have a single contract that subscribers watch for events from. Subscribers can perform filtering based on the dsnpTopic field.
• The topic is the dsnpType (possibly not an enum). Subscribers could listen for desired topics.

Unified Announcement Format

This is currently not the recommended solution, but is presented as a comparison.

• All actions are posted to the chain with some pertinent information about the action
• The same information is posted regardless of action
• The rest of the information for the action is stored off chain.
• Advantages
  • less data on chain --> lower up-front costs and lower node storage requirements
    // right to be forgotten is unclear
  • privacy management is easier -- for example, "right to be forgotten" is easier to comply with since
    data is external, off-chain.
• Disadvantages
  • indexing requires retrieving content @ uri
  • archiving requires retrieving more content @ uri
  • validation requires retrieving more content @ uri
  • cost savings may be minimal

field	description	type
topic	Ethereum log topic	bytes
action type	the type of action	bytes
fromAddress	social identity	bytes
uri	uri of stored action information	string

All data on chain

One possibility is not to have any data stored off-chain; instead, even the ActivityPub content would be posted to chain.
The disadvantages far outweigh the advantages:

• Advantages
  • Validation, indexing, discovery are much easier
• Disadvantages
  • This amount of data would rapidly slow down the network
  • The posting of illegal content could potentially shut down the network
  • Garbage collection, validation, privacy concerns, and dealing with illegal content become interdependent, and would pose conflicting interests.
  • Would still need archive to store at least some content
  • Unknown, likely chilling effect on incentive models

No data except hashes on chain

Only hashes of the events are stored on chain; everything else is interpreted via API(s)

[wilwade]

Archive.