The Fediverse Challenge
socialhub.activitypub.rocks
In follow-up to the issues I outlined in the Mastodon versus Fediverse discussion, here I want to address an even broader, more urgent topic that I have been trying to put to attention for some time. What I find the most intriguing and challenging - and the general objective that SocialHub was created for - is not so much the individual choices of a FOSS project, but rather: "How to keep things moving and ensure Fediverse evolves in a healthy and steady way?" Whatever you think of Signal m...

Tooted here:

Recent talk on direction of #mastodon are not what’s most relevant for our #fediverse future. Decisions of an individual #foss project are theirs to make. More important is where fedi as a whole is headed to.

A “Tragedy of the Commons” is at play. #TheFediverseChallenge is to remain relevant and healthy far into the future.

Individualism only gets us so far, but for Mastodon and other federated projects their choices are understandable. But only teamplayers will win!

  • smallcirclesOPM
    2•3 years ago

    I don’t think I understand your extra layer.

    Think we more or less mean the same, but got stuck in the analogy :)

    In the interaction between apps we have the message formats, which for e.g. AS are well-defined. And then we have the semantics, which are only partially and more informally agreed upon and then mostly in a Microblogging domain (tooting). When things go slightly beyond that it becomes unclear. Like, say, Follow{Group} for one app might mean “I want to follow that group”, while for another app it may signify “I’ll join that group as member”.

    This is not a problem in itself if the semantics are really different between these apps. If the same semantics are implemented with different message formats and there’s no agreement what to use, then things become really hard to interoperate and for the fedi to mature. But this is the current situation. A developer either makes their own choice, or looks at another codebase and copies, or speaks to a random other dev and they align somewhat.

    Even this is not a real problem. A heterogenous Fediverse will facilitate many different app types and a universal agreement on semantics becomes nigh impossible anyway (striving for such a lofty goal is I think one of the reasons of the failure of the Semantic Web).

    Message formats and their semantics are domain-specific (I am looking myself into domain-driven design as a basis to model them). What we need is a combination of standardized AP extensions and better, more powerful ways of doing Capability Negotiation. AP extensions should be as small as possible, while still meaningful, and define a single domain concept really well. There’s no need to use an extension, but there should be a growing (crowdsourced) library of extensions to choose from. They are building blocks for federated app design. With AP extensions set up like that, the Capability Negotation need not be overly complex. It may start by asking Compliance Profiles from a remote endpoint: “I support SocialHub/Groups-1.0” and based on that you know what a Follow{Group} means.