Multiple device support

[pfrazee]

Presently, users can't share keypairs between devices, because doing so risks publishing two messages with the same sequence number, which is a feed-corruption event.

Because identities are connected to keypairs, this forces users to create multiple separate identities. How can we solve this?

[pfrazee]

The "Aliased Keypairs" solution has the user produce new keypairs for each device, and then have the keypairs' feeds announce equivalence with each other. A would announce I am == to B and B would announce I am == to A. SSB programs would then treat the two identities as equivalent.

Problems with this:

• Messages encrypted for a user will need to be encrypted for each keypair.
• Multiple identifiers for each user, increases complexity.
• May cause glitches as the aliases propagate in the network, and not all nodes are aware of all aliases.

[pfrazee]

The "CP Devices" solution has the user copy their keypair between their devices, and then have the devices synchronize before publishing new messages to the network. This way, the devices ensure they never publish a conflicting sequence number.

Problems with this:

• Requires the devices to make contact before publishing messages.
• Requires users to copy keypairs between devices.
• Seems fragile.

[pfrazee]

The "Hosted" solution keeps the keypair in an accessible server (probably a VPS). The users' devices connect to this node in order to publish new messages.

Problems with this:

• Less effective secret management, as the keypair is entrusted to the server's operators.
• Requires server-connectivity to publish.

[dominictarr]

These three approaches would all have pretty steep tradeoff. only being able to publish when you are online would work, but turn it into a client-sever protocol which isn't really in the spirit of ssb.

[ahdinosaur]

:+1: for aliased keypairs, as that also ties in with key revocation.

[pfrazee]

Both "Hosted" and "CP Devices" introduce coordination into the protocol for the first time. On the other hand, aliased keypairs complicate the datamodel quite a lot.

[wesleytodd]

I think I also like the aliased keypairs FWIW. After reading through the discussions, I can totally see why it is the most consistent with underlying principals of SSB.

What happens when a user only sees one half of the alias messages, do they then have enough information to find the other half if they dont already follow that other user? Would this result in them getting only half the users messages?

[pfrazee]

@wesleytodd an alias announcement will involve two messages, one published by each feed, linking to the other. So you'll see one of those announcements, and then your software will know to fetch the other feed. So, yeah, you'll only get some messages until you fetch both feeds.

We need to figure out exactly what aliasing means. Even with an alias, the data-model will have to treat each feed as separate, because the logs will publish in independent orders.

[dominictarr]

Our application/protocol has advanced a great deal since we first dicussed aliases, so I think what we need to discuss how aliases would affect the various features we have: follows, links, names, private messages?

[pfrazee]

In some ways, it's a good thing that different devices are different identities. I might prefer to send a PM to a friend's personal device only, and exclude work devices.

I'd expect aliases to do the following:

• Show in the interface that the accounts are aliased and should be considered the same person.
• I'd expect the profile view to show all the different aliases, and let me view their posts combined (ordered by asserted wall-times) or separated. Opening one feed should take me to the shared profile-page for all.
• Show a subname, so I can differentiate the aliased feeds (home pc, cellphone, work laptop)
• Give some info about which I should use (eg "preferred" recipient)
• (Ideally) have groupings, so I can say "send PM to all of pfraze's devices," or "send PM to pfraze's work devices."

[dominictarr]

Also, you may want to subscribe to different things on different devices. I check personal email on my phone, but not github email.

I think there is an important security edge case about how we handle old messages from another account. There are probably a variety of ways you could represent the equivalence of the two feeds and we'd need to think these all though, security wise.

handling the feeds as combined, and addressing messages to all or a subset of devices would be simple enough too.

[ahdinosaur]

There are probably a variety of ways you could represent the equivalence of the two feeds and we'd need to think these all though, security wise.

mhm, owl comes to mind. same as, supersedes, superseded by, ...

[dominictarr]

I've been thinking that since this is relatively hard, we should figure out private groups before we do this. one way groups would be useful, and pretty easy to implement.

[ahdinosaur]

@dominictarr that makes sense, as this is all part a larger question of how to represent identities, whether as an individual or a group.

[ahdinosaur]

relevant stumble: very dense paper on group signatures from Pond.

[aredridel]

Separate signing and reading keys would make this easier, would it not -- all devices have their own identity, key, but share a reading key that that is encrypted to. They can assert they're a unified identity by co-signing a statement, but still act individually.

[pfrazee]

@aredridel ah, that's an interesting idea! @dominictarr what do you think of that?

[aredridel]

It's easier to solve than group chat since the parties involved in multiple devices kinda inherently trust each other, at least until a device is compromised.

[dominictarr]

@aredridel my big concern here is that shared keys make you less secure - if you copy a key between your devices and loose any of them, you are compromised. if they have different keys, and loose one of them, the others are still safe.

It's like, you want an aeroplane where if one engine fails the plane doesn't crash. If one engine fail causes the plane to crash, you are safer to have one engine than two.

[dominictarr]

Another possibility would be to use deterministic derived keys - I need to do more research here, but there is a mechanism whereby you can "multiply" your public key by, say, hash("phone") and get a pub key for your phone, but if your phone is stolen they can't go backwards to find your root key. Although, I'm gonna have to really learn how this works, because unfortunately this is not exposed by nacl... so it would need to be implemented...

