SSBC Grant Request

Research and implement multi-device feeds in Patchcore and Patchwork

One of the most commonly requested features on Patchwork and the rest of SSBC is how do I use multiple devices with the same identity?

This is such an obvious feature that most people are very surprised to learn that there is currently no good way to do this. But I have an idea that I would like to experiment with that should solve this problem quite nicely. It is not a "highly-technical" fancy pants crypto solution or anything like that.

My idea is to treat "profiles" themselves as subjective.

We could allow individual uxers to choose which feeds they would like to see merged. Other people browsing profiles would see that people that they follow have merged a particular profile with another and be able to agree (or disagree) with a merge. After agreeing, the feed would appear merged for them also.

Subjectivity has always been at the heart of all things SSB, allowing people to control their experience of the network. Why not allow people to choose the feeds that should make up a person?

In addition, a merge would be rendered by default if two feeds agreed that they wanted to be merged with each other.

Implementation

I suspect that after diving into this problem, the implementation details could change, but so far here's an outline of what I want to do technically:

• uxers publish sameAs about messages
• specified feeds get merged together if you are the author of the sameAs message (in the same way that you can rename a person) or if each feed specified has a matching sameAs about message pointing back at the other identity
• feed merges published by people you explicitly follow will be included in the public feed and displayed on the target profile pages - you can then choose to agree by also setting the sameAs message (probably with a dismiss notSameAs option)

I would update patchcore (which Patchwork, patchbay and mmmmmm are all based on) to read sameAs messages using the ssb-about plugin and apply the resolved merges to the various views and observables (such as contacts, profiles, and mentions).

Then implement the UI required to do the merging and approvals inside of Patchwork.

I would then assist other client developers in adding sameAs merging support into their clients if they want me to :)

Why I should do this (and why I want to)

I have now had a lot of experience rendering the scuttlebutt feed in various ways, first in Ferment (my failed decentralized soundcloud alternative) and then in Patchwork v3 (the vast majority of it is my code). I am one of the primary designers and developers of Patchcore, a shared library used to split out a lot of the complexities of making sense of the scuttlebutt feeds, and I understand all of its inner workings.

I'm sick of seeing all of the old dead profiles, and would like to merge them back into their new feeds. I would like to be able to share my "follows" and "subscriptions" with other devices instead of having to manually manage this. I want other people to see all of my posts as coming from the same person.

This is something I have wanted to do for a long time, but I suspected that it would probably be a lot of work to get right, and would take some time to experiment and work through all the weird issues. Funding would motivate me to finally push through and get it done!

Also sameAs logic can be used in a lot of other cased. I need something like this as a way to merge multiple book entries for patchbook.

There is currently a good discussion underway about this in this thread in particular very good suggestions from @cinnamon. I'd like to see that discussion resolved, or this proposal supported by @cinnamon. But yes, this needs to happen!

Thank you @cinnamon for the great context!

I think I understand where you are coming from now about other people being able to change the way your personal profile appears.

Does that mean you are not in support of displaying the names people you follow call someone on their profile?

One of the big features in the upcoming Patchwork 3.8 release (in addition to blocking) is that only names that your friends assign to someone will show on the profile, not just random strangers. Also the FOAF is being reduced down to 2 (meaning that Patchwork will no longer download the feeds of complete strangers - you now have to follow someone that follows them directly).

I am very keen to discuss this with you further, and re-submit a proposal if necessary!

Okay, this has given me a new idea.

These should be contact messages not about and should be handled inside of ssb-friends.

To merge feeds from your devices, you make them follow the other devices with sameAs: true in the contact message.

If two or more feeds have matching sameAs contact messages then merge the profiles together.

Then what about subjective identities?

I would like to also support a case where a feed follows another feed with sameAs but the other feed does not follow them back. For example in the lost key case, @Dominic would follow @dead_Dominic with sameAs: true.

If someone looked at @dead_Dominic, they would not see anything different. However if they looked at @Dominic's new profile, they would see an assertion saying that this other feed was also him.

This means that someone can't affect another person's profile display, but they can say things about other profiles from their one. People can already do this, no real change.

But the big benefit for @Dominic would be that he now receives mentions for his old identity in his client.

Other people could agree with his assertion, and publish a {type: 'contact', contact: '@dead_Dominic_KEY', sameAs: '@dominic_KEY'}). This would not appear on @dead_Dominic's profile in any way to anyone else. But now the person would see these accounts as merged. Potentially you could add a "x of your friends" agree that @Dominic is right about this assertion on his profile.

I'm less sold on this second part of the idea, but I am pretty confident that these messages should be contact instead of about.

@matt is "subjective identities" really about key revocation?

@cinnamon

When I look at person A's profile, whose nicknames are displayed there now -- those written by people I follow, or those by people person A follows?

Both! You follow or they follow.

If I use SSB under a pseudonym to talk about dangerous or controversial topics, I don't want my friends announcing my real name or merging me with my other account.

how do you deal with this problem in the real-world? what is your strategy to handle when somebody calls you by a different name than you prefer, against your wishes?

