SSB groups

Secure Scuttlebutt (also know as SSB, for short) is a delay-tolerant open source and distributed protocol, totally ryzomatic (as in: can't be bought by far-right oligarchs or shut down by odious tyrants) that Praxis have been helping for a while.

We're working closely with Manyverse, a SSB client doing a good job of sustainably build to-commons products. From them, we were invited to help with usability of a new SSB protocol feature, Groups.

Why groups

Groups are important because SSB is a cloud-less peer-to-peer platform, where discourse is generally open (like twitter).

Adding groups means communities can coordinate, share memories, manage resources, away from prying eyes, protecting their sovereignty.

On audience and deliverables

Currently the two apps spearheading the new feature are Manyverse and Āhau (a data-sovereignty-minded app built for indigenous groups) but others will come.

Assumptions and scope

We started by validating assumptions to produce an agreed scope. From there we validated group personas.

Group personas

User personas are archetypes that render explicit to members of the team the kind of user we're building for. Making it explicit helps us align our goals, reducing confusion.

You use personas as an acid test against a proposed flow, empathizing with their needs and goals and limitations.

For SSB, we decided on group personas since it's a social media after all.

• family photos: family wants to share pics of their life when they meet, seamlessly and privately. think siblings meeting for coffee while their devices update pics.

• company documentation: company writes their policies, code of ethics, tutorials straight on SSB. publicly or privately (closed groups?)

• indigenous groups: collective mapping and oral stories, respecting data sovereignty (related: Principles of Māori Data Sovereignty, PDF)

• study groups: a book club using SSB for event planning, notes and overall book (or any media, in fact) criticism

• political refugees: climate migration is on the rise. how can SSB help coordination of resources where corporate clouds fail?

Negative personas

The easier we make to enter and enjoy our tools, the more we're a target of recruiters.

Any group that depends on recruiting to grow should be part of our threat model. I'm talking about:

• nazis, white supremacists, alt-right

• cults, MLM, pyramid schemes

• marketeers, PR

• political propaganda, sock puppets

Possible deterrences are authentication security (that's our next post), blocklists (of both peers and subs, or even subs that follow them-like gab vs mastodon teach us), flagging systems, etc.

These are the personas we want to mitigate threats from - our tools should not make their work easy.

Group as an Object

To simplify specs, certain SSB features are called objects. Objects can be pointed at (shared, linked, referenced) and have a profile that shows more or less of its contents depending on the relationship peer has with it.

Peers have 4 types of relationship with groups: they're either in, out, request to enter, or invited to enter.

Joining a group

Groups are opaque to outsiders, but existence of the group is not. Outside peers can either request to join, or be invited to.

To request to join, peer answers pre-filled questions that then become a thread seen only by admins asking follow up questions. Admins can accept, reject or even silently reject candidate.

Sharing on SSB

Objects that can be shared either inside SSB platform (if you know each other) or outside it (if you only know each other outside it).

sharing outside SSB platform generates a token page that acts as a bridge, redirecting outsider towards the platform either by connecting with an existing account/app, or suggesting them to install it.

Sharing tokens links appear as Open Graph for friends. Token link and page are generic, and don't leak info of what exactly is on the other side, besides type of object.

Invitation to a group

Group invitations are also an object, but can only be claimed by the person invited, or have a 1 week expiration date if invitation is made outside SSB platform.

Being thrown into a group automatically violates consent, but it's a choice corporate social media made to drives engagement. On SSB, after invitation, peer sees profile and choose to join or not.

Inside a group

Once a group member, peer can see common threads, and if promoted to admin, admin-only and request threads. Candidates only see and interact with their own request thread.

Group members can view other members, along with their personal relationships and possible actions.

Clicking on a member opens a mini-profile, with everything about peer in the group. This mini profile differs depending on type of member, plus permissions.

SSB groups act as a truce between blocked, muted members: Members and admins are notified when people blocked by members join group or admin. The mutual notification forces existing members to discuss their differences before acting.

Group messages are seen by all members, so any message blocked/muted person sends can be seen.

Blocked members are not notified. Sincve muting is silent, only member who muted is notified and has access to list.

Conclusion

Because we're creating specs for different apps, design deliverables are loose (mostly flows and wireframes) so apps themselves can personalize as they wish. SSB community is composed of fun-as-fuck individuals, so it's cool to build stuff together.

Deliverables were presented to App designers, that are free to personalize it.