I heard often about activityPub being challenging to implement.
Now I know part of this is because, if you are building on activityPub, you want interop with existing platforms such as mastodon, and they do their own thing.
But ignoring that aspect, what is so hard about activityPub? What could have been done better?
I am a software developer, so feel free to use software dev concepts and terms when explaining. Thanks!
I don’t think ActivityPub is hard to implement, actually. It’s fairly specific JSON with a weird structure, but that structure isn’t hard to implement.
It does come with an oversight, though; the protocol doesn’t define how to ensure activities propagate to every server. That’s why following a Lemmy community from Mastodon will spam your feed with boosts, and why Mastodon instances all have different amounts of comments and likes on them. Some other things are also underspecified (like how to propagate creates through boosts, are those two events of is boosting a create enough?). These can use some fleshing out.
One thing that’s definitely underspecced is the client-server API. It’s practically impossible to take the spec and write a client for a C2S server that’s also built around the spec, because crucial things like “authentication” simply aren’t specified. Very few servers bother to implement C2S and even fewer of those cover more than the bare basics.
At some point I tried setting up a sort-of-tumblr clone by combining Fedibox with a C2S client, but I found it impossible to set everything up properly, and no other backends seemed to provide more than a basic C2S implementation. There’s potential there, but it’s hard to do it without an opinionated take on the spec that I feel shouldn’t be necessary.
the protocol doesn’t define how to ensure activities propagate to every server.
Outboxes are kinda that, but as I understand it mastodon’s implementation is deliberately defective.
They do describe well how “I post something on your timeline” works, but details on “someone else boosted a like on my timeline and I want to inform your server” isn’t as clear.
Lemmy posting boosts of every single activity to every following server is one way to get every server synchronised, but it feels a little like abusing side effects rather than using the protocol as designed.
Unless two instances had the exact same set of servers they’re federated with then I wouldn’t expect any given content to have the same number of likes/comments/etc when viewed from different instances.
What were some of the reasons as to why you “found it impossible to set up everything properly” re: C2S implementation? I’ve been trying to figure out why the C2S isn’t being adopted, as I think it solves many of the fediverse’s current UX challenges
The lack of server implementations is one of my issues. Fedibox seems to have the most complete implementation but I struggled to make it work right. Other implementations seem to expose some endpoints, but only the ones relevant for their platform. You can’t make a Lemmy client for a Mastodon-like because of that, nor make a Lemmy-like with a timeline.
The complete lack of standardised authentication made me give up. Every application has its own auth mechanism (with 2FA being even worse).
I also found it difficult to figure out the media storage API, if there even is one. AP describes a lot of JSON structures, but it wasn’t immediately obvious to me how I uploading images and videos would work. I suspect the answer may be “it doesn’t”.
What also doesn’t help is that as far as I can tell, none of the servers are fully compliant with even the S2S spec, which makes me suspect it’ll be difficult to get the full advantage out of the C2S API (as they don’t forward direct activities, but deserialise S2S content into their own representations and then serialise that back for the C2S API).
At some point, I experimented with an idea of “the ultimate ActivityPub server” that would speak as many protocols as possible. My idea to an approach was to use Fedibox as a backend, and write a web “frontend” that implements the Mastodon/Lemmy/etc. API, communicating through C2S to interact with the backend that deals with federation and all that complicated stuff. This way, you could use your Lemmy/Mastodon apps with one single account and one single message inbox (and maybe even a virtual timeline on the Lemmy side?).
To get started with the protocol, I tried to write a small C2S client and that’s pretty much where my efforts died. I didn’t feel like implementing S2S ActivityPub as well, I didn’t want to use Go (so extending fedibox wasn’t what I liked), and none of the other servers seem to implement ActivityPub in a generic way.
However, I am hopeful that there will be more options for APIs and apps once someone implements a good client and describes a good way to set up a server. I don’t have time to develop full proof of concepts like these anymore, but I’m sure someone who does will be able to revive the C2S API by just… figuring out the annoying work.
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.
