We Distribute

2025-08-29 22:53:02

Social Web Foundation is Betting Big on Client-to-Server API

From the outside looking in, it can sometimes feel unclear as to what steps the Social Web Foundation is taking to achieve its goals. The non-profit organization’s About Page states lofty ambitions, such as bringing together implementers to build tools, policies, and protocols to advance the Fediverse. The Projects Page includes End-to-End Encryption, a Fediverse Starter Page, GDPR Compliance, and Long-Form Text.

However, the SWF has been working on several interesting projects outside of these stated scopes, and it’s something Evan Prodromou has been bullish about: leveraging the ActivityPub Client-to-Server API. Historically, this piece of the ActivityPub protocol is rarely ever implemented, due to complexity as well as the fact that Mastodon’s own client API has seen widespread adoption.

A quick ActivityPub C2S primer

To really understand the C2S API, we have to go back in time to when the protocol was being developed. The basic concept was that any ActivityPub implementation would effectively act as a generic server, with clients providing unique experiences. Compared to Mastodon’s dedicated API, C2S isn’t explicitly limited to microblogging or statuses. Instead, clients dispatch activities to and from an Actor’s inbox and outbox.

Instead of every new social experience in the Fediverse acting as a bespoke server, the C2S API instead lets a wide range of clients interact with an instance. Instances no longer become specific delegates of what activities can or cannot be used. C2S opens the floodgates for any kind of application to hook in to a Fediverse account. Instead of an instance doing all the hard work, clients would handle much of the advanced logic themselves.

spectra.video/videos/embed/1FR…

There is a meaningful parallel to ActivityPub C2S, and oddly enough, it can be found within the AT Protocol’s ecosystem. Boris Mann presents a fantastic talk that shows radically different sets of apps that all do very different things, some of which have their own social graphs, leverage unique kinds of data, or offer interactions not available in other places.

Social Login

Setting aside unique applications for a moment, one of the key killer-features that ActivityPub C2S could offer the Fediverse is a coherent and streamlined login system for any Fediverse account.

I don’t know what this thing would look like or what we would collectively call it, but here’s some ideas.

This idea is actually not new. Pump.io, the prototype that largely became a foundation for ActivityPub’s design, offered the ability for people to remotely sign in to any other Pump server, using the account that was local to them. This was initially designed to let people interact with remote objects that their own instances had not yet collected.

Pump crawled so that ActivityPub could run.

The idea of a unified method for Social Web logins is extremely compelling. Right now, a lot of Fediverse apps offer platform-specific sign-on, leveraging a bunch of different APIs.

GreatApe, an upcoming media platform, offers four different ways to log in through the Fediverse.

The upside of this approach means that more apps and services can just let people sign in with their remote accounts, without creating a local account there. The downside is that it adds to the maintenance pile, because of how many different platforms exist within the Fediverse today.

What is the SWF is working on?

There are a few experimental areas where the Social Web Foundation is focusing on building up, so let’s talk about them. The main thing to understand is that these are building blocks, meant for iterative development and discussion with the wider community. As time has gone on, these projects have become more ambitious, and exist to showcase what’s possible with the C2S API.

Places.Pub – GeoSocial Data

Places.pub is an attempt to marry OpenStreetMap data with ActivityPub by using specific GeoSocial parts of ActivityStreams. More specifically, it uses these vocabulary words for activities: Travel, Arrive, and Leave.

One important need for geosocial software is that all objects in ActivityPub, including Place objects, need to have a permanent URL as their id property, which shares the description of that object in Activity Streams 2.0 format. However, there isn’t a good dataset of geographical objects — countries, states or provinces or regions, cities, buildings, businesses, parks, streets — available in AS2 on the Web right now. That is slowing down experimentation in the Geosocial Task Force.

Evan Prodromou, Blog Entry

Interestingly, Places.Pub operates as a hosted service by the SWF, and allows developers to connect to it using the C2S API. It simply acts as a repository of places, represented as ActivityPub objects.

CheckIn – An Example Client for Using GeoSocial Data

Checkin is the example client developed specifically for interacting with Places.Pub. It’s a relatively simple app, but the intention is to demonstrate a proof-of-concept to the community.

Something like this could be used to build a Foursquare-style GeoSocial app, powered entirely by open APIs and protocols. As a bonus, the client-first approach here would mean that developers wouldn’t necessarily have to take on the burden of building a full-stack Foursquare clone with a server backend and federation.

ReactivityPub

Although this is still in the tentative stages, ReactivityPub is an upcoming effort to integrate the ActivityPub C2S API directly into the React framework. It may or may not be related to the ap-components project, which intends to offer a toolkit for rendering and representing ActivityPub data using Web Components.

OnePage – A one-page ActivityPub Server

OnePage.pub is more of a personal project by Evan Prodromou, but could eventually be moved under the SWF project umbrella. Effectively, this acts as a headless server that’s primarily intended for the ActivityPub C2S API. It can be used to log into the CheckIn example client.

Why is this important?

At face value, all of these developments might not appear to mean much. However, these are significant because it shows the SWF taking a progressive approach on several fronts. It showcases the benefits of a long-neglected API, while attempting to address several wide-spread design issues that affect the network. If the organization can continue to build libraries, tooling, and other resources, they might be able to drum up further interest in making C2S possible.

Share

Social Web Foundation

Towards a bigger, better fediverse

^{Social Web Foundation}