thepraandClaude Opus 5.5
9ab87b2779
FEP-521a and FEP-8b32. Every persona has an Ed25519 key of its own (Avatar.SigningKey; migration 014 gives the earlier ones theirs), named in its actor's assertionMethod as a Multikey, the terms defined in the actor's own context. A persona's activity going to a relay carries an eddsa-jcs-2022 proof (JSON canonicalised by RFC 8785, Jcs), so what Activity-Relay forwards reaches Mastodon, which verifies it with its own code. Nothing else carries one: Mitra takes a proof over the HTTP signature and refuses one by a key it has not read, without reading the actor again. Received: an actor's own Multikeys are kept, and a forwarded activity whose proof one of them verifies is taken as it came instead of being read again from its origin. Discovery: WebFinger for the server's origin links its instance actor (FEP-d556), NodeInfo links it as the application actor (FEP-2677), and actors name RFC 9421 under implements (FEP-844e). Checked live: relay 16 (Activity-Relay's forward of alice's post reaches Mastodon), Mitra, GoToSocial and Mastodon unchanged (165 in all). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw
PrivaPub
A self-hosted ActivityPub server in C# (.NET 10, MongoDB) where one private login owns several unlinkable public personas. It federates with Mastodon, GoToSocial, Pleroma/Akkoma, Misskey and Lemmy.
- Live: https://privapub.thepra.dev
- Client: decePubClient, https://decepub.thepra.dev
- Architecture, conventions and deploy: CLAUDE.md
- Decisions and the plan to full ActivityPub interop: docs/ROADMAP.md
dotnet build PrivaPub.sln -c Release