I promise to add some more documentation before this is released, but I just want to keep providing updates on what we're doing here at the streams repository - especially as it concerns the fediverse and conversations.
The background is that we've always provided what I'll call "containerised conversations" in earlier iterations of the fediverse (several years prior to the emergence of Mastodon and ActivityPub). These are quite different from microblogs - which aren't really conversations at all, but more like people throwing posts into space kind of willy nilly. Each post and each comment can be addressed to a completely different audience.
In our alternate implementation of the fediverse, conversations are contained and more coherent. We do this by directing all comments back to the person who started the original post of the conversation, regardless how many levels of nested comments. This person "owns" the topic and is responsible for distributing all the comments to the original audience. This is how one implements restricted conversations - sometimes called circles or aspects - as well as private groups; which are very difficult to accomplish in a microblog platform. This is why only a very small number of fediverse implementations support these concepts.
When we brought our work to the ActivityPub fediverse several years ago, it conflicted with the microblogs, who quickly dominated the space. So we provided some ActivityPub extensions to continue our work and still use these very important conversational constructs.
Fast forward a few years, and we've been squeezed into a corner, and what we consider a superior way of managing "restricted" conversations has been relegated to obscurity. But during this time, a handful of ActivityPub developers have been working on tools which also provide this functionality, in better ways that in our original extensions. So we're updating our repository to accommodate these changes.
This work is described in the following Fediverse Enhancement Proposals (FEPs). The first two deal with signatures and retires the earlier flawed LD-signatures. This allows the content owner to relay private content to other members of the conversation, while providing proof that the author is not being spoofed. HTTP-Signatures don't work in this context because the original author may not have granted third-party permission to access the content directly and may not even be aware of who is involved in the conversation. The audience belongs to somebody else. It is being relayed by the conversation owner who does have permission to access the content directly.
FEP-c390: Identity Proofs
FEP-8b32: Object Integrity Proofs
The next two proposals deal with working with contextual collections. In this body of work, every conversation is a collection. Anybody can create a post, but only the owner of a conversation can add a response message to their conversation and distribute it to a pre-defined audience. This is accomplished by turning the conversation into a Collection object.
FEP-400e: Publicly-appendable ActivityPub collections
FEP-7888: Demystifying the context property
The end result is that the fediverse is able to support a wide variety of interactions which don't fit in the microblog or 'Twitter' model of interaction. There also may be times when one model works better for some conversations than others. Perhaps a simplified description would be to call these "constrained" or "contained" conversations, and the traditional microblog usage might be called "unconstrained" because conversations and their audiences have no binding to each other. Contained conversations create this binding and creates a conversation as an atomic property in the fediverse. It is also possible to "fetch" this container and access the entire conversation (all activities and comments) across all participants. This is not practical or possible using the unconstrained model. In any case, this is what we're doing. It makes things like the old Google+ "circles" and features like Facebook style private groups available to the fediverse without clumsy workarounds.
And best of all, it doesn't break compatibility with microblog software. It just provides additional functionality and features which that model of interaction cannot provide, as well as allow both mechanisms to co-exist without breaking each other's expectations of visibility and privacy.
Or put in another light, we support all of Mastodon's weird and non-standard privacy modes because we choose to. Some projects do not, and this is permitted by the relevant specifications. This just ensures that everybody supports ours - because we aren't giving them a choice.
