i wrote a blog post about activitypub! i promise it's different from everyone else's blog posts about activitypub, probably!

many thanks to @cwebber for inspiring me to write this

@kity @cwebber I've read your post and while I understand the intent, I have a really hard time figuring out how generic ActivityPub client could work and be useful.

In my mind, ActivityPub deals with the transport/data layer by providing a standard way to represent objects, activities and broacdcast those over the federation.

But how can a client implement a generic and meaningful UX for every server?

@kity @cwebber Sure, you could imagine writing a client that could post to both Plume, Mastodon and Pleroma servers, assuming they support C2S protocol.

But Plume supports Markdown, while Mastodon doesn't. I don't know for Pleroma but you get the idea.

How would the client know what the server support in terms of features?

@kity @cwebber also, projects handle different types of data.

Funkwhale and PeerTube instances deal with Audio and Video media, respectively, PixelFed with images, Mastodon and Pleroma with small-to-medium text, Plume and Write.as with long-form content, etc.

Do you think it's possible to provide a unique and comfortable experience for all those projects ?

@eliotberriot @cwebber so i think you've got it a bit backwards here; i'm talking about a generic *server* that can (extensibly) route and handle anything a client sends. in this scenario, your client could be the mastodon interface, which is great for microblogging, but you could also use the peertube interface to post and interact peertube content. in this world all activitypub servers would basically be "generic" reimplementations of the same concept, and the clients would differentiate how you interact with the platform (moving the user-agent aspect from being embedded in the server to being a user-controlled aspect)

@kity @cwebber thank you for the explanation, it's clearer now. So pretty much like XMPP servers like Prosody from what I understand?

@eliotberriot @cwebber i'll be honest i've never used xmpp before, but someone else might have an answer 😅

@eliotberriot @kity @cwebber *maybe*? i'm not sure to what extent xmpp servers store data and how, but i'd say probably in the sense that email servers can host your emails and xmpp servers can host your messages.

a generic AP server would at minimum handle delivery of AS documents generated by the client -- the recipient can parse and validate, perhaps the server can tell the client whether the response was 200 OK or if there was some error (i.e. "was this message delivered successfully?")


@eliotberriot @kity @cwebber so in that sense it would be delivery server only (like SMTP) but then one step above that would be to have the server also manage data *storage* and not just delivery (a la IMAP).

in that case, the server stores your inbox and outbox and all the AS documents and Activity stuff, and allows fetching the content on valid GET requests. but there is no standard authentication/authorization flow, so we're kind of limited to allowing public fetching if we want full compat

· · Web · 1 · 0 · 0

@eliotberriot @kity @cwebber as far as the client would be concerned, the generic Server doesn't have a way to dictate limitations. but rather, the client would fetch only the AP documents that could be validly displayed within that client. so if the client wants Note objects under 500 characters, it would get your inbox and filter for Note type, then filter for length.

that's kind of wasteful i guess? which is why most AP projects chose to reject incoming Activity that they don't understand.

@eliotberriot @kity btw @cwebber feel free to correct me if i'm wrong, this is just my understanding of what a generic AP server would be like :)

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!