Kevalin - Interaction Modes

Publish a document - Async public communication

A JSON document is published to a key in the DHT. It can be retrieved by anyone with the correct key.

Send mail - Async private communication

An encrypted message is routed to the node(s) closest to a mailbox ID.

Mail messages are persisted for a set length of time using the normal DHT republishing rules. The sender must periodically republish to refresh the message if it has not been received.

The recipient can retrieve the message using the normal DHT lookup algorithm by specifying the mailbox key.

The recipient can use their private key to ack the message and remove it from the DHT (acks are also registered in the sender’s mailbox to allow them to determine when their message has been received).

Proofs that the sender is permitted to send messages to the mailbox can be provided as ‘postage’ and invalid mailbox/sender combinations rejected.

Subscribe to a document collection

A collection document describing a set of other documents is published.

Subscribers to that collection participate in a routing network to exchange and broadcast updates to the collection.

Active subscribers periodically publish their IDs to the DHT.

Passive subscribers periodically query the DHT to locate active nodes to gossip with.

Share a file

Larger files can be shared by publishing the sharing node’s ID to the DHT under the hash of the file. This allows a swarm to be formed around the nodes hosting and requesting the file’s content.

Once connections are established, files are transferred in blocks as with the BitTorrent protocol. The pool of active participants is managed as a Kademlia routing table. Requests/Offers are broadcast in this network.

For sequential files such as videos, it may be desirable to request blocks in a predictable order to allow buffering.

Participation in a swarm might be protected using an encryption key (to protect the content) or an authorisation proof (to protect bandwidth and prevent unknown nodes participating in the swarm entirely).

Share a stream

A stream of data (e.g. a live video stream) could be shared by using the overlay routing table to broadcast each new chunk of the stream as it is created.

Any missed chunks (or replay behaviour) could be facilitated using the standard file sharing request/offer protocol.

It’s unknown if latency would be good enough for video calling applications, however it seems likely that this would only work with a small number of participants anyway, so latency is likely to be less important than bandwidth and CPU considerations.