Patchwork: Multi-device support (a.k.a. Multiple Identities)

[mawise]

I figure this one will probably be a lot of work and I don't know what other discussions already exists but maybe I can trigger some brainstorming.

My (limited) understanding is that we can't use multiple devices with a single id (key) because the log could get out of sync between devices. Eg: if I make a post on my phone, then another post on my laptop but the two don't sync between then I've got a divergent log. (Ignore the fact that there's no mobile support)

My first (naiive) solution is to give each user an ID on her first device, and each other device gets a child ID. Now each device owns it's own log. The user needs to just assert once in the device log that this ID also represents her. This assertion also being signed by the root ID; sort of like an https certificate. Maybe we can even do this using the existing certificate standards.

Other ideas?

[ahdinosaur]

hey @mawise, i like what you're thinking. :zap:

you can find previous discussions starting from (and then following the cypherlinks):

%q6qYcAlqig+3fqDxvBjaUzLyCoxG1yNUd4focPVSXhI=.sha256

[ETeissonniere]

Hm... What about a multisig-like system?

[mawise]

Thanks @ahdinosaur for the links! I hadn't spent enough time thinking about key revocation and private messaging, which that discussion made me think about.

It sounds like there are two main alternatives floating around.

1. Somehow associating multiple keys by asserting that another identity is the same as me (and the reverse).

2. Defining a hierarchical group structure such that it doesn't matter if you're sending to or publishing as a group or as an individual. Then an individual can just be the group of her device identities, and groups of groups are trivial. I think this is the same as fractal identities.

I haven't spent time yet thinking about multi-sig and it's consequences, but I think the details of the implementation become very important.

I expect that some implementation of 2. will make the better long-term solution, but it is definitely more complicated. Specifically it needs semantics around how the "group" can post content: for example if the group has a single log, then a majority of the group must approve any post before it gets appended, which limits how big a group can be and still be useful for publishing. It also needs semantics around how membership can evolve.

I think that 1. can be implemented much more quickly since we can rely on shortcuts such as requiring mutual "you're the same as me" statements, and leaving out key/identity revocation for now. I think key revocation will really require breaking the semantic of key==identity, and making identity a different abstraction.

[dominictarr]

@mawise variation on 2: if you could describe your rules for creating a valid log append as say a javascript function (getting into "smart contract" territory here) then you could do all sorts of things like have a rotating leadership or "board of directors" that would be responsible for updates. Maybe a thing could be you'd assign a leader, up until the AGM (annual general meeting) and then a majority vote would be required to elect a new leader. etc. you'd need > n/2 to agree on a valid next message, but any subset of members could fork the group (i.e. kick everyone else out). hmm, interesting implications around default behaviour for removing members - would you default to "loyal" stay with the group, or "rebel"? hmm, I think that might be able to a per member configuration setting...

[av8ta]

@dominictarr there are proof of stake altcoins that work exactly like that. Memory is fuzzy about where I read it but it may have been the federated proof of stake coins. Apache Zookeeper on top of Apache Kafka has leader elections as part of its fault tolerance strategy for when servers go down. Brief overview of that here: https://www.infoq.com/articles/apache-kafka

@mawise @dominictarr the problem of multiple devices belonging to one identity - I don't know the inner workings of ssb yet so this may be a silly idea... I wonder if this problem could be solved in a similar fashion to HD wallets in bitcoin. You have a seed (usually twelve English words) that derives an unlimited number of public/private key pairs deterministically from that seed in a merkle tree. I'm thinking the root of the merkle tree could be the master identity of a human and the keys down the tree could be their aliases and differing personas or differing devices. So each key down the tree could be used as either a different persona and/or a different device. That way each log is tied to one keypair but the individual gets to claim ownership over many keypairs via ownership of the root key. Perhaps it could be applied to groups as well - the root being the overall group and the leaves being members. Not sure how you tie those membership keys back to an individual's tree though

[mawise]

@dominictarr cool thoughts about smart contracts! I read a little bit about this idea in the links @ahdinosaur shared.

It might be worth taking a step back and deciding exactly what semantics we want out of groups. For groups to solve the single-user, multi-device issue by giving each device it's own key we need other users to be able to follow a group and get updates from every ID in the group. We also need a way to send a private message to the group that can be read by every ID in the group (multi-encoding?). We basically want the group to be an abstraction that other users can follow or message, hiding the different devices.

