This will be a much quicker post than the last two, and there’s a very good reason for that. You see, I’ve never implemented a spec before. ActivityPub isn’t the easiest, from what I can tell, and it’s exposed quite a few…deficiencies in my design for Themis. So, at the moment, I’m spinning my wheels a bit.
The crux of the issue is the way the spec expects me to communicate. ActivityPub uses activities for that (duh). These are objects with a number of properties, one of which is an ID. These have to be globally unique, and the easiest way to do that is to tie them to the originating server. So the server at example.com, for instance, can make IDs of the form example.com/activity/1234: the last number is different for each new activity, and it probably comes from the autogenerated database key. (An alternative is UUIDs, which I use elsewhere in Themis. Flake IDs—what Pleroma uses—are another option, if you’re looking for something that can be sorted chronologically, which is required by certain parts of the spec.)
So far, not so bad. But the AP spec wants these IDs to be URIs. And that means I have to format them properly. The problem is, a URI has a few necessary components. I have to account for subdomains, for instance. And the difference between HTTP and HTTPS, because somebody might use the former (I am for my dev instance, so why not?). Let’s not forget nonstandard ports, either. Listening on 80 or 443 requires root privileges on Linux, and NestJS defaults to 3000.
Putting all that together proves that my initial idea of just storing an origin host name alongside the names of groups and users is, to put it mildly, inadequate. Yesterday, I added a new Server object, which will store every part of a URI except the path. Hopefully, that’ll be enough to make ID generation a lot easier. And let’s also hope I don’t break too much in the process.
Anyway, once I get that done, I’m thinking the rest of ActivityPub will be relatively simple. Not easy, mind you, but I actually have made some progress on implementing the client-to-server portion of the spec, which is something even Mastodon isn’t doing. Give me a few more weeks, and I think I’ll be ready for Alpha 6. Until then, keep your fingers crossed that I don’t screw this up too much.