[Feature] Federate vutuv over ActivityPub

[wintermeyer]

Summary

Make vutuv speak ActivityPub (AP), the W3C protocol behind Mastodon and the rest of the Fediverse, so that:

• independent vutuv instances can connect into one shared professional social graph, and
• vutuv profiles, follows/connections, and posts can interoperate with other ActivityPub apps (Mastodon, and the emerging federated professional networks).

The goal is a federated, open-source alternative to LinkedIn/XING — a niche the Fediverse repeatedly asks for and does not yet have a strong answer to.

This supersedes #657. That issue is kept open/closed only for its community discussion; this one is the canonical, self-contained version.

Motivation

vutuv is already self-hostable, so federation is not about self-hosting. It is about network effects. Unfederated professional networks derive their value from being the only place your contacts are; that lock-in is their moat. If vutuv federates, every vutuv instance — plus compatible Fediverse software — becomes part of one graph, so a single small instance is still useful on day one. This is the same reason Threads added AP federation to bootstrap reach.

Scope — what "support ActivityPub" means concretely for vutuv

This is a large feature; it should land incrementally. A rough order:

1. Discovery — WebFinger (/.well-known/webfinger) so profiles resolve as @user@instance, and AP Actor documents for each profile.
2. HTTP Signatures — sign and verify server-to-server requests.
3. Inbox/outbox — per-actor inbox/outbox endpoints and the shared inbox.
4. Social graph — map vutuv's existing follows and mutual connections onto AP Follow / Accept / Undo activities (the data model already has these primitives).
5. Content — federate profile data and posts as AP objects; receive remote ones.
6. Moderation — instance/user blocks, report handling, allow/deny-listing.

Benefits

• Defeats the network-effect lock-in of incumbents; small instances are useful immediately.
• Interop with other in-progress federated professional networks (see prior art) and with microblogging (e.g. posting a job opening that's discoverable via #fossjobs / #GetFediHired).
• Strengthens vutuv's positioning and could open non-dilutive funding (e.g. NLnet).

Costs / risks / open questions

• Maintenance & spec complexity — AP is a moving target; federation is ongoing work.
• Moderation & spam — federation imports the whole Fediverse's abuse surface.
• Privacy — professional data is sensitive; what federates by default, and what stays instance-local, needs an explicit policy.
• Open questions: build on top of an existing Elixir AP library or implement directly? Which objects federate vs. stay private? How do connection requests (vutuv's mutual, approval-based model) map onto AP semantics?

Prior art & resources

• bonfire-networks/activity_pub — a maintained ActivityPub library in Elixir (most relevant starting point).
• Haui1112/FediWork — demonstrates a federated professional network is feasible.
• Flockingbird (NLnet-funded federated-LinkedIn attempt) and ProFed — adjacent efforts; interop with them is a bonus goal.
• Recurring demand on the Fediverse for a "federated LinkedIn."

Status

Not currently on the roadmap ("bigger fish to fry"), kept open for community interest and periodic re-evaluation. Contributions and design proposals welcome. See #657 for the original 2019 request and the community discussion that shaped this issue.

[wintermeyer]

Status July 2026: follow-only federation is live (v7.43.0, deployed 2026-07-04)

vutuv speaks ActivityPub in production. What shipped, mapped to the incremental scope list above:

1. Discovery — done. GET /.well-known/webfinger resolves @handle@vutuv.de, every federating member has an actor document at /:username/actor, the profile URL itself answers Accept: application/activity+json, and the profile HTML advertises <link rel="alternate" type="application/activity+json">. Try it: search @wintermeyer@vutuv.de on Mastodon.
2. HTTP signatures — done. draft-cavage (RSA/SHA-256, the Fediverse convention) signing on every outbound request and verification on every inbox delivery, including the digest over the raw body; per-member RSA-2048 keys, minted on opt-in.
3. Inbox/outbox — the follow-only subset. Per-actor inbox handles Follow (stores the remote follower, answers with a delivered Accept) and Undo(Follow); every other activity is acknowledged (202) and dropped. followers/outbox are count-only collections. We use remote sharedInboxes to deliver once per server, but do not offer one ourselves yet.
4. Social graph — the outbound half. Remote actors can follow vutuv members. vutuv members following Fediverse accounts (and receiving their posts) is deliberately out of scope for this tier.
5. Content — the outbound half. Public posts federate as Create/Update/Delete(Tombstone) Notes with image attachments and inReplyTo threading (when the parent's author federates too). Closing a post's audience federates a Delete. No inbound content by design; reposts do not Announce yet.
6. Moderation — minimal by construction. Nothing federates inbound, so there is no remote content to moderate; a frozen/suspended/deactivated account stops federating automatically.

Design decisions worth knowing:

• Consent first: federation is opt-in per member (/settings/fediverse, default off) because deletion of federated copies on remote servers is advisory-only under the protocol and can never be enforced.
• Per-installation switch: FEDIVERSE_ENABLED=false turns the whole surface off (intranet installations); see docs/ADMINS.md.
• Architecture write-up: docs/architecture/fediverse.md.
• Related, shipped in v7.42.0: profiles emit rel="me" for listed social accounts, so Mastodon's link verification (green check) works without any federation.

Still open from this issue's scope (reasons to keep it open): receiving remote content (replies/likes/boosts), Announce for reposts, vutuv→Fediverse follows, instance-to-instance federation between vutuv installations, account Move/migration, a shared inbox, and inbound-moderation tooling.