Feder: One ActivityPub Core, Many Runtimes

Feder is a Rust framework for building ActivityPub applications from a portable protocol core and platform-specific runtimes. The project grew out of my work in the Fedify ecosystem and from a question that kept coming back: what would it take for a Fediverse server to become smaller, cheaper, and more portable than the usual VPS-based web application?

One motivating image was a single-user ActivityPub server as a physical device — something you could plug into power and Ethernet. Pushing that idea further led to a more difficult question: could parts of a Fediverse server run on embedded hardware such as ESP32-class boards, closer to sensor-network devices than conventional servers? Feder does not assume that a full Mastodon-like server can simply be moved onto a microcontroller. Instead, it asks how ActivityPub software should be decomposed when different machines have very different resources.

Feder separates ActivityPub protocol logic from platform execution. The core is responsible for federation behavior such as inbox/outbox state and delivery decisions, while runtimes take responsibility for networking, storage, clocks, and execution. The same core should work with different runtimes depending on the target environment: a Linux runtime for development and testing, and eventually more constrained runtimes for embedded devices.

This separation changes how "lightweight" is understood. It is not just about removing features, but about drawing clear boundaries between protocol behavior, storage, networking, scheduling, and hardware-specific execution. The first step is a Linux proof of concept: a small single-user ActivityPub server used to validate the framework before moving toward constrained runtimes.

The goal is not to present a finished server, but to share what it means to design ActivityPub as a portable engine rather than a monolithic application. Feder is still early-stage, but its direction is clear: one ActivityPub core, many runtimes — and the question of what kinds of Fediverse software become possible when federation logic can be separated from the machine it runs on.