[NHQ]

I solved this riddle. They keys analogy needs to be paired with an ignition one. If you take the keys out of the ignition, that engine (ssb/sbot) shuts off, and refuses to replicate, perhaps sending a final message at shutoff so others know not to replicate.

Put the keys in another vehicle (application), and that local engine will have the rights to publish, which other engines of that key will later trust / oblige when they sync with the network.

This requires the users to own their keys, which is a good practice, and for ssb to handle sequence breaks, perhaps obnoxiously--which may prevent you from making the mistake of trying to run two engines at once again.

Also, what if you published to your peers first, instead of locally? Then your local would replicate you from your peers, which may prevent "sequence" discontinuities when you publish from multiple devices.

Finally, why does ssb need to treat any one set of keys as an identity, when it can replicate other ssb feeds based on their public key alone? The mechanism for signing and verifying lives in the crypto libs, and can be done "outside" of the databases core function.

[aredridel]

I'm late reponding to @pfraze here but delegating the choice of which device of a user's you send to to the sending user is such a rough one: that means a user has to communicate what their identities are, plus updates to that list, the context for when to use which one, and how much it matters, and prevents the case where someone starts a conversation on one device but moves mobile; smooth transition between the two is super important if you ask me.

Let the user create separate (or multiple!) identities, and separate that from devices, too. (I myself have three twitter identities; two tumblr identities, and definitely distinct work identities for email)

[pfrazee]

@aredridel I agree, devices aren't the most friendly abstraction-level for identity. It is good to have multiple idents, but only when the user asks for it.

[dominictarr]

@NHQ this is actually a pretty good idea. It's not perfect, but it is simple, and we'd be able to implement it much sooner than I had anticipated. I see two problems:

• you have to log out of one device before you log into another... this would be a surprising thing for the user, since (to them) there won't be an obvious reason why can't do that. (not such a problem for home/work/laptop, but is awkward as phone/laptop)
• you'd have to copy the private keys to your other devices.

Maybe there are ways to work around these... for 2) you could have a key that is derived from your master key, or just copy the keys, or something. 1) maybe you could have multilpe devices that connected to each other and formed a consistent group. That would only work when they are both online, otherwise you'd have to log one out.

[pfrazee]

[edit - prematurely posted, will post the full comment in a moment]

[pfrazee]

@NHQ's suggesting a "publishing lock." It can't be done manually. Transferring the lock without also synchronizing the log state would allow forks in the history.

Consistent groups require a quorum to make progress. In Raft, that's simple majority (see table at bottom). For 3 devices, only 2 would need to be in communication.

That's still not very good. What happens when:

• You take a device on the road, but forget to transfer the lock first.
• You lose the device that holds the lock.

[dominictarr]

or, one device is turned off, but the other one is on!

[NHQ]

If you fork yourself, merge yourself.

[bcomnes]

Besides the fact we can't easily figure out exactly how it works due to lack of source, Bittorrent Sync has an interested way of handling key distribution between devices for a single identity.

You essentially create an identity on your first device A, add a mobile device by scanning a QR code on device A with phone B, and then accept the pairing request on Device A.

At that point you can use the mobile device B to add device C etc. The devices are aware of all the other devices apart of the identity, and can remove devices at a later date.

I believe a central server might help out with some of these transactions, but it is my understanding the key exchange is p2p (and wont even leave the local network if possible).

I think its an interesting UX that opens up a lot of options for the underlying key exchange pairing process. Unfortunately the details are hidden :cry:

[matthiasbeyer]

Any progress on multi-device support lately?

I'd love to try this (patchwork, scuttlebutt ...not sure about terminology yet) but multi-device support holds me back.

---

I just created the liber project and just pushed notes on how to do multi-device support in my setup. Maybe that helps with your discussion?

[dominictarr]

this thread is very old, we have most discussions on ssb it self these days. We have recently funded a grant for @mmckegg to implement multidevice, so it should be coming very soon!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[chmac]

I realise this is a very old issue. It seems like there's no current solution to this in scuttlebuttverse, unless the discussion is inside the network somewhere and not visible to me (seems entirely possible).

My suggestion is a combination of the Hosted and CP Devices strategies. I keep my key, it can exist on many devices. When I want to sync to the network, I check in with my "Hosted" component (which is really just a dumb agent). It tells me what the latest network state is (sequence numbers, whatever). I can incorporate this state into my messages, update the signatures, and then publish these signed messages to my "Hosted agent".

The copying of keys obviously creates issues, as does the storage of secrets in general. I'd suggest that's a wider issue and would solve it in a separate approach. Multi-device is not the same problem as key security, revocation, etc. There's a lot of cool ideas in that space since the advent of crypto based monies, where key security becomes really, really, really important.

If there was a conclusion to this discussion and I missed it, apologies.

PS> Not sure if this issue is really "closed" just because it's stale btw.

[heyakyra]

One could study how Keybase does it — https://keybase.io/blog/keybase-new-key-model — I am keenly interested in this feature!

