Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

Describing relationships between various naming and communication systems #379

Open
aschmahmann opened this issue May 21, 2019 · 0 comments
Labels
Mutable Data Naming, Real-Time updates, IPNS

Comments

@aschmahmann
Copy link

aschmahmann commented May 21, 2019

Communication and naming systems are fundamentally related by the idea that in order for a set of parties to communicate they must have a particular communication channel. This communication channel has a name, whether it is explicit (e.g. #ircChannel, hash(publickey)) or implicit (e.g. Alice and Bob's bidirectional TCP channel).

To explore this more thoroughly and see how it relates to the distributed naming/communication world we'll examine the mappings between a few closely related systems.

The below thoughts are still a bit rough, but describe the layout of space of some systems that distributed application developers may care about (IPNS, Dat, SSB, IRC, Email, etc.)

Our Systems

  1. Open Chat: A system that anyone can join and post in after only referencing the chat topic (e.g. #ipfs)
    • Note: This is equivalent to open collaboration systems via the utilization of operational transform or CRDTs
  2. Open Multi-writer Naming: A system wherein any number of users can modify a shared data structure
  3. Email: A system wherein any user can message any other user and the contents of that message are only known by the participants
  4. Single-writer Naming: A system wherein only a single user can modify a particularly named data structure
  5. Closed Chat: A system where a pre-determined set of users can post messages to each other in a way that is visible to the entire group
  6. Closed Multi-writer naming: A system where a pre-determined set of users can modify a shared data structure

The Equivalences

1. Chat <-> Multi-writer Naming

Chat: We can create an arbitrary number of topics t which any number of users can then post to. Posts are not deleted.

Multi-writer Naming: We can create an arbitrary number of objects o which any number of users can modify. Traces of the modifications are not deleted.

Chat -> Multi-writer Naming

For any object o that we would like to have many users collaborate on:

  • Create a topic o for users to post to
  • Every user modification is submitted as a modification operation on a shared data structure (e.g. operational transform or CRDTs)

If the Chat system is Open then users will not require being pre-registered and therefore we can build an Open Multi-writer naming system.

Alternatively, if the Chat system is Closed then we will only be able to build a Closed Multi-writer naming system

Multi-writer Naming -> Chat

For any topic t that we would like to have many users post to:

  • Create a named object t that users can modify as an append-only log
  • Every user post is submitted as an append operation on the log

As above, if the naming system is open we can build an open chat system, but if it's closed we can only build a closed chat system.

2. Open Multi-writer Naming -> Email

For any user u that we would like to have many users be able to send messages to that only u can read:

  • Create a named object u that is an append-only log associated with a cryptographic public/private key pair (u_pub, u_priv)
  • Whenever a user s wants to send a message to u they create an append operation with their message in it that is encrypted with u_pub

3. Open Multi-writer Naming <-> Email + Single-writer Naming

Email + Single-writer Naming -> Open Multi-writer Naming

For any object o that we would like to have many users collaborate on:

  • Whenever a user u_i wants to join the collaboration:
    • Have u_i create a single-writer object o_i
    • Have u_i create their own composite object C that incorporates all the changes of each of the o_j
    • Have u_i discover all of the other u_j and send them an email notifying them to add o_i to their local copy of C
  • Whenever a user u_i wants to modify o they create a modification operation and put it in o_i

Note: there is an assumption here that the u_i can discover the relevant u_j, in some circumstances this could occur within the context of the email + single-writer systems or might be a separate system. At worst this makes the equivalence Email + Single-writer Naming + Discovery <-> Open Multi-writer Naming, since a Key-Value Store Open Multi-writer Naming system could be used for discovery.

Open Multi-writer Naming -> Email + Single-writer Naming

Open Multi-writer Naming -> Single-writer Naming

For any object o that we would like to have many users, u_i, read from and only 1 user, Admin write to.

  • Create a named object o-mw that is associated with a cryptographic public/private key pair (Admin_pub, Admin_priv)
  • Whenever Admin wants to modify o it publishes a modification operation to o-mw and signs it with Admin_priv
  • When any of the u_i want to see the latest state of o they read the state of o-mw rejecting any changes that cannot be verified by Admin_pub
Open Multi-writer Naming -> Email

Described above

4. Single-writer Naming -> Closed Multi-writer Naming

For any named object o that N predetermined users would like to collaboratively modify:

  • Have each of the N users (designated u_i) create a single-writer named object o_i
  • Have each of the users create their own composite object C that incorporates all the changes of each of the o_i
  • Whenever a user u_i wants to modify o they create a modification operation and put it in o_i
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Mutable Data Naming, Real-Time updates, IPNS
Projects
None yet
Development

No branches or pull requests

2 participants