Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards.

[profpatsch@mastodon.xyz]

Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!

https://coding.social/blog/grassroots-evolution/#fediverse-tomorrow

#activitypub #fediverse #FEPs #fep #fedidev

[profpatsch@mastodon.xyz]

I'm thinking of replying in a blog post as someone who has spent the last three months actively developing a fediverse application (#flohmarkt).

But the most critical thought: I miss a discussion about reducing implementation complexity as much as possible. The standards leave much "wiggle room" for implementation, which I think is partly to blame for the "whack a mole" nature of support

[profpatsch@mastodon.xyz]

Things that come to mind:

* Inbox signature validation is very vague
* jsonld is a complex standard that introduces a need for libraries, leads to slowdowns and blows up the implementation surface
* Interaction schemes like quoting requests lead to nontrivial state machines

In general: any MAY in a definition explodes the possible things that can go badly.
Which is why I think we need to use a different approach from how e.g. RFCs are structured

[smallcircles@social.coop]

@Profpatsch

Hey, thank you! Delighted you found my article even before I announced it on fedi

https://social.coop/@smallcircles/116379158584600016

Thus far my poll on readership found 4 Meh skips. AI vs. long handcrafted thinkpieces: 1 - 0?

We'll see. Finding that out is also SX, after all.

[profpatsch@mastodon.xyz]

@smallcircles heh, I thought I had missed the Fedi announcement because it was already there

[Guest]

@Profpatsch A lot of effort is being put into reducing implementation complexity - it is just not very visible. Libraries, testing tools, documentation (such as the guide that I mentioned during our previous conversation).

However, the complexity is unavoidable in a decentralized network. A standardized representation of a quote (FEP-e232) was proposed long time ago. It was easy to implement, versatile (FEP-e232 could be used to build any kind of link, not just a quote), and it was supported by a significant number of fediverse projects. Then Mastodon developers decided to invent a different kind of quote, with all the unnecessary complexity that you described. But I'd rather deal with this complexity than have some centralized standards org telling me what to do.

Another issue is disinformation -- and that is really weird, and unique to Fediverse. You probably heard that JSON-LD is required, but that is not true. The spec doesn't require it. Only a few Fediverse projects actually use JSON-LD, and as a developer you don't need to worry about it -- adding "@context": "https://www.w3.org/ns/activitystreams" to your JSON makes your software compatible with >99% of Fediverse instances, and even that is only necessary because Mastodon has a bug. Unlike the problem of competing standards, this problem can be solved by writing better documentation.