personally, i never chose the name Mikey. my roommate at university called me Mikey, against my wishes, when at the time i preferred to be called Michael. eventually, i realized that fighting against my friends was silly, and accepted that names are better given in love than controlled in spite.

similar to real-life, Scuttlebutt's decentralization means we can't control who says what and who hears what other people nearby said. regardless of how Patchwork implements this, any other client could choose to implement it differently. what is our strategy to handle when somebody implements a Patchtroll client with every feature we disagree with?

i like @matt's proposal because it provides a simple way for uxers to be in control of their subjective identities, using the same logic as we already have for nicknames. it doesn't mean we are in control of the subjectivity of others. but i think this respect and support for inter-subjectivity is what makes Scuttlebutt so beautiful, especially in a world of polarizing factions.

trying to explore the roots of my tension, which is way beyond the original proposal so i'm sorry if this is going off-topic:

@cinnamon i really appreciate your efforts to help Scuttlebutt support privacy and reduce harassment, in general to create better ways for uxers and communities to establish strong personal and group boundaries.

on the other side, we have some who feel that strong boundaries cause strong pain: %caKx+Bx...

Whites, non-whites and whomever else can freely speak their mind when I am around. They don't need to worry about trigger warnings, safe spaces, or what not. They can just communicate in an open honest way, and be able to know that I won't be "offended" by whatever they have to say. I would rather them be fully honest about what they think, for example, given that I am non-white. Why is it that a white man would be so comfortable with me, so as to share that they are klan sympathizers, or x/y/z group which radical ideals etc... The progressive left, merely uses Stalinist tactics, to beat their opponents. Instead of rational discussion about these things, if you want to defeat the racist's then you have to be reasonable, and concede that they might have some legitimate points despite their xenophobia.

it's easy for me to disagree with this narrative, but lately i've been coming back, trying to understand this widely shared pain, it's hard to ignore when it is spreading like wildfire. and in some way i can also relate, back when i was living in the Bay Area, to what @rich describes here: https://medium.com/enspiral-tales/4-things-that-struck-me-after-visiting-political-spaces-in-14-us-cities-c1dceb1e8cb4

I think that’s what I mean by the censorship I picked up in some of the political spaces we visited. Folks don’t seem to have good spaces to learn in, so they shut their mouth to avoid causing harm. If I’m not comfortable talking about sexism it’s safer to say nothing.

At best, censorship results in reduced capacity. People with more privilege have more opportunity to shape the world, so we need to learn how to talk about oppression unapologetically.

At its worst, censorship turns to rot, resentment and shame, which is a resource that neo-fascist recruiters know how to exploit. Trump said it is cool to be sexist again, and I’m sure a ton of men breathed a sigh of relief.

the best i've come to so far is that there's a difference between using a boundary to assert control of your space and using a boundary to assert control of someone else's space. it's something about self-defense versus aggression.

i'm still teasing this out. i agree it's a much more important priority to focus on supporting those who are marginalized and may experience harm from unsafe spaces, then those who will feel pain from privilege, but i guess at the end of the day we're all in this together.

