fraction/oasis

Same-as support

christianbundy opened this issue · 11 comments

christianbundy commented

This sounds crazy but I swear it isn't.

What's the problem you want solved? Lots of people have lots of accounts and there isn't a clear way to link the accounts. On SSB this is usually called #same-as, and there's some deprecated code here that doesn't work, but the spec is there.

Is there a solution you'd like to recommend? If you're following someone publicly, maybe give two options: "unfollow" and "same-as" (TODO: better wording). If you select same-as, it publishes a message that says { following: true, blocking: false, sameAs: true }. The easiest win would be changing the Mentions page so that it adds mentions for all of your feeds instead of just the one you're on now. We could iteratively add features like:

  • Same name between all feeds
  • Same description between all feeds
  • Profiles display messages from all feeds
  • New private messages add all feeds as recipients (max 7 though, ouch)
  • Eventually underlying modules (like SSB-Friends) so that following one feed has the same effect of following that feed + all feeds it's done same-as with.

Anyway, my thought is that it can be iterative, and that literally just changing Mentions will have a gigantic impact on the adoption of same-as by other clients. 🤷‍♂️

cinnamon-bun commented

Yeah! This is the start of a complex UX challenge but it's a good place to start. I have many thoughts!

Having to follow first before seeing the same-as button is unintuitive, could it always be there?

There are lots of relationship actions, maybe it makes sense to put some of them behind a dropdown. This could be one, since it will be rarely used.

We'd need a way to undo it also. Different-than. :)

same-as sounds like jargon - how about "Claim as my profile"?

Let's see, there are 4 cases. What should we show on a 3rd party profile page (not your current identity's profile)?

Neither I nor the profile I'm viewing have sent same-as

  • [Claim as my profile]

I've not sent same-as, but the profile I'm viewing has

  • [Claim as my profile]
  • (Let's not show that the other identity is waiting for confirmation from you - this will freak people out if a random person tries to same-as them, when it's a harmless situation since it means nothing unless coming from both sides)

I've sent same-as, profile I'm viewing has not

  • Claimed as my account, waiting for confirmation from the other side. [Unclaim]

Both have sent same-as

  • This is you, on another device. [Unclaim]

Lastly, every profile (yours and others) should show a list of the other confirmed same-as accounts (or be a single merged profile page, but that's tricky)

  • 👍2
cinnamon-bun commented

Let's call a cluster of same-as'd identities an "identity bundle" for lack of a better word.

I wish we could hide this whole situation from users so it just feels like a seamless single identity across devices, but I don't think we can plug the leaks in this abstraction. Instead of hiding it, I think it would be better to highlight the difference so users understand the concept.

Lots of challenges to solve!

Profiles and names

  • What profile info to show when there are several different names in a bundle? Should we use a single name for all the identities, or show their separate names? Maybe we need a separate kind of profile page for bundles vs single identities
  • There's nothing to use as a canonical ID for a bundle, e.g. for profile URLs, because bundles can be constantly changing / merging / splitting

Relationships

  • Following, blocking - apply to all identities in the bundle, or just one? The bundle can change later - new devices; merging together with another bundle

Private messages

  • When sending private messages to a bundle, if the recipient adds more devices to their bundle later they won't be able to read the old private messages from the new device.
  • If bundles in a private message thread have changed, who do we use as the recipients for newly sent messages to that thread? Do we need to get user consent to change the recipients?
  • Your outgoing private messages need to get cc'd to your own other devices so you can read them there. Same for any private-to-yourself messages like private following.
  • Private message limit of 7 participants is not enough for two humans who could each have 4 device identities
cinnamon-bun commented

Right about now I'm wishing same-as worked by using a single shared keypair among all devices. Then we could use the keypair as a stable ID for the bundle.

cinnamon-bun commented

Anyway I'm thinking too far ahead! Yes to this:

  • Same-as buttons on profile
  • Include your other identities in Mentions and Participating
casutherland commented

It could be of interest to review how keybase provides a fluid #same-as user experience, by composing the user's identity graph (linking to hellobot's as Chris's graph is not rendering) from the user's device identities and the device sigchain.

Reconstructing this graph is what the Keybase app does, using chris's chain. It also checks each of the social proofs: the tweets, gists, etc., to make sure the edges are truly bidirectional.

Aside: as was mentioned previously elsewhere, SSB could potentially provide a social proof endpoint, in addition to consider a similar proofing and sigchain mechanism to implement #same-as.

tunnckoCore commented

@qcu, just was thinking about the same thing.

Meanwhile I found there's ssb-identities which seems like such thing, reasons not using it?

anicolao commented

I don't see how this can possibly work in the presence of private messages, or even how you send private messages to someone with it being clear how to encrypt. It's not a stretch to imagine someone with more than 7 same-as identities, or trying to send a message to two people whose sum of same-as'ed identities is more than 7, or a user who expects to be able to read your old message with a newly minted same-as identity.

christianbundy commented

@anicolao You need to either change how private messages are encrypted or say "we can only encrypt to this maximum number of recipients". 🤷

CommanderMoto commented

So, DID 1.0 was officially released as a W3C recommendation today. I believe this information should be relevant to the same-as discussion. If this is a topic that has been waiting for a proper Standard to help solve some of its challenges, well - we're un-blocked now!

jphastings commented

I think you'd need to create a "meta" identity to hold all the fluid accounts that are same-as. It'd be a substantial change to support such a thing, but it'd offer lots of flexibility. I'd see it operating like this:

  1. Me (Phone) initiates 'same-as': A new SSB identity/private key is created ("Meta private key").
  2. Meta account is created: Meta private key is encrypted so only Me (Phone) can decrypt, and included in a post from the meta account which declares "This is a meta-account including Me (Phone)"
  3. Me (Phone) sends invite to Me (Laptop) to join meta-account: a private message including the Meta private key encrypted so only Me (Laptop) can decrypt.
  4. Me (Laptop) accepts request to join: Uses meta-account private key to repeat (2) from Me (Laptop).
  5. New followers can follow the meta-account, and clients will automatically follow both Me (Laptop) and Me (Phone) behind the scenes, showing both as if they were posted by the meta account.
  • The profile of the 'same-as' group is the profile of the meta-account — so there's a definitive way to uniquely declare what the profile pic/name/etc is (this is probably copied from the first account to start the same-as process, by default)
  • Messages (2) and (4) are structured so that older clients (which don't support this extension) could follow the meta-account and still get the idea that Me (Phone) and Me (Laptop) are probably the same person, and can choose to follow both accounts separately.
  • Newer clients would send private messages to the meta account, so would be encrypted using the meta-account's key; so all clients for the sub-accounts can decrypt (because (2) and (4) provide that key to sub-accounts)
  • This also means accounts newly brought in as sub-accounts can decrypt historical private messages sent to the group (this may not be desirable! It seemed like it was saught after in this chat above though)
  • Removing a sub-account from the meta group indicates to followers that there's no need to follow that particular sub-account any more (it doesn't prevent that sub-account from decrypting historical messages etc.)
  • New clients receiving private messages to a sub-account (instead of the meta account) can make it clear visually that the conversation won't be available on other devices; perhaps the other party should upgrade etc.

Does this seem wildly infeasible or undesirable?

  • 👀1