NGI Assure group ("Private Groups in Manyverse")
@Mix @arj @andrestaltz📱 @Powersource @nonlinear
#bat-butts #batts #manyverse #private-groups
I realized that people in the SSB community may not know what we're working on, so in an attempt to bring transparency to our work and document our journey, I'm starting this thread that will summarize the whole team's weekly progress. Not quite a dev diary, because we'll also include design and other aspects along the way.
We started by trying to find a time in common for a video call. This proved to be quite hard! We have people in US East Coast, New Zealand, and Europe, and if you take a look at timezones, this means one of us will inevitably be in their usual "sleep" time range. We found a solution when nonlinear volunteered to wake up at 5AM on Fridays for the video call! For Mix, that's 9PM. In Europe, that's roughly lunch time. Our first team meeting was on 20th of May.
Now that we have the basics of teamwork set up (our communication channels are on Signal, our project management is on Airtable, our notes are on Hackmd), we can finally start work on core work.
If you peeked at this diagram for SSB work in the coming months you'll notice that we have 5 boxes inside the "funded by NGIa" rectangle. Those are the 5 milestones we have written down in our grant document. Once those are completed, we'll be paid by NLnet. They are:
(1) User experience design of groups
We want to study user needs and design the user interface of private groups in such a way that is consistent with Manyverse’s current workflows. Nicholas Frota, a product designer by profession, will lead this phase.
(2) Private chats extended to unlimited members
Manyverse currently has private group chats, limited to a maximum of 7 participants. We want to introduce “SSB Private Groups” as the engine behind group chats, extending the participant count from 7 to (theoretically) unlimited. This will allow us to test the waters of “SSB Private Groups” while not making user interface changes, yet.
(3) Removal of members by moderators
An important property of groups is community safety where boundaries are set, such that infringers are accountable for their actions and/or removed from the group. “SSB Private Groups” as a subprotocol does not yet take removal into consideration, so we want to design new rules in the protocol to allow groups to effectively exclude infringers, one way or another.
(4) Space-efficient replication of group messages
Group content is encryted to only the members of a group, and are irrelevant to group outsiders. While SSB stores replica of contents from friends, it is undesired to store encrypted content from friends if that content can never be decrypted. We need to find ways of utilizing peer-to-peer storage efficiently and respectfully.
(5) Groups as a new feature in Manyverse
Finally, we want to put together all the components of the previously mentioned milestones and deliver new group functionality in Manyverse that enables hundreds of members per group, member removal, seamless replication of group content, via an easily understandable user interface.
It seems like these are ordered linearly, but actually we started with (1) and (4). Turns out that (2) depends on (4), so (4) is really important.
Mix, arj and I had a video call to give Mix a primer on metafeeds, and to sketch a first draft of how would private groups replicate as metafeeds and subfeeds. We have a nice sketch, but it has some open questions that need answers before implementing. Mix also got acquainted with ssb-meta-feeds, giving some feedback on its API, and a README PR.
Nonlinear got busy with (1), and the design process starts by mapping out all the assumptions (be them technical, sociotechnical, or social) surrounding Groups (we're dropping the word "private" by the way). Notes can be found in this GitLab issue, but these notes will evolve a lot over time. So if you're reading this in the distant future, I don't know what you'll see there.
:) We had a couple of meetings to discuss these assumptions, and we noticed how much nonlinear's design work is extremely important!
One of the conclusions that we arrived was that we cannot promise that Groups are for the security-minded folks. These SSB Groups can't even be on the level of Signal chats in terms of privacy and security. This has to do with limitations in the cryptographic schemes we're using. Any group member can leak the symmetric key of the group to anyone else, which means those others could not only read one message, they could read all messages! And they can also write new posts such that existing members can read them (unless we stop that on the UI layer). It's important that we acknowledge this and that we don't promise too much.
That said, the cryptographic schemes we'll use are an improvement over the wide-open Public posts, because Groups can have some kinds of boundaries that Public cannot. We're reserving "Secure Groups" (with double ratchet-style perfect forward secrecy and other stronger properties) as future work, where we'll be able to cater for personas that need strict security guarantees. Communicating the "security"/"insecurity" of
private-groups-based Groups is going to be an important task. At this point I'm very grateful we have a professional designer who helps map the assumptions, concepts, personas, limitations, and utilities.
(continues in the next post...)