So many AP platforms are made by a couple of guys in their garage, it’s not even funny, and the mentality of “just dicking around” means what gets used is whatever the whims of the day dictate, rather than the standard.
“If it works, it’s not stupid” and all that.
But that kind of work lacks real world testing, and depe concern for public expectaton or desire.
Plus, you have to keep in mind that the idea of interplatform interoperability isn’t this core conceit of ActivityPub. It’s a potential use case, but it’s not an expectation. There’s no reason anyone should expect interop like that, other than some developers wanted to try it.
But some didn’t, and now that their platforms are gaining audience, they’re refactoring to meet that audience’s expectations.
rikudou@lemmings.world 1 week ago
I recently did a library implementing pretty much the whole ActivityPub protocol and let me tell you one thing I’ve learned: ActivityPub is a half-assed unfinished mess.
It has so little constraints that pretty much anything is valid. You’d think that there was some logic at the core, but not really.
For example, there’s the Like activity, the name is pretty self-explanatory. But it’s valid to like anything. You want to like another Like activity? Why not! So you can like a like that likes a like…
Obviously, no real project implements such nonsense. But because almost everything is valid and up to interpretation of the implementer, there really is no single ActivityPub to implement that gets you running smoothly. There are many de-facto standards with various levels of compatibility with each other. Sending private messages is one such thing that many projects chose to implement in different ways.
Fun fact: Without implementing the HTTP Signatures spec, your app will not be able to send any activities to any software, because ActivityPub allows anyone to impersonate anyone, which obviously didn’t really fly with people developing actual software that uses it.
In conclusion, pure ActivityPub is an unusable mess in its pure form that literally won’t be able to communicate with other software implementing “ActivityPub,” so everyone is kind of implementing a similar slice/hybrid of ActivityPub and other protocols, but not exactly the same ActivityPub.
SkaveRat@discuss.tchncs.de 1 week ago
tried working on my own service and figured this one out very fast.
It’s amazing that it works at all. 98% of the stuff is not documented at all. and the stuff that is, can hardly be called documentation.
p03locke@lemmy.dbzer0.com 1 week ago
They have conferences about ActivityPub. Why isn’t W3C trying to fix this mess in newer backwards-incompatible versions? The time to do it is now, not later, because it would involve a major version and years of pushing for adoption. The lack of standardization of basic concepts is why integrations of different types of implementations is a broken mess, which is the whole fucking point of ActivityPub! Now, we have to compete with ATProto, which has different kinds of problems, and it’s very possible that it just wins out and kills ActivityPub.
This reminds of the early days of SMTP, where there was zero thought behind security, and that created an entire spam industry.
PeerTube integration into Lemmy is still shit, poorly implemented, and rarely linked by Lemmy admins.
Microw@lemm.ee 1 week ago
There are now Fediverse Enhancement Proposals (FEP) that are being published by Fedi developers with the goal to improve interoperability and well-being of diverse services, applications and communities that form the Fediverse.
Eibriel@sopuli.xyz 1 week ago
Email specs be like 👀
rikudou@lemmings.world 1 week ago
Can you send me some details at my totally valid email “Rikudou’s personal email”@5.75.133.3?
Eiri@lemmy.ca 1 week ago
Oof, sounds like we really need a new, better put together version of the protocol. I wonder if the W3C would be good to do that.
Zangoose@lemmy.world 1 week ago
Doesn’t W3C already maintain the ActivityPub protocol?