On the coding side, not much has changed: Mix and I have been working on ssb-keyring for ssb-box2. We didn't have a lot of time last week because I was focused on a Manyverse release, and Mix... with the cat.
But we had a productive team meeting, nicholas+me+arj where we discussed a couple of tricky topics, such as:
Groups as "persons"
Nicholas is more and more convinced that groups are "identities" in a way much similar to how persons have identities. This would be reflected on presentational aspects in the app, and in capacities ("groups should be able to publish public posts"). We discussed the tricky limits of this abstraction though, like:
- can groups be blocked? (we reached a conclusion that "yes", but we're defining what effects that blocking would cause)
- how does a group post something on its "feed"? (there is no single author for the "feed", so we'd have fork risks)
- if groups are persons, can I invite a group to a group? thus creating a subgroup (we decided to not allow this for the time being, otherwise we're complicating our work too much)
Closing a group
If group admins have the power to remove members, could they remove everyone from the group, essentially "deleting" the group. We didn't reach a conclusion for that, but we discovered that "leaving" a group is functionally equivalent to "blocking" the group, on the data layer. Or, there could be an exception where you unsubscribe from the group's contents, but are still willing to replicate the group locally, for the purpose of helping other peers.
Group where admins disappear
Related to "leaving" groups and stopping its replication, we also discussed about an indigenous use case, where a group contains a lot of important content that is old/generational, and should be kept forever, even if the group's admins pass away. Groups where inactivity does not imply autodeletion.
One idea I tossed, to support this, is forking a group such that a person elects themselves as the admin of an entirely new group which inherits content from another group.
Changes to SSB at the conceptual layer
So far, SSB has been a simple map from "1 feed ID to 1 person". The conceptual layer is the data layer. But this abstraction is showing its limits. On the one hand it's simple, and in many ways simple is fantastic, but on the other hand, we need to find solutions for: partial replication, stable storage, groups, same-as, etc.
One way how 1-feed-1-person already doesn't work is when you have two or more devices. That's the case for many people on SSB and we need same-as (fusion identity) to solve that.
For partial replication, we've come up with metafeeds which create a tree of feed IDs that you own, each branch for a specific purpose.
For (private-)groups, we have the group ID as a "cloaked msg ID" and increasingly we're noticing that these group IDs can function as "identities" or "persons".
So going forwards we're going to have to break apart the conceptual layer from the data layer. Feed IDs will just represent a sig-chained sequence of messages, but not much more. When thinking about a person, we're going to have create another representation for them, such that (e.g.) when addressing Alice in a DM or in a mention, the implementation will have to figure out "which of Alice's feeds do we target in this context?"
We want to be intentional about this tradeoff and willingly pay the cost of letting go of the simplicity of 1-feed-1-person.