Fediverse
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
I've been in tech for multiple decades, and when I looked at the structure of the JSON and the developer documentation, my eyes glazed over and I bounced off of it. It's worse than "not elegantly designed", it's (in my opinion) kinda slapped together without much thought or testing. This is a thing seems to me to have been a side-project that had some anemic interest for a long time, then became spontaneously exponentially popular on accident (because of a dying bird and a terribly handled forum API), and now it's just sunken cost.
https://www.w3.org/TR/activitystreams-vocabulary/#actor-types : this is a fucking nightmare, and almost all of the decisions here are completely arbitrary. Like, seriously, what the hell is this?
There's also no real reference implementation, so it's almost guaranteed that various apps won't be able to talk to each other without some kind of translation layer (See: Mbin's implementation of a Mastodon-like microblog). Mbin/Lemmy/Mstodon/etc don't even have agreement on how likes, votes, or boosts work. User addresses are also wacky; Is it @someuser@server.tld or server.tld/u/someuser ? Both?
Why is it hard to implement? It's not really a standard, it's a college dorm data-structure fan-fic that wished it was RSS with a like button (and a bunch of other buttons that apparently no one needs or wants, since no one uses them). I'm utterly flabbergasted that the w3 published this. Like, there's literally a section on Spam that just kinda says "figure it out yourself". This is a useless document, which also hilariously contains an entire section of self-congratulation for a "standard" that hand-waves things like how to handle a DOS and doesn't even bother suggesting a method of authentication since their "years of hard work and experience by a number of communities exploring the space of federation on the web" couldn't agree on one.
What could have been done better? Having consensus from a larger group of better developers during the protocol phase (mostly to weed out silly crap that isn't useful, and actually defining - you know - a standard), and some decent time in the oven for server implementations before millions of people flooded into a series of barely connected instances that are running software that isn't really ready for production (many of which are really close, but are hamstrung by this awful protocol).
Not even more than ~one page in and I see this
IntransitiveActivity
Inherits all properties from Activity except object.
??? That's not how inheritance works in any language I've worked with lmao. One of the most basic types in the language and I'm already debating the pros and cons of different designs. Should I make the inheritance work with the type system and just return null for or should I add my own dummy types that aren't in the spec so that it's impossible to get an object property from IntransitiveActivities?
I think the biggest issue is HTTP Signatures - they're not part of the standard, they're not well-documented, and without them your server won't federate with anything and so you have no idea whether it works.
Plus sometimes an implementation works with Mastodon but not something else. I think Mastodon just uses certain headers when calculating the signature, but Bridgy Fed also includes the URL or something. The C# code I'd copied was programmed to exclude the URL always, so I had to change that, but it took a while to figure out that that was the issue.