Get Federated

Drop a file in a folder. Talk to the Fediverse.

{
  "version":   "1",
  "type":      "create",
  "id":        "my-first-post-20260908120000",
  "url":       "https://yourdomain.com/posts/my-first-post",
  "published": "2026-09-08T12:00:00Z",
  "title":     "My First Post",
  "summary":   "A short teaser shown before the fold.",
  "content":   "<p>The post, as HTML.</p>"
}

Any tool that can write a text file can write this. Every publishing platform already has what it contains — the content, a title, a date, a URL.

Your content, at your site, federated — not reposted, not copied.

We're told we have to choose: independence or participation, but not both. Thankfully, you already have independence, if you want it. Here's participation:

A small Node.js sidecar that manages followers, signatures, and delivery so that your publishing tool does not have to. Your content stays on your domain, served by whatever you already use.

You need a server running a recent version of Ubuntu Linux or similar — this will run easily on the smallest VPS instance you can provision — a domain with DNS pointing at it, and the ability to use SSH and edit a file.

Learn more…

That file is enough to federate all of your content. Each update is written to a folder as a file like the one above. SocialSecretary turns it into a signed ActivityPub activity and delivers it once to each instance where you have followers; the instance fans it out to them. Every reply, like, and boost comes back as a file in a dedicated directory, where your publishing tool picks it up — or ignores it, if one or another kind of interaction is not something you want. You can already picture how it works.

The Fediverse was never locked behind a platform. The barrier has been that the dominant ActivityPub implementations bundle the social handshake with a full content management system, a database, and a moderation infrastructure. What has been missing is the handshake on its own — standalone, self-hosted, working for whatever you already publish with.

The hard part of ActivityPub — HTTP signatures — is about 150 lines of careful code using only Node's built-in modules. Strip away everything a platform is trying to be at the same time, and what is left is signed JSON and a list of addresses.

What it is for

Consider the usual options. RSS lets readers follow a site, and stops there. The Fediverse lets millions of people discuss and share, but expects you to hold an account on someone's instance. A platform's API may let you bring links to your own content onto that platform, or it may not, and where it does, the access is restrictive and subject to change.

SocialSecretary uses ActivityPub to connect an independent site to the Fediverse directly, in a way that is open and durable. Your content, on your site, federated — where those millions can find, discuss, share, and reply to it, and follow you so they see what you publish next. Without an account on anyone else's instance.

Your publishing tool already has everything it needs

Every publishing platform, by definition, already has the three things SocialSecretary asks for: the content, a little metadata, and the ability to write a text file. That is the whole requirement. Virtually every independent publishing stack can integrate with SocialSecretary today, with a post-publish hook of a dozen lines.

zdat exists to show what that looks like: a command-line publishing tool built on exactly this interface. It composes posts, writes envelopes, reads what comes back, and serves your posts as real pages on your domain. Use it as a modest publishing platform in its own right, or read it as the reference implementation — the thing a Hugo, Eleventy, Astro, Kirby, or WordPress integration can copy. It is a separate project with its own guides.

What you'll have

A live @you@yourdomain.com presence that accepts followers from any ActivityPub server, broadcasts posts from any tool that can write a file, receives replies, likes, boosts, and mentions as files your tool can read, runs as one process under systemd with no dependencies beyond Node itself, and keeps every object it ever publishes in an archive you own.

Download

SocialSecretary is a manual installation, on purpose. There is no install script. Every step says what it does and why. If something goes wrong, you will know exactly what: you can say “This step didn't work for me,” not “The installer failed for some reason.” When you are done, you know what is on your server, and so you know how to run it afterwards. It takes an hour or two, most of it spent reading the installation guide — which you should want to do anyway. There is no way to eliminate that obligation. An automated installer just lets you ignore it, until the worst and most annoying time.

curl -O https://socialsecretary.pub/dist/socialsecretary-latest.tar.gz
curl -O https://socialsecretary.pub/dist/socialsecretary-latest.tar.gz.sha256
curl -O https://socialsecretary.pub/dist/socialsecretary-latest.tar.gz.asc

Current release: 1.0.1, 19 September 2026 — release notes.

How do you know you can trust those downloads?

```
gpg --auto-key-locate clear,wkd --locate-keys rob@socialsecretary.pub
```
Fetches the signing key from this domain. The fingerprint it prints must be 735C CBB0 C5C2 73DD E2C5 0FA1 A84B 1564 762B 3085.
```
gpg --verify socialsecretary-latest.tar.gz.asc socialsecretary-latest.tar.gz
```
Must say Good signature from, naming Rob. This key also carries the rob@zdat.pub identity — Rob's projects share one key on purpose, the same way this domain and zdat.pub share one person. gpg may print either address as the primary line and the other as aka; what matters is the fingerprint above, not which name comes first. The warning that the key is not certified is gpg noting you have not personally vouched for it; the fingerprint check above is your vouching.

sha256sum -c socialsecretary-latest.tar.gz.sha256

Must say OK. If any of the three does not, stop.

The signing key is published by Web Key Directory: ask socialsecretary.pub who rob@socialsecretary.pub is, and the domain answers. It is the same idea as WebFinger, which lets anyone find @you@yourdomain.com by asking your domain. You know the files you are downloading were signed by whoever controls socialsecretary.pub, and the signature proves they have not been altered since. No account, no platform, no third-party keyserver. The key is also at socialsecretary-signing-key.asc for anyone not using WKD.

The open internet has had thirty-five years of careful work from dedicated professionals and a global community; it already has good answers for identity and trust. This project uses them because they are as good as the closed alternatives or better. You don't need a platform to federate. You don't need a platform for trust. You are a full-fledged member of the open internet as soon as you choose to be, on your terms, for as long as you like.

Read the guide

The archive contains the complete documentation. It is also here.

Installation Guide markdown: From a fresh Ubuntu server to a live presence. Start here.
Operator Guide markdown: The five-minute weekly check, what normal looks like, what every log line means, every procedure.
Handoff Envelope Specification markdown: What your publishing tool writes.
Mailbox Specification markdown: What your publishing tool reads.
Activity Log Specification markdown: What SocialSecretary logged, in either direction, and why.
Filesystem Reference markdown: Every server path, its owner, its mode, and what writes it.

License

SocialSecretary is free software under the GNU Affero General Public License, version 3 or later. If you modify it and run your modified version as a service for others, you must offer them your source — that is the whole obligation, and it is the point: the pieces that make the open web work should stay open wherever they end up. Your publishing tool is not affected; a separate program that talks to SocialSecretary through files and HTTP is a separate program, under whatever license you like.

Or skip ahead: download it, or read the installation guide.