Turtl p2p

[orthecreedence]

I'm putting this here for two reasons: one is to gauge interest, and the other to start spitballing ideas.

I have been thinking a lot lately about decentralizing Turtl: the federating of multiple servers so people can really own their own data. But thinking it through further, federation isn't even the most useful model. Really, the connections between instances are generally a handful of personal devices and also sharing with other people. This lends itself to a more p2p model.

In effect, I think I have this distilled down to a somewhat coherent plan (very open to suggestions):

• The p2p core would no longer sync with a server, but would sync with other nodes.
• Nodes would identify each other via public-key cryptography. An asym keypair can be derived statically using the email/password combo, the the public key of this pair would effectively be the user id.
• Nodes set up channels between each other via direct link, which can be entered in the login screen.
• The concept of headless/non-decrypting nodes kind of ties everything together. If you don't want to type your home IP address into your phone's turtl app, you can run a cloud-based instance of a turtl node that acts like a full node but never decrypts.
  • This would save the full profile locally and update it as sync items came in, allowing you to fully re-sync a new device
  • It acts as a conduit for your personal devices to share without having to leave one device on all the time or having to know your devices' IPs.
  • Supports granular syncing controls
  • Don't sync anything
  • Only sync with my devices ([enter public key here]) and shares I'm participating in
  • Sync anything anyone sends, and sync these items with any matching listening public key or share.
    • This could be the new turtl "server", a headless node that people can use as a lazy syncing/sharing endpoint.

I'm still thinking about the protocol between nodes, but I think in general it sets up some kind of key exchange:

node1	node2
hi, i'm jerry, pubkey is abc
	hai, jerry, i'm samantha, pubkey xyz
cool, subscribe to channel chan-sync-xyz
	thx, subscribe to channel chan-sync-abc

from there, each node would subscribe to each others pubsub channels (thinking 0mq might be useful here, at least to get this off the ground). from there, any changes in data would create a sync record, which is packaged as a message object:

struct MessageID {
  timestamp: DateTime<Utc>,
  pubkey: String,
  client_id: String,  // maybe not needed, but good for debugging
  nonce: u16,
}
struct Message<T> {
  id: MessageID,
  signature: Vec<u8>,
  body: T
}

Each Message is signed with the originator's private key (and verified by receiver), then forwarded to all interested parties (determining who is interested is undefined right now...public key is an easy one, but not sure about active shares...they would have to be queried, aka, activity on space X by user Y should not just be forwarded to all channels owned by Y, but all channels where X is shared with someone, and shares should store a public key that can be used to set up and encrypt a channel).

Nodes store processed MessageID for however long, and if a node comes across a MessageID it has already processed it throws it out. The storage period should line up with the amount of time that sync messages are stored, and if a client is out of sync for longer than that period, it should (after sending any outgoing sync records) re-download the entire profile.

Would love thoughts, ideas suggestions, etc. The goal here is to make Turtl work even in limited connectivity

[orthecreedence]

Main concerns so far:

• How are shares propagated? Nodes would have to advertise somehow that they can forward on behalf of <public key I am sharing with>. Now we're getting into node gossip as part of the protocol, yikes. Or perhaps we don't, and we the put the onus on users to sync their shares to the nodes handling the sharee's sync items. Seems more reasonable as a v1.
  • Could even give each user who signs up with the hosted node an endpoint (ie, node.turtlapp.com/daryl) that resolves to an ip:port that the share system can use to send the share (this type of lookup system would help in the case where we have a lot of traffic and need to partition users onto different headless nodes).
• How do we deal with files? Chunk them and sync the chunks? As always, they tend to throw a wrench into the gears somewhat.
• If pubkeys are the "user_id", and they are generated from email/password, what happens when a user changes their password?
  • Need protocol for handling a "pubkey changed" message.
  • Would need to set up new channels, possibly alias channels for some time (sync expiration period?) to allow older devices to catch up
• If we're using pubsub, it's quite possible to miss messages. Might be better to use some form of polling, ie "got any syncs after id X??"
  • Thing is, now we're getting into clocks. What happened when? According to who? Since the devices are all trusted to some extent, it might not even matter for v1, and maybe we can use the node datetime for the message id (preferable)
  • Perhaps we can re-use existing sync protocol for this somehow.

[va-an]

Wow, looks like an awesome feature, but not clear to me. Node - is a "new server"? May we consider the node as replacement for server? Or we assume that clients by themselves are nodes and can communicate with each other directly (phone and desktop as example)?

[orthecreedence]

Or we assume that clients by themselves are nodes and can communicate with each other directly (phone and desktop as example)?

Yes, exactly. Each client would be a node, capable of directly communicating with any other Turtl client/node. This eliminates the need for a server altogether.