For groups of real users, what do we want? If I joined a group, I wouldn't want all my postings to appear as the group identity. I probably want to be able to post either as the group identity or as my own personal identity.

Either way, It does seem like we can have the group's log only contain membership updates, whether using a fixed algorithm or a hashed algorithm that requires > n/2 members to approve somehow in order to avoid log forking.

Then by processing the group log, you get the id's of every user you need to follow to get group messages. And those logs have "group" posts somehow annotated. Private messages to the group get encoded for every member in the group. This works well for single-user/multi-device as well. The user would just annotate every post as a "group" post.

Now a group of groups would recursively allow every id to post as the group, and require any private message to be encoded for the entire group.

I think this has some problems:

• group posts are no longer a single append-only log. If you post as the group, then I can post as the group after you with my own asserted timestamp that is before your post. This is kind of gross.
• in order to follow a group, you have to download every group member's entire log
• messages to groups are only visible to the membership as of the last update received by the sender.
  
  
  
  • If I get updates that group X has members A and B, then I disappear to Antarctica or otherwise off-grid before C and D are added to the group, then any messages I write to the group before I get back can only be read by A and B. Maybe this is the semantic we want for groups.
  
  
  • If I'm running Patchwork on my laptop and phone, and after you go sailing I get a second phone and start using that, I can't trust that I'll be able to see every message on my second phone.
  
  
  • Maybe this means we want two group semantics. One where private messages are encoded to the group's key which is shared among members (add-only groups), and another semantic where members can be added and removed, but new members don't get to see historical records.
  
  

[mixmix]

make sure you search patchwork for discussion about this one.

[fuzzyTew]

It seems like there are a number of 'ideal' solutions to this problem, but it could be good to have a 'simple, quick' solution for the short term.

I would just allow a client to specify (and publicize) that some other device is owned by the same person. When private messages are received, they are forwarded to that device. When that device posts something, we post it too. If both devices specify each-other as co-owned, this will allow functionality with both.

If a device is compromised or lost, we can specify on another device that this is so. Both devices can still be used, separately, and if both stay active friends will have to decide which one they consider to be the real user.

This preliminary approach should require no changes to the existing protocol.

[mmckegg]

@fuzzyTew

I'm just about to start working on this! SSBC has given me a grant to work on this problem for a month. The plan is outlined in this thread: %JjSO5d5/lIRyv5gUKEFis57urBvFam1cAbAIVXMMGJo=.sha256

It basically boils down to what you mention above! It is a user interface solution rather than a crypto one, but from my understanding ends up being very secure with few trade-offs.

My current plan is that someone follows their other feeds with sameAs: true. If the other feeds also follow back with sameAs: true, then patchcore will merge these identities together.

Since the actual mechanism for merging feeds is separate from the sameAs following stuff (it is a filter in patchcore), potentially it could be used by other features. I will explore what these are as part of the R&I. @cinnamon-bun has given me a lot to think about in this area, as far as how public this sort of thing should be: the "subjective" merge. At this stage, I want to at the very least implement it as a private feature (I can merge feeds in my client, but no one else can see it). But this is much less important than the two way full merge as above, so I won't prioritize it.

[davydog]

@mmckegg

Do you have an update on your Multi-device support project?

[mmckegg]

@davydog

I have a prototype working here: #695

Taking a break from Patchwork for another week or so, but hoping to get back in and have something released mid-late Jan!

There's a dev diary here: %DxQpzCl/x6ulFoU/a2XWiET1hh3Nfw/VGWHCSg88V8U=.sha256

[davydog]

@mmckegg - Thank you for your update! From this point on I'll refer to the dev diary for future multi-device development updates. Is there another dev diary I should refer to for updates on mobile development? I ask about mobile mainly because younger folks (like my daughter, her boyfriend, etc.) are more accustomed to accessing social media through their mobile platforms. (I still prefer using a desktop or laptop.)

[ahdinosaur]

hi @davydog, mobile development is primarily being worked on by @staltz:

