Please fasten your safety belt and put your seat tray in the upright position.
There've been a lot of developments on the Zot6 front in the last week. I'm not even sure where to start. OK, let me start here...
If you are interested in a "fediverse" of "social networking projects" which can all communicate and work together seamlessly, it is time for you to get off the Zot6 train. It is not stopping at your station.
Zot6 is standing up for the right of people to have nomadic identities, privacy, and granular permissions over their profiles and content (including their media content). It is also standing up for the right of people to not be forced to accept spam or unsolicited replies to their content from people they don't know or never heard of (or who they have even *blocked*). Unfortunately these rights are incompatible with the rest of the so-called "fediverse" (and "federation"). Hence all connections to those networks are being severed.
The repository for Zot6 things has moved. You'll find packages at https://framagit.org/zot
- and not everything has been relocated yet.
Webpages for different projects and efforts can be located at https://zotlabs.com
Osada will be spun off (separated from Zap) and officially abandoned. If you want to take over the project, go for it. The implementation of Zot6 there is now frozen because future Zot6 work (and Zot8 - more on that in a moment) will not be compatible with ActivityPub. At all. As far as I know Osada is the only viable ActivityPub server for events and groups, but Friendica and Hubzilla aren't very far off.
[Zap - going forward:]
Posting to groups/forums via tags will be removed. You can post from the group "wall" if you are a member. The reason for this is that you can get into unresolvable permission conflicts between your personal channel and the group. This also radically complicates message delivery.
Zot6 uses Activitystreams (not ActivityPub) as a serialisation format. The actor/object model may be elegant for expressing content, but it falls on its face when relayed between two actors with different permission expectations. ActivityPub folks haven't encountered this issue because they have no working permissions system.
ActivityStreams also cannot express nomadic content. In a network built on nomadic identity, you need content to be retrievable even if it moves, and the ID of that content must be DNS independent.
As a consequence, we are re-evaluating ActivityStreams as a serialisation format. We may be able to keep it with some additional modifications, but all options are on the table currently. The end result will not be zot6 compatible, so the new work is being called Zot8. (Zot7 will be the intermediate development work leading to Zot8).
There are a number of potential approaches/solutions to the issues we've encountered. Currently it appears that we will require a dedicated 'Relay' mechanism which differs from known existing relay mechanisms such as LD-signed activities and 'Announce' activities. This still has not been specified but basically needs to express the concept of "I'm sending you this content that somebody else created (attribution attached), but followups must return to me and use *my* permissions". It appears we can emulate this behaviour in ActivityStreams, but not using the current relay mechanisms. So the mechanism to do this must be formalised.
We may be able to use a custom protocol handler to specify nomadic content identifiers and still cram it into the ActivityStreams specification, but resolving that content will need to be done "at runtime". I'm currently looking at adopting selected P2P technology on top of the S2S stack to locate and deliver nomadic content (e.g. Distributed Hash Tables, Route tracking , etc.).