The complex ways of interpreting the specs

[how]

I find the discussion in FEP-1b12: Group federation very interesting and maybe there’s something cooking that goes beyond the topic of this FEP and would warrant a more specific topic.

@nutomic

Using the same approach as an existing implementation is always preferable because it results in better compatibility.

I beg to differ here. The “first to market wins” approach is not necessarily the best one. Your statement might be true for the ‘leading’ implementation, but that comes as a hindrance to some functionality, it may be invalid. Maybe an implementation path was chosen for reasons independent of the goal to stick to the specification. Many times people have complained that Mastodon has chosen ways that force others into a path away from the spec. This is part of the reasons why we have this discussion space and the Fediverse Enhancement Proposals process and lively discussion.

If someone comes with a real use-case and a good understanding of the specification that differs from the existing, it might be more work for all now, but the end goal might be better served. Maybe adding support to more open interpretations ends up being less work now than later on. This is all trade-offs, but stating that one way is better than another might end up being a mistake: the collective must evaluate, within the interpretation space, what option offers the most openings to further technological iterations.

The complexity of working in the open and with many different interpretations should not be a burden, as it is the force that makes fediversity possible and desirable.

[codenamedmitri]

@how +1, totally agree with your stance.

[aschrijver]

I totally agree as well. I put two different approaches before in:

@aschrijver

There’s multiple ways to get buy-in [for AP spec changes]:

1. For any proposal try to get consent of the big players, and if you don’t get it the proposal is a no-go.
2. Forge ahead with standardization, turning proposals into specs that make sense for the general dev ecosystem to adhere to. And as more projects do, they implicitly provide ever stronger incentives for big players to fall in line with those or become the odd one out.
3. The sweet spot between 1) and 2) I guess

If 2) happens insufficiently, then 1) is the only path left and new players will ‘follow the leader’ in post-facto interoperability.

We have seen over time that big implementations, like Mastodon, only opportunistically engage with the broader development community. Though that is fine- these are their own project’s consideration, after all - it is not good for open standards evolution.

Each project puts their own project-specific concerns first, but those should not be driving the ecosystem with “follow the leader” post-facto interoperability. If we want the most healthy ecosystem and see long-term interoperability improvements then the open standards should the source of truth, the place to look at first.

Right now I have a strong feeling that the post-facto Mastodon technology adoption is hampering the Fediverse from coming to its full potential.

Coincidentally Angelo Veltens today tooted a paper that has some strategies to follow to improve the situation:

Centralization, Decentralization, and Internet Standards

[indieterminacy]

[content-warning: rant]

Short termism is not our friend
Simplicity is a pseud and a fraud
Habits are chains

Societally wise its advisable to take risks, see what works and doesnt.

Viewing this video section explains it (from the perspective of the industrial revolution much better than I could:

$ mpv --start=0:38:21 https://archive.org/details/the-ascent-of-man-ep8

Innovation and technological advancement is not linear, it doesnt even have to be rational.

From the same, documentary, see this point regarding how wasteful the use of automation by earlier French society was (relative to our later adaptation of these concepts).

$ mpv --start=0:07:25 https://archive.org/details/the-ascent-of-man-ep8

There is a major misunderstanding in modern societies as a consequence of business management practices, infantalising both management and the common worker:

• If you want to understand complexity, ask a frontline worker about what frustrates them about their job.
• If you want to uncover simplicity, follow up by asking them how they would solve such problems.

To think in terms of first movers and early advantage when discussing technology is a moot point and tabloid behaviour that distracts from technical details and discussions about democratizing technology.

If we want to have solutions that have full utility and are societally advantageous to all then we are lacking. Do all stakeholder groups from having an awareness of:

• what something such as ActivityPub is?
• what the specifications are?
• and how they can be used?

Only when people from all backgrounds are able to make ActivityPub their own will we know what is truly successful.
Atm, we are working off heuristics, if not our own biases.

Until this is achieved we should:

• Be informed regarding distinctions between functionality and habits;
• Be creative;
• Document our understandings and functional opportunities so that people with new perspectives can make the next leaps with greater clarity.

As such SocialHub is useful, not only in terms of providing an open forum for discussing techological aspects of ActivityPub but doing so in a way in which both ATL posts and BTL comments are easy to link to and reference across a range of fediverse and unfediverse environments.