#c2s — Public Fediverse posts

FediCon / FOSSY

Excited for FediCon 26!

I’ll be giving a talk about the ActivityPub API

My talk will explore the challenges of building a general-purpose client using ActivityPub’s Client API.

https://2026.fossy.ca/schedule/presentation/460

Cacheable Requests for Remote Content

TLDR: proxyUrl requests are un-cacheable, this is a terrible Developer Experience.

When fetching remote Activities, Objects or Actors with the ActivityPub API we use a few endpoints. First, we might fetch activities directly from our Inbox endpoint, this loosely translates to a users Home feed.

But to represent these Activities in a meaningful way to users, we also need information about the Actor who posted the activity, so that we may display their Avatar, Display name and perhaps their Webfinger1.

We could fetch an Actor directly from a client, but not all ActivityPub servers are guaranteed to have CORS enabled. So to reliably fetch, we use the proxyUrl endpoint2.

… the client posts an x-www-form-urlencoded id parameter with the value being the id of the requested ActivityStreams object.

Unfortunately POST requests are opaque regarding the id3.

Typically, a Service Worker would use a fetch eventListener to intercept the request, and depending on cacheing strategy might first look up this id in the cache, or indexedDB, and if it isn’t found would then fetch and save response for later use.

So back to our Home feed, when scrolling through the activities you are likely to see a number of posts from the same people, whether because you only follow a few or because you follow some frequent posters.

Without cacheing, our app would need to fetch those Actors again and again, each time one of their posts shows up. Also, depending on your server configuration, could get your client rate-limited.

Beyond ActivityPub, not cacheing is wasteful, these continuous requests could not only make a low-powered device slow-down, heat up and drain a mobile battery, but depending on internet access where you live could also eat into your data plan.

1. Webfinger is an identifier & protocol for looking up information about users, which should look familiar: [email protected] ↩︎
2. https://www.w3.org/wiki/ActivityPub/Primer/proxyUrl_endpoint ↩︎
3. Basically a URL: https://www.w3.org/TR/activitypub/#obj-id ↩︎

@steve @hrefna

Perhaps @kopper is looking in the direction you are interested in, with the 'ois' C2S AP project:

https://codeberg.org/outpost/ois

As written in the README:

> I want to act on an idea i had and slowly refined in my head for a while now, on making an AP server whose only job is to handle actors, leaving all the indexing of reply trees and other "actual functionality" to other services an actor could log in to (if it sounds familiar, this is a C2S server. Or an ActivityPDS if you don't care about worthless protocol wars and like to keep up with what the other side is doing).

#ActivityPub #SocialWeb #C2S #ActivityPubAPI

Hello World

Coucou! This is just a first post announcing Nuages to the world.

Nuages is an ActivityPub app, connecting to your favourite servers that support the Client to Server API.

Follow us to get our latest updates, we’ll be officially launching the app in the coming weeks 😉

#ActivityPub #c2s #ActivityPubAPI #Fediverse

The ActivityPub API doesn't define a way to get all server known posts with a specific tag.

There are a few ways this could be done in an ActivityPub client

What behaviour would you prefer when clicking on a post Tag link?

(Any other ideas, comment)
#ActivityPub #c2s #activityPubAPI

Working on Poll/Question for ActivityPubAPI, it looks like Mastodon is sending an update after every single vote in a poll, presumably for an accurate vote count!

#c2s #Mastodon

I tried to implement the "standard" ActivityPub #C2S API in Mitra.

It's an interesting exercise, but I am not sure if I'll ever enable it by default. Permitting clients to publish arbitrary JSON is equivalent to allowing them to publish unsanitized HTML. This may be acceptable if you're an admin on a single-user instance, but it is a really stupid thing to do when there are multiple users.

Although it might be possible to validate activities using strict JSON schemas, that would require a lot of work. You may as well create your own API that will have none of those issues.

FEP-ae97 API is also tricky to implement, but at least it offers a genuine advantage over regular REST APIs: nomadic identity. Also, its security is more straightforward because portable actors and objects are namespaced by DIDs.

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

@steve @hongminhee

I mentioned this thread in the #ActivityPub #C2S tracking issue. I think there's a fundamental risk that C2S is going sideways because of misconceptions between devs on where things are / should be headed.

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130#issuecomment-11737818

@tobias

Maybe #bovine is, what you're looking for.

https://codeberg.org/bovine/bovine

#python #activitypub #c2s

(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

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

The intro to HDA (Hypermedia-Driven Applications) I've been raving about today seems relevant to the ongoing discussions about C2S APIs for the fediverse, especially the proliferation of the monolithic server+web-app antipattern. I've started a SH topic on it;

https://socialhub.activitypub.rocks/t/could-hypermedia-driven-application-architecture-be-useful-for-ap-c2s/8521

But SH seems like a ghost town ATM. Tried to post on ActivityPub.space but their interface hates my mobile browser (Fennec from F-Droid) 🤷‍♂️

#FediDevs #ActivityPub #C2S

ActivityPub client developer experience is something like this.

Building a coherent feed with stateful objects requires comparing an Activity from the inbox, with what’s in your outbox.

#ActivityPub #c2s #DevEx

Have I already mentioned that the “Show thread” request is slowly driving me crazy?

#c2s #activityPub #fep7888

I opened a issue in the swicg ActivityPub API repo about a gap i keep running into: how does a C2S client access server-local metadata about foreign objects?

Thread collections, read status, notifications — your server knows things about remote objects that the client needs, but AP has no vocabulary for it.

https://github.com/swicg/activitypub-api/issues/60

#ActivityPub #Fediverse #C2S

@evanprodromou

@django @evan @liaizon

Hey, this is great. It is so nice to see the uptick of interest in the #C2S part of #ActivityPub. Very uplifting and gives me hope for the future of #fediverse.

I really liked your #FOSDEM presentation, and thank you for mentioning my humble list. They are just notes atm, but I will try to keep them up-to-date. I just made a bunch of updates..

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

Would love to hear more on what are the particular plans and goals for your project in the near future?

@kopper @nelson

This is marvelous. I wasn't aware of your project, but now I am and added it to the #ActivityPub #C2S tracking list.

I've also lined up #Outpost for inclusion on the delightful #fediverse curated lists at https://delightful.coding.social

Bring it on!

#ActivityPub Social API is getting a lot of attention and traction on the implementation side! 🎉

Join the fun, in this area where there's a fine future for the #fediverse social networking.

Some new updates to the list of client-to-server #C2S parts of the AP open standard:

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

Added the projects of @kopper and a new C2S article by @django

@pfefferle @steve @mariusor

This is wonderful! I updated my #ActivityPub #C2S notes with link to the PR..

https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130

thanks to the awesome support of @steve and @mariusor the #WordPress #ActivityPub #C2S API support is quite solid now.

It is possible to publish a new post, comment to posts and other comments and to follow others.

https://github.com/Automattic/wordpress-activitypub/pull/2851

@i47i @HolosSocial @apps

PS. I track a list of #ActivityPub #C2S implementations and didn't add #Holos till now. If I should add it, pleas let me know, or comment directly to the issue.

https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130

Roadmap 2026 — Charting the stars of the open social web

https://activitypub.blog/2026/02/11/roadmap-2026-charting-the-stars-of-the-open-social-web/

I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.

On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.

On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.

As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.

My fosdem talk is up!

I make a case for more platforms to support the ActivityPub client API, and how we should look beyond microblogging for future growth of the ‘verse

https://fosdem.org/2026/schedule/event/QK7XSV-activitypub-c2s/

#c2s #fosdem #fediverse #ActivityPub