I’ve spent the last couple years or so digging into standards and playing around with Perl libraries and it’s probably about time to buckle down, stop chasing the new hotness, and build some working code. So here’s the plan.
As I’ve mentioned here and there, my goal is simultaneously absurdly unachievable and very modest. On the one hand, I want to destroy Facebook.
On the other hand, I just want a little standards-compliant blogging software that’s easy enough for my mom to keep up with and comment on.
So here’s the plan.
If you think about it, that’s what Facebook is. That’s what Twitter is. And so forth. It’s a platform where you read stuff other people have written, and you write stuff.
This is tough because most of them have TOS’s and API’s that are explicitly designed to prevent silo-busting clients. But if it can do no more than read Facebook, for instance, that’s still an improvement. Imagine being able to control what appears in your timeline!
Furthermore, though, it allows owning your words - you don’t need to rely on Facebook’s export function if your client has been maintaining a local copy of everything.
TL;DR: It will use machine-readable, extensible standards so clients can proliferate yet users don’t have to wait for their favorite to update to the newest features.
Clients can (and should) customize their interface for posting different types of content, but in a worst-case scenario the machine-readable standards mean the “API” can change without breaking anything. For instance:
Organizationand display it accordingly, adding the clarification provided by the standard:
The media network(s) whose content is broadcast on this station.
BroadcastChannel, and that http POST is allowed to this page, so it knows that it can offer the ability to add
A unique instance of a BroadcastService on a CableOrSatelliteService lineup.
BroadcastChannelis, so it looks up the standard and knows that the form it offers its user should be a text field for
broadcastChannelId. It can also offer the user the text explanation of what should go there:
The unique address by which the BroadcastService can be identified in a provider lineup. In US, this is typically a number.
The client might present form fields in a generic (alphabetic?) order, leaving it to the user to figure out which ones are most important, but it’s better than nothing. (And perhaps there’s a
wirebird: standard where the client can look up templates for new standards, and apply them without having to do a software update.)
ActivityPub has a machine-readable structure, so it will fit into the above interface, structurally. Layering the ActivityPub API’s onto it will allow federation with Mastodon, Aardwolf, and anything else that uses the standard.