Post
Today we have #ActivityPub, which provides real and actual #Federation, but is overly complex and difficult to implement, and we have ATProto, which promises Federation, but delivers central control and is even more complex and difficult to implement.
See this discussion (you'll need to scroll down a bit to find my contribution):
> https://circumstances.run/@davidgerard/115335451897410462
Dave Winer would love the point I was making there…
[contd]
Why do I say #ActivityPub is overly complex and difficult to implement?
I'd need to get into some very geeky weeds to explain exactly why and I'm not going to do that on a thread. But, suffice to say, there's only a small number of full-featured Fedi implementations out there for a reason. And every single one of them is using a protocol implementation directly tied to their overall implementation.
This has been pointed out before:
> Playing with ActivityPub. https://macwright.com/2022/12/09/activitypub
[contd]
In fact, the closest thing we have to an ActivityPub *Reference Implementation* is the Express ActivityPub Server, which hasn't been updated recently and is only a *partial implementation*:
> https://github.com/dariusk/express-activitypub
I probably don't need to make the following point if you are a coder, but for the peanut gallery: Every substantial and mature protocol comes with a *Reference Implementation* as a testbed. And, by extension, this means ActivityPub is neither substantial nor mature.
[contd]
Am I dunking on ActivityPub right now? Well, yeah, I guess I am.
Do not take this to mean I think we shouldn't be using ActivityPub. Hell, I'm using it right now! I'll take something that works over promised Pie in the Sky or 'doesn't actually deliver' any day. I'm not stupid.
Here's the problem: I can't easily roll my own Fedi servers. There is no such thing as a 'generic, but tweakable Fedi server' and there are no libraries implementing the server protocol without baggage.
[contd]
A space for Bonfire maintainers and contributors to communicate
