RE: https://mediaformat.org/2026/05/posting-from-c2s/

Hey look, first post from a custom client using ActivityPub API

#activitypub #c2s

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

8.1.0 — By the Numbers

https://activitypub.blog/2026/04/22/8-1-0-by-the-numbers/

there is now also an english version https://changinggraph.org/en/index.html

#changinggraph #rdf #activitypub #c2s #fediverse

🎉 JEU CONCOURS 🎉

Envie de repartir avec un beau panier de légumes frais
d’une valeur de 30€ ? 🥦🍅
On a peut-être ce qu’il vous faut !!

👉 Pour participer, c’est simple :
✔️ Like ce post
✔️ Commente en identifiant 2 amis
✔️ Abonne-toi à notre page

📅 Tirage au sort le 03/04
📍 Résultat annoncé ici et au marché de la Chaponnière

Bonne chance à tous !🍀
#fyp #jeuxconcours #legumes #panierlegumes #bio #BioLocal #produitslocaux #produitslocaux #frais #marchelocal #c2sservice #C2S #jeux #jeu

(digital) doodling a little

#c2s #activitypub #ios #fediverse #wordpress

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse