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!

  • @Liwott
    2•3 years ago

    If you want to talk to someone else on the internet, even if you both speak the same language, then there is no direct path. You have to talk to an intermediary: the machines, which speak an entirely different language

    I was more seeing the following : even if we have similar sensations (that’s the applications’ use cases), if we need to communicate them to each other we need an intermediary : the language (that’s the protocol). People who speak the same language (French, or Lemmy-flavoured AP) will be technically able to understand each other’s experiences, but will only be able to communicate partially with speakers of English (or Mastodon-flavoured AP). For example, how do you explain the concept of cross-posting to an English-speaker?

    I don’t think I understand your extra layer. I mean, I don’t think that information is actually lost by a lower level language, but rather that all the information loss comes from those different dialects of AP. I may be completely wrong.

    In a diverse landscape and culture, even with an open machine “language” / protocol, you get a lot of different flavours.

    Agree, and probably even because you are using open protocols (as in the following Facebook example). This seems to be one of Signal’s reasons not to federate.

    Facebook has the largest social media userbase, but they can exactly dictate what language is spoken by the machines, so they don’t suffer from this issue.

    Indeed, that’s mainly why I used English=Mastodon rather than English=GAFAM and Esperanto=Mastodon, which is probably more suited for other aspects. For example, they probably share the position of a flawed open-door to the niche of the Fediverse/conlangs. My last point is probably also better put in that context : the way to go may be to follow closely the user-filled Mastodon (or Esperanto) while forking to adapt the features we don’t like (either adding stuff, or slightly changing it)

    There’s very little interop at all currently

    I guess “very little” is quite subjective. For example, AFAIK, Friendica and Hubzilla allows you to follow activities on at least 7 (not Lemmy, don’t know about WriteFreely and Plume, the others I think so) of the 10 most used fedi platforms, which I wouldn’t call too trivial. Again I may be completely wrong.

    But I do get your point that most interoperability is currently limited to social networking (and even that is far from done), while there’s more potential uses for AP.

    • 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.

    • @Liwott
      1•3 years ago

      My last point is probably also better put in that context

      Although it did also make sense the way I originally meant it : Esperanto would be a more app-agnostic implementation of AP (for example one to be developed on SocialHub), people would still find imperfections and the way to go may be to mostly follow it for interoperability while doing slight adaptations.