BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.coscup.org//coscup-2026//talk//MUHKX7
BEGIN:VTIMEZONE
TZID:CST
BEGIN:STANDARD
DTSTART:20000101T000000
RRULE:FREQ=YEARLY;BYMONTH=1
TZNAME:CST
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-coscup-2026-MUHKX7@pretalx.coscup.org
DTSTART;TZID=CST:20260809T113500
DTEND;TZID=CST:20260809T120500
DESCRIPTION: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?\n\
 nOne motivating image was a single-user ActivityPub server as a physical d
 evice — something you could plug into power and Ethernet. Pushing that i
 dea further led to a more difficult question: could parts of a Fediverse s
 erver run on embedded hardware such as ESP32-class boards\, closer to sens
 or-network devices than conventional servers? Feder does not assume that a
  full Mastodon-like server can simply be moved onto a microcontroller. Ins
 tead\, it asks how ActivityPub software should be decomposed when differen
 t machines have very different resources.\n\nFeder separates ActivityPub p
 rotocol logic from platform execution. The core is responsible for federat
 ion behavior such as inbox/outbox state and delivery decisions\, while run
 times take responsibility for networking\, storage\, clocks\, and executio
 n. The same core should work with different runtimes depending on the targ
 et environment: a Linux runtime for development and testing\, and eventual
 ly more constrained runtimes for embedded devices.\n\nThis separation chan
 ges how "lightweight" is understood. It is not just about removing feature
 s\, but about drawing clear boundaries between protocol behavior\, storage
 \, networking\, scheduling\, and hardware-specific execution. The first st
 ep is a Linux proof of concept: a small single-user ActivityPub server use
 d to validate the framework before moving toward constrained runtimes.\n\n
 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 applic
 ation. Feder is still early-stage\, but its direction is clear: one Activi
 tyPub 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.
DTSTAMP:20260626T064252Z
LOCATION:TR411
SUMMARY:Feder: One ActivityPub Core\, Many Runtimes - Jiwon Kwon
URL:https://pretalx.coscup.org/coscup-2026/talk/MUHKX7/
END:VEVENT
END:VCALENDAR