• grant proposal: %dRRJzh1KjmVBdjU27ZHAYdMXZLXmRZVXpmla0D6K8aI=.sha256
• dev diary
  
  
  
  • %b6nlgiAu3ZWkLqKnvkU1T/9PZCfiqSU/Ujg1xRmD/64=.sha256
  
  
  • %3vAGovsIPBaffEjlXS66sgZAM61lkluMOHux8vbODys=.sha256
  
  

there's more if you follow Andre on the 'butts, but those are the most important threads i reckon.

[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.

[xloem]

@staltz @ahdinosaur looks like this issue was just closed by a bot. I've partly been not using scuttlebutt waiting on this feature; any updates on whether anybody is working on it anymore?

[xloem]

@mmckegg did sameAs ever happen?

[mmckegg]

@xloem Not yet, but there have been some massive backend changes to replication and contacts just recently that now makes it possible to do properly.

It's just waiting on someone to feel like heading it up sameAs again. That might be me eventually, we'll see! (need to complete the refactor first)

[DawnPaladin]

I too am waiting to join Scuttlebutt until this feature is in place. Please work on it when you can!

[mixmix]

Anyone with available resources, please offer to fund this if you can
afford it. It makes a big difference

On Tue, 22 Jan 2019, 05:37 James Harris, [e-mail] wrote:

I too am waiting to join Scuttlebutt until this feature is in place.
Please work on it when you can!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ssbc/patchwork/issues/484#issuecomment-456133699, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACitnoniRCJe-kx1aJkORzrtG_b9Vqx_ks5vFezfgaJpZM4M34uJ
.

[xloem]

@mixmix, are the devs using any preferred bounty system we could accumulate spare change into?

[christianbundy]

@xloem

We've used Gitcoin here and here, I'm not aware of any other bounty systems that have been used but I don't Gitcoin is specifically preferred.

[Mathias-g]

How much needs to be raised for this feature to be implemented?

[xloem]

I started a bounty at https://gitcoin.co/issue/ssbc/patchwork/484/2183 with a current value 0.4 eth or a little under $50. I think others can add money by hitting the 'contribute' button on that link.

[mixmix]

Great idea. Depends if the money is paying for a person's time, or is just
a koha (gift/ offering).

This is a really big piece of work and touches many oujda of the stack.
There's also a question of who gets to approve the person taking on this
quest. To get it into Patchwork would require a bunch of matts time

On Sat, 26 Jan 2019, 18:11 xloem, [e-mail] wrote:

I started a bounty at https://gitcoin.co/issue/ssbc/patchwork/484/2183
with a current value 0.4 eth or a little under $50. I think others can add
money by hitting the 'contribute' button on that link.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ssbc/patchwork/issues/484#issuecomment-457803057, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACitnqbzjoR0fCqU3c0YGW6sjX-GoUt2ks5vG-OFgaJpZM4M34uJ
.

[xloem]

There's also a question of who gets to approve the person taking on this
quest.

The bounty is set to auto-approve workers after 72 hours. I'm new to gitcoin and am happy to adjust it or transfer ownership.

Sounds like some more donations will be needed.

[mixmix]

Yeah I honestly think it would be good to be careful and a little
conscious about this.
I think there should be a gitcoin bounty for preparing (identifying,
planning, scoping, seeding) quests that would be suitable for gitcoin
bounties.

There are probably a bunch of easy wins, and there are probably some
dark holes we need to plan around. I'm really interested in gitcoin
funds this sort of work. Because it is a huge part of /the work/

On 28/01/19 5:02 AM, xloem wrote:
>

There's also a question of who gets to approve the person taking
on this
quest.

The bounty is set to auto-approve workers after 72 hours. I'm new to
gitcoin and am happy to adjust it or transfer ownership.

Sounds like some more donations will be needed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ssbc/patchwork/issues/484#issuecomment-457930094,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACitnnh8U1W7EtlY-qvZQb3MU3zUF8yxks5vHc19gaJpZM4M34uJ.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__Work has been started__.

These users each claimed they can complete the work by 316 years, 9 months from now.
Please review their action plans below:

1) ucheblessed28 has started work.

New ideas about your project is that we could just generate a general ID for the user which should just be his/her email, then we can login through any device

Learn more on the Gitcoin Issue Details page.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[xloem]

this issue has been closed but it is being discussed in #sameas on scuttlebutt as recently as two weeks ago.

[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