Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ActivityPub protocol and extensions

Plamenu uses WebFinger and NodeInfo for discovery, ActivityPub actor and object endpoints, signed inbox delivery, and signed or authorized fetch.

Identity and transport

Local actor and object URLs use the configured domain, which must stay fixed after federation begins. An optional account_domain provides shorter handles; its WebFinger, host-meta, and NodeInfo discovery paths must forward to Plamenu. Remote handle changes are accepted when WebFinger resolves to the same actor URI.

Transport supports draft-cavage and RFC 9421 HTTP signatures, FEP-8b32 integrity proofs, delivery retries, and URL/IP checks on remote fetches. Remote RSA, Ed25519, and ML-DSA-44 verification keys are stored per actor. Local RSA and Ed25519 private keys are encrypted at rest.

See signing-key operations for rotation and recovery, queues for retry behavior, and Tor/I2P transport for optional proxy routing.

Identity proofs

FEP-c390 statements are published in actor attachments and verified on remote actor fetches and Updates. Plamenu supports Ed25519 did:key with eddsa-jcs-2022 and its legacy suite name. It retains valid original statements and discards invalid or removed ones. Expired proofs are excluded when profiles or actors are read. This remains an experimental FEP; Ethereum and prehashed Minisign proofs are not implemented.

See member controls and client endpoints. Identity keys are user-owned and separate from the server’s federation signing keys.

Content

Local publishing includes Notes, polls, Articles, Events, and group threads. Titled ordinary group posts use Page. Replies, quotes, favourites, boosts, emoji reactions, group moderation, and event participation have federation handlers. Groups use experimental FEP-1b12/Lemmy-oriented behavior.

Group actors publish postingPolicy in the https://codefloe.com/plamenu/plamenu/ns# namespace: anyone, members, or mods. Lemmy’s postingRestrictedToMods is also emitted and is true for mods.

Outgoing Articles put the title in name and a heading in the body, supporting readers that display only the body. summary carries the content warning. Plamenu removes a matching leading title when rendering incoming articles.

Inbound object handling includes Note, Question, Article, Page, Event, Document, and Video, with remote media handling for audio/video and PeerTube streams. These are receiving and rendering capabilities; they do not imply that Plamenu provides a publishing tool for each remote object or media type. The posting guide describes local web controls.

Remote software controls its own presentation. Some clients display an article or event as a title and link. Fixture and live-peer coverage is described in interoperability testing.

Webxdc

The experimental FEP-752d implementation supports Note invitations, Group/WebxdcSession actors, membership, sequenced updates, fan-out, replay, participant removal, session closure, and deletion.

Bundles are publicly retrievable. Plamenu accepts application/webxdc+zip and legacy application/x-webxdc, checks the SHA-256 Multihash in digestMultibase, and validates archive limits before caching or execution. Serve bundles from the separate Webxdc origin described in the deployment configuration.

window.webxdc.joinRealtimeChannel() uses the draft’s ephemeral ActivityPub baseline: binary packets travel as Create/WebxdcEphemeral and coordinator Announce activities. Connected clients receive them over a host WebSocket. Packets have no durable serial, database storage, retry job, or replay, and expire within five seconds. This does not provide a low-latency guarantee.

Plamenu uses bounded in-memory fan-out, duplicate suppression, and delivery concurrency. Routing/authorization metadata is cached for two seconds and signing keys for thirty seconds; local Webxdc membership and lifecycle changes invalidate authorization immediately. Signed inbox requests still read known actor keys and instance policy. Packet processing skips durable inbox bookkeeping and unknown key refetch. Packet payloads never pass through the database notification bus. Run one serving process per instance for this experimental channel; replicas would need a shared, non-persistent fan-out transport. Reverse proxies should also exclude ephemeral inbox bodies from request logging.