@cinnamon I like what you raise about naming. I think telling people it will be publicly visble (or when you say it, it's heard) is an excellent idea

I think people giving offensive names to others is a good signal I want to block them. People accidentally revealing others is another matter. We could perhaps explore private-names - names that only you and some group know. The challenge is then switching contexts so in a private group I call you @cinnamon_REALNAME and here you would say @cinnamon ... but we could teach interfaces to block private names ... aaaand I'm down a rabbit hole talking implementation.

yeah, being able to privately nickname and merge identities, i think that's a really good idea that makes sense for all types of messages

it would also be pretty neat to be able to make private names, that where then only autosuggested within private messages. and no one else knew them. (or, within the layers of protected messages)

@cinnamon yes, the diagrams are spot on for patchwork 3.8.x!

By the way I released Patchwork 3.8.0 but found a bug that I want to fix before pushing it out (and doing the changelog). Will probably release a 3.8.1 first.

Thank you so much for your contributions to this discussion! I really appreciate the input and have found it quite eye opening!

I like the use of telescopes/spyglasses for following. Very boaty, but also more clearly indicative of the mechanics/semantics than an arrow.

@cinnamon these diagrams are really helpful. Thank you.

Hi @Nate

That's a generous thought. The post describing the grants is here: @EMovhfI...

If having read it you have any further questions, ask away.

I'm new here and may not be the best person to answer them but I'm certain someone else will do so!

Wrong link. I'll try again in a moment once I've found the right one. Sorry.

Hopefully this is the correct one: %Qmj97E3...

I've been thinking about this proposal for a few days, trying to wrap my head around whether sameAs is the right way to do this or not.

I have a few questions, and maybe more in the future.

• Let's say I have two devices, and I want to get private messages on both devices. How does sameAs help me with that?

• If I can use sameAs to merge profiles with lost keys, how does that prevent someone from firing up a key and claiming my feed as their own?

@ev if someone wants to send you a private message, they just send it when they @ you, it just add all your sameAs devices as recipients.

how does that work when you mention 3 people with 3 sameAs each @dominic ? thats over the cap

@mix Same thing as if you mention 8 people with no sameAs

Some people won't get the message and there will be no warning. Bad user experience indeed.

@cinnamon oh, we could just have a receive-key (similar concept to your merge key) that was share across devices. then you'd only need one private-box recipient per receive-key.

regarding original proposal:

@ev raised a concern

I want to agree to locking in 1, multi-device feeds. However, I'm not clear if this is going to be implemented as sameAs -- which I'm concerned is a security risk, as someone could pretend to be my feed with this strategy.

I also raised a similar concern and suggested separating receiving private messages from merging feeds. That discussion was in the other thread

I want to see multi-device feeds implemented as subkeys using libsodium -- similar to how Bitcoin issues subkeys for receive addresses. Is this @matt's approach? If this is his approach, then I can support 1. If not, I cannot.

Are you refering to Heirachical Deterministic wallets? That won't be more secure than this proposal, because either you do hash("phone"+privateKey) to get a private key for the phone, but you can't prove to someone else that is the correct key without showing them your private key.

There is also a way to do something like curve_add(hash("phone"), privateKey) and also something that corresponds to curve_add(hash("phone"), publicKey), this sounds really good, but unfortunately it means if you gain the phone's private key you can reverse the addition to get the main private key. This means if any device you have gets compromised, they all get compromised.

For that reason, I think it's safer to have separate keys generated on each device, so that loosing one device only compromises that one device.

@dominic Thanks for going into depth here. The truth about this topic is I'm not sure what the right approach is here, because I don't have enough experience with cryptography to implement it myself. I'm just concerned that sameAs could be the wrong approach, and when you're messing around with crypto you don't want implement security issues -- as they lead to security exploits, and thus lead to people writing about how your software got exploited. Right now ssb has managed to avoid that so far, which is awesome!

@matt Would you be able to clarify the approach you'll be taking towards implementing this grant?

I'm fine with this grant being used to pay you to research towards what the best possible implementation of this is, as this feature is very important. I just want to make sure that it gets implemented the right way at the lowest and most secure level possible.

@ev

Would you be able to clarify the approach you'll be taking towards implementing this grant?

Part of this process will be exploring the different approaches to implementing this. The grant is for "research and implementation".

As mentioned in the root post, I suspect that once I start down this rabbit hole, my approach may change.

Just from discussions, I have changed my mind about using about messages in favour of contact.

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

cc @keks

@cinnamon yep, this all make sense.

In regards to third-party merging (if I end up implementing this) I think it is important to reiterate that you will NEVER ever see a profile as merged unless you explicitly opted into merging!

That was always the plan, but I possibly didn't make it clear in the original proposal.

The part that I am still thinking about is whether a one-way sameAs should be displayed anywhere in the user interface and if so, who should be able to see it.

Like we discussed previously, there would be very little room for abuse displaying it on the person's profile that made the assertion. But what about on a profile that the assertion was made about? I can see how that could be a problem, so I'm going to be very careful here! If I were to implement that, it would only show if you are friends with the person that made the assertion.

@cinnamon

I'd suggest using the about message with the highest timestamp across the linked feeds.

Yep, that makes sense! I totally agree.

By the way, there is some discussion about this that you might be interested in on the old deprecated ssb-contact plugin: https://github.com/ssbc/ssb-contacts/issues/1

@dpc yes, that is definitely a trade-off.

But I know of no crypto solutions that can avoid this and not share a private key between devices. We want to avoid the case where one device getting compromised causes you to lose control of all of your devices/identities.

Can anyone think of possible exploits/abuse given that you know which device someone is posting from?

cc @cinnamon

@dpc

Thanks for the suggestion. Unfortunately, I believe something like this would involve some deep breaking changes to #scuttlebot in the way that feed replication works.

Do I understand you correctly that from an outside perspective, an identity is no longer a fixed key, instead it changes every so often? Is there a "primary" key here? If so who controls the private key to that primary key?

Please forgive me if I am interpreting your suggestion too much though the lens of how identities currently work!

the consensus here might be a little blurry part, since the whole process is not be interactive; care needs to be taken so that things are not "stuck", waiting for one device or something like that

Yeah that is true. I think that will come down to getting the user interface right.

Also (slightly controversial opinion), a partial state might not be so bad if we embrace a small amount of subjectivity in this. What I mean by that is a one way assertion still has some merit if that feed is trusted.

Gluing together feeds via some higher-level concept is a bit of a hack, if you ask me, but I guess in the current architecture, might be the best choice.

@dpc it's maybe worth mentioning that this architecture is not by accident. by having a linear history on one-feed-per-key, we can avoid entire schools of problems: consensus ( #against-consensus ), conflict resolution, dag/tree replication, and so on. the idea is that by starting with less we can create simple protocols that can provide a solid foundation for doing more. everything is trade-offs and this seems like the best option given what we currently know from the first few years of playing with this system. that being said, thanks for your alternative ideas, there's still much exploration to be done if you want to help experiment with some alternative protocols.