Files
SocialPub/FEDERATION.md
T
thepraandClaude Opus 5.5 8f4d6cbdf9
Build / Build (push) Successful in 57s
Deploy / privapub.thepra.dev (push) Successful in 1m12s
A private fediverse on the workstation: PrivaPub against a real GoToSocial
tools/pasture/run.sh starts PrivaPub, GoToSocial and Mongo on one podman network behind Caddy's internal CA, and
interop.sh drives both through their own client APIs: follows (one to a locked account), posts, CW, replies, likes,
boosts, DMs, edits, deletes and unfollow. All 25 checks pass, three fresh runs in a row.

- Federation:AcceptAnyCertificate joins the two test-network switches; startup refuses all three in Production.
- WebFinger falls back to http only when AllowPlainHttp is on.
- A bootstrap logger, so a failure before the host is built is no longer silent.
- P4 is ticked in the roadmap, with what has not been run live (Lemmy, a Mastodon circle member).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012CzABvBkbcFqoHdmi8b9WB
2026-10-01 13:19:16 +02:00

7.7 KiB

Federation

PrivaPub is an ActivityPub server written in C#. This document follows FEP-67ff and describes how it federates.

Supported federation protocols and standards

Tested against

  • GoToSocial 0.22.1, end to end. It runs in a private network on the workstation (tools/pasture/) and is driven through its own client API. Checked both ways:
    • follows, including to a locked account;
    • public posts with a content warning;
    • replies with notifications;
    • likes and boosts;
    • direct messages;
    • edits and deletes;
    • unfollow.
  • Mastodon, Misskey, Lemmy and PeerTube, by unit tests only. The tests feed the parser documents written in each server's shape. No live exchange with any of them has run yet.

Supported FEPs

Planned: FEP-1b12 (communities), FEP-8fcf (followers synchronisation), FEP-5feb (indexable), FEP-7628 (Move), FEP-044f (quotes).

Actors

Every account is an avatar: one private login can own several, and they are deliberately unlinkable. Nothing in an actor document, a collection, NodeInfo or a delivery relates two avatars of the same login.

Thing Address
Actor (Person, Group, Application) /peasants/{name} (/users/{name} redirects)
Inbox /peasants/{name}/mouth
Outbox /peasants/{name}/anus
Shared inbox /human-centipede
Followers / following /peasants/{name}/groupies, /peasants/{name}/stalking
Objects /peasants/{name}/scribbles/{id}
Activities /peasants/{name}/grunts/{id}
Direct-message context /peasants/{name}/whispers/{id}
Profile and post pages /@{name}, /@{name}/{id}

The names are the project's own and are stable; resolve actors through WebFinger, not by guessing a path.

  • The key is {actor}#main-key, RSA 2048, served as SPKI PEM with owner set to the actor.
  • published on an actor is truncated to the day. indexable is false.
  • The instance actor is /peasants/privapub (type Application). It signs every fetch PrivaPub makes, so no avatar's key is used to read another server's content.

Groups

A group is either a community or a circle.

  • A community follows FEP-1b12. Posts addressed to it (in to, cc or audience) are accepted according to its posting policy (followers, anyone, or moderators only) and the group Announces the whole activity, with audience set, to its followers. A new post is also announced as an object so Mastodon shows it. Updates and deletes of community content are announced too. A top-level post is a Page with a name. Members are counted at /flock; moderators are listed at /wardens, which the actor's attributedTo points to, with postingRestrictedToMods as Lemmy expects. A mention of a community posts into it.
  • A circle is private. Its actor is not discoverable and every follow is a request. Its posts are addressed to the circle and its members collection, delivered to each member's own inbox and never announced. They are served only to a signed request from a member, or from the instance actor of a member's server; anyone else gets 404. A Mastodon member's replies reach only the people they mention.
  • Announces from remote groups (Lemmy communities) are followed through to the activity: the object is fetched from its own origin, never taken from the announce.

Activities

Received:

Activity Effect
Follow follows an avatar or community; Accept is sent unless the community approves members by hand
Accept{Follow}, Reject{Follow} completes or ends a follow an avatar requested
Undo{Follow, Like, Announce} reverses it
Create{Note, Article, Page, Question, …} stored when a local avatar follows the author, is addressed or mentioned, when it replies to a local post, or when it is addressed to a community the author follows; a public parent is fetched to complete the thread
Update{Note} replaces the content; the previous version is kept
Update{Person} refetches the actor
Like counted and notified, on posts the liker could see
Announce counted and notified for local posts; shown to followers of the announcer, with the original refetched from its origin
Delete deletes the object, or the actor and its follows
Flag becomes a report for this server's moderators

Sent: Follow, Undo{Follow}, Create{Note}, Update{Note}, Update{Person}, Delete{Tombstone}, Accept{Follow}, Reject{Follow}, Like, Announce and their Undo, Flag. A deleted post answers 410 with a Tombstone.

  • Attachments are Documents with mediaType, name (alt text), blurhash, focalPoint, width and height. Uploaded files have all metadata removed.
  • Pinned posts are the actor's featured collection (/trophies); featuredTags is /tattoos.
  • Blocks are never sent. A blocked account is sent Reject{Follow} if it followed, and is unfollowed.
  • Reports are sent as Flag by the instance actor, never by the reporting account.

A Create's Note carries Mastodon's content, contentMap, summary and sensitive, plus Mention and Hashtag tags. A post's title becomes name and is also the first, bold line of content, because Mastodon does not show name. A content warning without its own text uses the title, or "Content warning".

Visibility is expressed in to/cc the way Mastodon does it: public, unlisted, followers-only and direct. Inbound followers-only posts are recognised by the author's own followers collection.

Local-only posts

Posts with a location (shown to nearby users of this server) never leave the server, in any form.

Security rules a peer will notice

  • Signatures. Inbox POSTs must be signed over (request-target), host, digest and date (or (created)). The date may be at most one hour old and fifteen minutes ahead. A bad signature gets 401, malformed input 400, an accepted activity 202, too many requests 429. Activities are processed after the 202.
  • Origins. An actor document is accepted only from the address it names as its id. A key only if its actor lists it with owner set to the actor and on the actor's origin. An activity's id, and any object it creates, updates or deletes, must be on its actor's origin. An embedded object from another origin is fetched from that origin.
  • Fetching. All fetches are signed by the instance actor. They go only to public addresses, follow at most three redirects and read at most 1 MB.
  • HTML. Received HTML is sanitised to Mastodon's allowlist.
  • Delivery. Failed deliveries are retried with Mastodon's backoff (16 attempts). A host that keeps failing is paused, starting at an hour and growing to a week.

Known limitations

  • Polls and custom emoji are not implemented.
  • Remote media is fetched through this server's proxy when a local client displays it.
  • Collections expose counts, not members.
  • Only rsa-sha256-style keys are verified. RFC 9421 signatures are planned.