Independent technical referenceSystem / content / protocol / route

Protocols / federation

WebFinger, ActivityPub and federated blogs

Entry abstractFederation adds identity discovery and message delivery to the familiar blog publishing model.
Distributed constellation of independent server blocks linked by fine illuminated connections

A conventional feed lets readers pull new posts from a site. Federation adds addressed identities and server-to-server delivery: one publication can expose an actor, another can follow it, and new objects can be delivered to remote inboxes. For a blog engine, that means familiar posts participate in a larger protocol graph.

WebFinger discovers an account

RFC 7033 defines WebFinger as a way to discover information about an entity identified by a URI. A request uses the well-known WebFinger endpoint and a resource query parameter. The response is a JSON Resource Descriptor containing a subject and links.

GET /.well-known/webfinger?resource=urn:example:writer

The endpoint is discovery, not the complete social identity. A link in the response can lead to an ActivityPub actor representation. Correct URL normalization matters: scheme, host, account name and aliases must describe the same identity consistently.

ActivityPub actors and objects

The ActivityPub recommendation defines client-to-server and server-to-server interactions using ActivityStreams objects. In a blog-shaped implementation, a publication or writer can be represented as an actor. A post becomes an object, follow relationships connect actors, and inboxes receive activities.

This does not require abandoning the ordinary website. The canonical HTML entry can remain the human-readable destination while a representation exposes structured data for federation. The two views must agree on identity and URLs. If a federated object points to one address and the page declares another canonical address, replies and shares can fragment.

Delivery changes the operational model

RSS is mainly pulled by readers. ActivityPub delivery sends signed requests to remote inboxes and receives requests from remote servers. The engine now performs network work on behalf of posts: resolving actors, managing queues, retrying deliveries, checking signatures and limiting hostile traffic. A failed remote server should not block local publication.

Queues make this boundary clearer. Publishing commits the local post first; delivery jobs fan out afterward. Retries need limits and observability. Shared inboxes can reduce duplicate work, while follower collections and visibility rules determine who should receive which activity.

Stable identity is still the foundation

Federation amplifies permalink decisions. Actor IDs, object IDs, profile addresses and HTML links can be copied by many independent servers. Changing them later requires more than a local redirect because remote databases may treat the new identifier as a different object.

Federation in the dasBlog lineage

The active DasBlog Core repository lists ActivityPub among its features, and the maintainer's current project category includes work on WebFinger. Those links are the proper source for the project's present implementation. This page remains a protocol overview and does not act as project documentation or support.

Test across trust boundaries

A local test between two friendly servers exercises syntax but not the hard operational cases. Include unknown actors, malformed objects, duplicate deliveries, deleted remote content and a server that responds slowly. Confirm that private or draft material never enters a delivery queue. Federation code consumes remote input and initiates outbound requests, so its network boundaries deserve explicit review.

Log protocol outcomes with stable correlation identifiers, but keep private payloads and credentials out of routine diagnostic output.

A blog remains a website

Federation is most resilient when it extends a readable, linkable site rather than replacing it. HTML pages, feeds and the federated representation should share durable identifiers and clear authorship. The feed guide covers the pull side; the URL guide covers the identity promise both models depend on.