— @coreagile https://github.com/ssbc/handbook.scuttlebutt.nz/issues/17#issuecomment-478345036

Matrix also does client key sharing, but hasn't yet implemented a full p2p-by-default model (login requires an identity/homeserver): https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide/#key-sharing

[jedahan]

@chmac It's very possible I am missing a key piece, but I think the difficulty is that your "Hosted" agent is that it likely will have a subjective view of the world? Or are you saying 'if someone has multiple devices, only ever publish from one?'

[chmac]

@jedahan Looking back, my explanation was not super clear. I'll try to elaborate with an example scenario that hopefully makes it clearer.

• I have 3 devices, phone, tablet and computer
• I designate computer as my "master" device
• I'm writing messages offline on phone
  • These messages are written to a pendingLog instead of the standard log
• phone reconnects to internet
  • phone syncs my full log from computer
    • If computer is unreachable, then phone cannot publish
  • Now that phone is confident it has the "latest" head of my log, it copies from pendingLog to log and resigns if necessary
  • The sequence numbers might change if messages were posted while phone was offline
  • Then phone syncs the log to computer

There's some nuances here, like what to do in case of network failures while updating, etc, etc. But the core idea is that a single device becomes the "master", and it's only by talking to this device that any other devices using the same key will append to the log.

[matthiasbeyer]

And why not simply introducing merges for logs? That'd would solve all your problems here.

[chmac]

@matthiasbeyer How would merging of logs work? Is there a proposal for this documented elsewhere? My initial thought is that it would be quite a hard change, and would not be backwards compatible, but I haven’t thought about it so much, maybe there’s a better way.

[matthiasbeyer]

@chmac As far as I know, there is not such proposal. But I was suggesting it on various occasions for years now. If the "log" is a "DAG" (think git), all your problems with multi-device support are solved - the only thing you have to care about is the implementation in these two points:

• When to merge - there has to be a policy when a device starts a merge, because if you just detect diverged HEADs and merge away, you'll end up with merges all over the place. Something like "The last update on the branch that is not my current branch is more than 10 minutes ago, then I'll merge" would be an idea... but that's a detail and has to be discussed elsewhere
• What to merge - each device has to authenticate (as in the user approves) which other devices to merge - for example via QR-Code or something, where a user tells her device "Laptop" that it should merge the device "smartphone" by teaching it via QR-code.

And that's basically it. Now you got a full DAG for your "log", all algorithms for working with it are already invented and you can also easily add other devices or remove devices, because it is just authenticating the device to all other devices (and really, if you have more than 5 devices for one profile, that's really a lot and I guess not that common) or removing the authentication for a device on all others.

[chmac]

@matthiasbeyer I imagine this would be one possible approach. However, changing from a sequential log to a DAG is a pretty huge protocol change, and would not be backwards compatible. I'd assume it's much harder to implement this across the ecosystem than something which is backwards compatible...

[jedahan]

If what is published is readable by clients unaware of the change this might be fine - would love to see a PoC

[ssaavedra]

@chmac in your previous list of work, you propose syncing phone with computer but then require that phone publishes on its own.

What if, instead, phone just relays pendingLog to computer?

You are already requiring them to be connected, and this would at least solve the problem of resigning and race-conditions between both devices (not in this case, but think of maybe bot-instance1 and bot-instance2).

[chmac]

@ssaavedra Yes, you’re totally right, that makes more sense here. I was actually thinking about computer being a server rather than my laptop, where it wouldn’t have my private key. But in the example I gave, this issue topic, your suggestion definitely makes more sense. :+1:

[aredridel]

Oof. That means "write long thing on one device, then lose the other device" loses the update.

[chmac]

@aredridel Maybe there's an alternative? What about if phone keeps a copy of pendingLog until it receives those messages back as part of the published log?

[aredridel]

Maybe? It's tough, trying to map identities to devices 1:1 like this, or coordinate with devices that may disappear, entirely, forever, potentially all but one at once.

[chmac]

@aredridel I think this might work. If computer disappears, then at some point phone could be told it is now the "source of truth", and could publish messages from pendingLog to log and push them to the internet. The other devices would then push to phone instead of computer. I guess if it disappears and has unpublished messages, they're gone, but that's likely true in any situation...

[aredridel]

That actually doesn't sound too terrible, given a single stream of messages.

[ssaavedra]

I agree with that, if computer disappears, a way to instruct phone to be the source of truth or relay on a different source (computer-backup?) can be designed.

If keys are already on the devices, there should be no problem, we'd just be avoiding the race conditions by relaying messages through a single stream, but we can fall back to self-publishing if required. But beware that this kind of network partition is precisely where we want to ensure that double-writes don't happen. We should really insist users to check their other device before allowing to write from a different device.

[chmac]

Another major challenge here is what does the local client do with pendingLog? I know from the Bitcoin protocol that dealing with forks requires quite some thought. My understanding of SSB's internal workings is that various views get built by parsing log. I'd assume that these views assume that log is immutable. How would a pendingLog which is essentially mutable fit into that paradigm? This aspect might actually be the source of complexity here...