I wanna do an ActivityPub API that's really just that... a robust, general purpose backend capable of serving a variety of client apps.
Maybe v2 would have customizable API for compatibility with existing clients.
First things first though... I checked with Awesome ActivityPub to see if there were any active projects already doing something like this that I could just jump in on.
Different clients are going to have different requirements, right? A macroblogging client has different needs from a microblogging client, and both are different than the threadiverse, or something like PixelFed. Even Mastodon has different reqs than Sharkey between the backend instance and the client.
And yet, the backend's relationship with the Fediverse, itself -- via ActivityPub -- is very similar in each case.
An AP-based backend is basically a two-faced API. One API faces the client, and the other faces the rest of the Fediverse. This project would provide a robust, configurable backend for a variety of frontend client implementations.
Then AP-based applications could focus on the frontend.
More I think about it, the more I think it's a good idea, and right up my alley.
Like an ActivityPub framework, made for web devs, not users. Due to the nature of AP, it would have to be configuration-over-convention (more like Django than Flask), but theoretically it could do all the heavy lifting between client-server and server-fediverse APIs.
Devs would have to do a bunch of config to say "this server will map these APIs in this way," but a lot is going to be boilerplate and mappings with transformer callbacks and the like, right? It would reduce the work for new implementations, and reduce idiosyncratic client-server-fediverse implementations.
I'm open to suggestions, here! Or any feedback. Would devs find this interesting? Maybe they would consider it for an AP-based project? What language? I'm most comfortable in Python, but by nature this project would need multiple elements, and many pieces could be fulfilled by already existing tech.
It sounds like a transformation layer between APIs to me, which means it could be systematized and implemented in multiple languages. A set of SDKs?
Yeah... that's the approach to take: a backend like this is gonna be a docker compose kinda thing, with orchestrated pieces, anyway... regardless of language.
Python's a great language for prototyping, so with the SDK idea in mind... anything written in prototype Python that is not public in the SDK could be rewritten later in another (faster) language -- either piecemeal with C modules or in entirety.
I'm just spitballing, here, but I'm really warming to this idea.
@notroot there'd definitely be a need for what you wanna achieve. However, you will also find that what you want to build isn't straightforward at all, and you are working with the rough outline of an ultra-flexible protocol framework that still has a lot unspecified.
I'd advise joining #SocialHub and/or W3C SocialCG. People to follow are @helge (AP + Python) @hrefna (FeatherPub) and @steve (AP Linked Data), among others, who explore this space.
@notroot@smallcircles Are you thinking of an AP Client-to-Server extension or a completely custom client API like Mastodon's (which supports many client implementations but is focused on microblogging)?
@steve@smallcircles I'm thinking that, out-of-the-box, it could provide a basic, vanilla AP client-server API to get a project going, but that the power of such a project would be in customizing that API to work with different client API requirements -- including pre-existing APIs like Mastodon's.
This is all very much in the "Big Idea" stage right now, and a couple folks who clearly know more than me have already warned me that it's gonna be hard.
Add comment