If you get all of your important technology news from “content aggregators” like Hacker News, Lobste.rs, and most subreddits, you might be totally unaware of the important but boring infrastructure work happening largely on the Fediverse, indie web, and other less-centralized communities.
This is no accident.
The rough consensus of these spaces has been strongly in favor of the sort of centralized tech monopolies, venture capitalists, private equity ghouls, and “innovation” that weakens the position of workers against the wealthy (i.e., most use cases for Large Language Models).
Occasionally they sprinkle in a bit of faux resistance–just enough to be able to pretend they’re counterculture, so they can pretend that Silicon Valley spirit hasn’t been thoroughly sold out to Palantir over the past two decades. That’s why a few “anti-AI” rants will occasionally slip through.
Earlier this week, I announced the immediate availability of a reference implementation for the Public Key Directory–a project I’ve been working on since June 2024. Hundreds of people shared it on Mastodon and BlueSky. Comparatively, almost nobody on Hacker News ever saw it.
Today, the COCKTAIL-DKG specification is now live (previous blog post). It’s an early version (v0.1.0), and the reference implementations are still a work-in-progress, and there’s still a lot of work to do, but it’s a tangible specification. With test vectors (from my hacky implementation that isn’t clean enough to publish)!
Two months ago, I wrote a blog post titled The Dreamseeker’s Vision of Tomorrow. In the time since, I’ve gotten two of my three current projects to the next stage of maturity (and the third one was blocked by one of those two).
I have no illusions that the larger tech industry will do anything but collectively shrug at this sort of progress. I’m sure you’ve all heard it before.
This is boring infrastructure work!
There’s no drama; no scandal. There’s nothing sexy. No one is bleeding. Why would anyone want to read about this?
Hell, why are you even blogging instead of making short-form video content?
Get with the times. The attention economy demands tribute.
Design tooling to integrate FREEON into other workloads that already support single-secret Ed25519 today.
Imagine tying this into SigStore and attestations like PEP-740.
None of this work will generate much buzz, but I’m building it because I feel strongly that it needs to exist.
Fediverse users should be able to have private chats with each other, that not even their instance admins can snoop on.
This encryption should be accessible to mere mortals, without sophisticated training or discipline.
Geographically distributed open source software teams should be able to mitigate the $5 wrench problem.
AuxData is a little exciting
One thing that I feel is underappreciated about the Key Transparency system I designed is that it’s extensible. That is to say, you can push more than just public keys; you can also publish (and revoke) typed blobs of “auxiliary data”.
If you asked a cryptographer how to enable a workflow where strangers can encrypt a file and send it to you, such that only you can decrypt it, they’ll recommend something like age. (If they recommend PGP without you specifically adding it as a constraint, they’re a clown.)
But, in this scenario, how does anyone know that they’re using YOUR age public key and not the NSA’s? Or Mossad’s?
I’m not just building a solution for the Fediverse. I’m building a viable way for developers the world over to build federated trust and transparency that doesn’t involve cryptocurrency and all the crap that comes with that crowd.
(But, of course, the fact that it’s not a blockchain or AI solution is precisely why tech news message boards won’t give a shit.)
Y’know, this is probably what they call, “taking it easy.”
I still haven’t finished that damn key management blog post. But now that the Key Transparency project has a reference implementation, and COCKTAIL-DKG exists in the C2SP repository, I’m a lot closer than when I started.
At the risk of jinxing myself into having another thing to write about before January 1, here’s to 2026.
To get started with the project, start with the pkd-server-php repository (linked above). Some quick commands:
# Clone the source code
git clone https://github.com/fedi-e2ee/pkd-server-php.git
# Install dependencies
cd pkd-server-php
composer install --no-dev
# Setup and configure
cp config/database.php config/local/database.php
vim config/local/database.php # or your favorite editor
cp config/params.php config/local/params.php
vim config/local/params.php # or your favorite editor
# Setup SQL tables
php cmd/init-database.php
# Run locally for dev purposes:
php -S localhost:8080 -t public
This represents an important milestone in the overall project!
So, I’d like to outline the road between where we are today, and when you can easily use end-to-end encryption to communicate with your friends on Mastodon and other ActivityPub-enabled software.
But before we get into the technical stuff, the most important question to answer is why anyone should care about any of this.
Important
What was released today is still not production-ready. We’re still on v0.x for all of the software in scope.
There will be bugs!
Some features may need to be reconsidered (which will require future revisions to the specification).
Do not count on any of this software being secure or stable until we tag v1.0.0.
As I’ve discussed in a previous blog post, a lot of social media toxicity and online services getting shittier over time share a root cause:
They’re direct consequences of centralized platforms with access to fuckloads of sensitive data about people.
Whenever a techie figures this out, they’re quick to embrace decentralized technologies, but these actually have a pretty awful privacy track record.
I like to pick on PGP and Matrix, but the Fediverse (including Mastodon) is a good example that doesn’t require technical expertise to grok:
On the Fediverse, DMs (“direct messages”) are not end-to-end encrypted. This means that your instance admin can snoop on your messages if they want. (In fairness, this was also true of DMs for Twitter and BlueSky for most of their history.)
Last year, the W3C decided to investigate E2EE for ActivityPub, which would create a standard for solving this privacy foot-gun for Mastodon and other Fediverse software.
However, key management for the Fediverse was still a very difficult problem to solve.
To understand that, you need to know a little bit of cryptography concepts.
Don’t worry, I won’t be throwing any crazy math at you today.
Public Keys
There’s a special type of cryptography that involves two different numbers (called “keys”): One public, one secret.
Every “secret key” (which, as its name implies, should be kept secret) has a corresponding “public key” (which can be freely shared with the world). The two have some mathematical relationship that lets us do cool things.
If you’re hoping for an intuitive, easy-to-understand explanation for how any of this “secret/public key” magic works without any mathematics, the best I’ve found online uses colors.
(If you need a deeper explanation, I’ll try to come up with one. But for now, just know that “public keys” are intended to be shared publicly, and can be used for lots of things in cryptography.)
Some things that are nice to know about public keys:
Some algorithms allow you to encrypt a message such that, even if you publish the encrypted message publicly, only the person holding the secret key can ever hope to decrypt it.
Others allow you to use your secret key produce a “signature” of a message. Then, someone can take your public key, the signature, and your exact message, and prove that you signed it. But (and this is critical) they cannot easily forge new messages and convince others that you signed them.
Key Transparency is a way to ensure that, given a public key to use for cool cryptography purposes, you can be reasonably sure that it’s related to the specific secret key held by the person you want to communicate with.
How Key Transparency works is simple in concept: Build a protocol that lets everyone publish their public keys to an immutable, append-only ledger called a “transparency log”.
If you want to find the public keys that belong to your friend, you can simply query the transparency log for all [non-revoked] public keys that belong to said friend.
If the transparency feature is well-designed, app developers can write software that is reasonably confident it has the right key for the intended recipient. This is more robust than expecting users to manually verify arcane-looking strings (key fingerprints or “safety numbers”).
Finally, you can have the Fediverse instance software (e.g., Mastodon) advertise which transparency log it passes messages onto, so you always know which transparency logs to query for a given instance.
When you package this all together, building end-to-end encryption for the Fediverse becomes much simpler.
Project Architecture
Before I get into the meat of today’s discussion, I need to be clear about the service architecture that the Public Key Directory fits in.
If you prefer a visual aid:
The above diagram is taken from the current version of the Architecture page of the Specification repository.
Protocol Messages are ultimately committed to the Transparency Log.
After being validated, they ultimately update the mapping of “which public key is currently trusted for a given ActivityPub Actor?” as well as “what auxiliary data is currently trusted for a given ActivityPub Actor?”
Users will generate most Protocol Messages locally, and then encrypt them (using HPKE) with the Public Key Directory’s Encapsulation Key, before passing them onto the Instance.
This encryption prevents their instance from selectively censoring certain protocol messages from the user.
Authentication and authorizations decisions are made by the Instance, so the Public Key Directory will only accept most messages from the instance itself.
Instances (“Fediverse Servers” in the diagram above) will also generate some Protocol Messages on their own. (Namely, BurnDown.)
Regardless of the origin, the Protocol Messages are sent to the Public Key Directory by the Instance (which will use RFC 9421 “HTTP Message Signatures” to sign the protocol message).
The Simple Read-Only API
Of course, this is only concerned with writing to the Public Key Directory.
There is, additionally, an HTTP JSON REST API for read-only access. This HTTP API allows SDK software to make an incredibly simple but powerful user experience for fetching public keys and other data from the Public Key Directory.
For example, if someone were to write JS SDK tomorrow, the API their users would need to know is quite simple:
// Example config
const keyDir = new PublicKeyDir('https://example.com');
// Fetch public keys to use for E2EE
const publicKeys = await keyDir.getKeys("@soatok@furry.engineer");
// AuxData type: ssh-v2
const sshPubKeys = await keyDir.getAuxData("@soatok@furry.engineer", "ssh-v2");
The Auxiliary Data feature also allows other people to build atop this work to help provide key transparency to other protocols. See fedi-pkd-extensions for more information.
Why don’t you force the use of Actor URLs instead of double @ identifiers?
The data that is stored in the transparency log always contains the canonical URL for an Actor.
The user-facing APIs (HTTP API, client software, etc.) permits strings like @soatok@furry.engineer, but these strings will be canonicalized for you (i.e., to https://furry.engineer/users/soatok for my handle).
This is a convenience feature and is only available so long as WebFinger for the host instance is online. I wanted to make this software as easy-to-use as possible while still being strict about Actor identification under-the-hood.
Why not use [other transparency solution]?
There are, indeed, many projects that aim to provide some cryptographic notion for transparency. Famously, Facebook / Meta has an open source “auditable key directories” project.
There are a few things the Fediverse Public Key Directory project does that other incumbent designs, such as SigSum, do not:
My design actually stores public keys and other data. It isn’t only managing proofs of data stored externally, it’s actually serving as a source of truth for the verifiable data it serves.
Despite storing and serving data, my design goes out of its way to make GDPR compliance not logically impossible by design (assuming crypto-shredding is a legally valid way to comply with EU data protection regulations).
If you wanted to build with AKD or another key transparency solution, you still need to figure out your own architecture and storage.
In contrast, the Fediverse Public Key Directory project is an opinionated complete solution.
Moving on…
Now that we’ve covered the preliminaries, let’s take a quick look at how we got here, where we’re at, and then where we’re going next.
I’ve talked about this at length in earlier blog posts in this category, if you want more details.
At the end of 2022, I decided to use my applied cryptography experience to help the Fediverse encrypt direct messages between users. I started laying out a specification for E2EE overall, but realized that Key Transparency was a harder problem to solve, and therefore the one I should focus on first. In 2024, I shifted my focus to solely tackle Key Transparency.
The public key directory specification project was open source from its inception, but I didn’t want to release a reference implementation of the server software until I was certain about the design decisions made in the specification.
Thus, the actual implementation work was a solo undertaking. Lessons learned from trying to build it were used as a feedback mechanism to strengthen, simplify, and clarify the specification.
Earlier this year, I started writing a Public Key Directory server in Go, which was a sensible choice since I was planning to build atop SigSum (and all the developer tooling was written in Go). However, this proved to be a grueling experience, so I decided to change direction and instead implement my own Merkle tree-based transparency log.
In the weeks following this experience, I’ve been hammering out the PHP server implementation I’m releasing today.
Here’s a quick visual aid for understanding the architecture:
Once the full specification was implemented, and I have good CI tests to ensure it works well on multiple RDBMS backends, I fleshed out a PHP client SDK.
As soon as both software components were ready for public feedback, I made them both open source and published this blog post.
In parallel, writing more client SDKs will make it easier for Fediverse software written in TypeScript, Ruby, Elixir, Python, Rust, and Go to communicate with the Public Key Directory.
Either way, the goal for these SDK libraries is to allow both end-user applications and Fediverse servers speak the protocol (even if, in practice, most end users will only use it from a browser extension).
As more of the community gets involved with the project, we may need to update the specification and implementation to make adoption easier for all parties involved. Once we’re happy with both, we will begin tagging the v1 major version and proceed to the roll-out phase.
Setting A High Assurance Bar
While I’ve been developing this project, I’ve been looking for ways to ensure that we meet an extremely high bar for software assurance (security and correctness).
Unit testing is table-stakes for software development.
Static analysis tools (e.g., Semgrep and language-specific linters) should be used appropriately to identify issues before they become a risk.
The server-side reference implementation uses both Psalm and PHPStan to identify type-unsafe code and fail builds if any occurs.
Mutation testing is encouraged for finding gaps in test coverage.
Fuzz testing is encouraged for anything that parses user input.
The PKD server software tests both the protocol inputs as well as the HTTP request handlers this way.
Requirements traceability, using tools such as awslabs/duvet, can be used to ensure the requirements in the specification are covered by the software and its test suites.
Formal verification, using tools such as ProVerif, can be used to verify the correctness of the cryptographic algorithms.
Dependency freshness (e.g., setting up Dependabot alerts or using Semgrep’s supply chain security features) is also highly recommended for every project.
Before v1.0.0 is tagged for any project in the fedi-e2ee organization on GitHub, each of these requirements will either be met, or I’ll commit a statement about why it’s not an appropriate mechanism for that specific repository.
Why no crypto audit?
One thing you’ll notice is absent from the above list, but common for cryptography projects, is a paid third-party assessment by other cryptography and software security experts.
As of this writing, I simply do not have the disposable income to fund such an audit, and I have no plans to generate revenue off the work I’m doing, so it’s unlikely that I ever will.
Unless a third party steps up and pays for an audit, this will remain an unchecked box.
Once we tag v1.0.0 of the various specifications and implementations, it will be time to write patches for the various Fediverse instance software and client applications.
Patching instance software will generally be easy: All instances really need to do is advertise a list of Public Key Directory servers. Everything else will be handled by the existing ActivityPub plumbing (since the Public Key Directory only accepts most Protocol Messages via ActivityPub, not generic HTTP).
However, if the instance software doesn’t already support RFC 9421 and FEP-521a, those will remain blockers for that project. (Also, they MUST support Ed25519 for it to work.)
I’ve already volunteered to help Mastodon get with the program. However, the Fediverse is much bigger than just Mastodon, so some coordination is necessary.
Once Key Transparency exists across the Fediverse, the next two phases can be performed in parallel.
If they commit to an extremely stupid mistake (e.g., being backwards compatible with some legacy protocol that requires, I dunno, RC4?), I will dust off my own early specification and proceed to build that out.
(With the Public Key Directory project already deployed, I don’t really need to boil the ocean on the “Federated PKI” step in my original spec, after all.)
At the end of this effort, we should have open source desktop apps, mobile apps, and browser extensions that implement E2EE with public keys vended from the Public Key Directory.
As far as MLS implementations go, the ts-mls project seems like a reasonable TypeScript implementation to build upon. At some point in 2026, I hope to find time to review it thoroughly.
Extending the Public Key Directory to Secure Other Protocols
Key Transparency is a powerful security tool, and there’s no sense keeping it all to ourselves.
To that end, I want to build proposals, specifications, and proofs-of-concept for using the Public Key Directory to fetch other application-specific public key material (dubbed “AuxData” in the PKD spec).
Some use cases that come to mind are:
SSH public keys
age public keys
A secure replacement for JSON Web Keys for Identity Providers implementing SAML, OAuth, OpenID Connect, or similarly shaped authentication protocols
I can’t give you a realistic timeline for when all this work will be complete. I’m actually very bad at accurately predicting how long it will take to build software.
What I can say is, I’ve already put a lot of necessary work in, and most of the remaining work doesn’t actually require much of my particular skillset, so maybe it can be sooner than later?
Ultimately, that decision comes down to the Fediverse and the greater open source community.
I’ve received a few questions on various platforms and thought I would answer them here.
If you have a technical or security-related question that isn’t covered here, I recommend reading the threat model from the specification repository. If your question isn’t answered, there’s a good chance it’s worth talking about.
Will this project offer “crypto agility”?
The short answer is: No.
But the protocol is versioned, so if we need to upgrade a component (e.g., from Ed25519 to something post-quantum), we can do that by specifying a “version 2” ciphersuite.
This sort of work will be deliberate and carefully constructed. There will never be in-band protocol negotiation beyond the “v1” or “v2” breadcrumb.
What I absolutely do not want is to ever recreate JSON Web Token’s flawed design of an alg header that lets you choose none or use public keys with symmetric-key cryptography.
Will the Public Key Directory (PKD) be centralized?
No, but it won’t be the case that every Fedi host needs to run their own.
It’s my expectation (especially when trying to make the software performant) that a single PKD could service the majority of the Fediverse, but I hope it won’t need to.
How is this better than Trust-On-First-Use (TOFU)?
The TOFU trust model assumes that the first public key you receive is definitely the correct one, and pins it. There is no external attestations, signatures, third-party oversight, or transparency logs involved.
There are many people who think that “manually verifying key fingerprints” is a normal thing that normal users should be expected to do, correctly, 100% of the time.
This is an unreasonable expectation. I know professional cryptographers that, despite using Signal, have never once verified another person’s Safety Number.
Bootstrapping trust on Key Transparency provides a stronger baseline security than TOFU, because you have third-party witness co-signatures, an immutable transparency log, replication, and checkpoints from one ledger onto others.
Additionally, after a first AddKey message has been submitted to the Public Key Directory (which MUST be the first “action” every Actor submits to the directory), every other message must be signed by a currently-trusted key held by the end user.
The only way an attacker can revert back to a state where self-signed is allowed is to be an instance administrator and issue a Burndown message, which is a break-glass account recovery feature. Note that you can disable administrators’ ability to intervene to recover your account if you issue a message to make your account Fireproof.
This is why reading the threat model is so important.
And, sure, this is not as secure to the endpoint as manual fingerprint verification would be. But nothing precludes client software from adding key fingerprints (or Signal-style safety numbers) on top of key transparency.
Just don’t expect most non-geeks to bother.
This is important: I want those non-geeks to be okay even if they don’t bother.
Transparency log-based trust protocols are more robust at scale than expecting everyone to be perfectly disciplined all the time.
Why is this mechanism even necessary?
Because key management–especially answering the question, “How can I trust that this public key is this stranger’s public key?” at Fediverse scale–is so much more difficult than just the “if I have a public key, how can I securely encrypt with it?” question.
Even cryptographers underestimate how hard key management problem is, sometimes.
What’s the plan around account recovery?
If you want a more thorough answer (which is very likely for the sort of person that asks insightful questions), I highly recommend reading the Specification.
TL;DR – BurnDown lets your Instance Admin reset your account to a state before your first AddKey, so you can enroll a new keypair in an emergency.
Remember:
After your first AddKey, unless BurnDown has occurred, every other protocol message your client software emits to the Public Key Directory MUST be signed by one of your currently-trusted public keys.
However, this sort of capability makes some people (especially power users) uncomfortable, so there is also support for Fireproof messages, which make the PKD reject any BurnDown requests for you.
Account recovery with any PKI is nontrivial. This is just how I chose to thread the needle in my proposal to satisfy as many use cases and threat models as possible.
We haven’t seen the Woodland Critters on South Park in 21 years, and although many thought that we’d never see them again, they make a roaring return to the finale of South Park’s Season 28!
Now the Critters were originally created as part of a Xmas story dreamed up by 4th grader Eric Cartman for a twisted Xmas story that he wrote, and while they appear cute, lovable, and child-like are really satanic creatures with dark powers including the ability to summon demons and hellfire. They engage in murderous and sadistic acts, including the torture and murder of Strawberry Shortcake.
There are a dozen Woodland Critters that include a bear, deer, rabbit, squirrel, and a fox. All are named simply by adding a “y” to their species name, so here we have Foxy the fox. (We foxes do struggle to control our dark side, you know.) Despite their apparent innocence, the Critters are quite sadistic, and use their dark powers to engage in violent and despicable acts that I don’t wish to even describe in a blog that tries hard not to venture beyond PG-13 territory.This time, the Critters are all excited because Donald Trump has impregnated Satan, who is going to give birth to the Anti-Christ. Things get very strange in a show that includes a talking towel prone to getting high, Towelie…
I know of no other show that has an anthropomorphic, marijuana-addicted talking towel as a recurring character. In Towelie’s defense, however, the government created him, and he’ll do the right thing when he knows what’s going on. He’s actually saved the boys from an evil towel on one occasion…
South Park at its best reverses and confounds our expectations, and the re-appearance of the Woodland Critters after a long absence from the series is an example of that, mixed in with the saga of satirizing the Trump administration and its key players for several seasons.- – Y’all have a Merry Xmas now, ‘ya hear?
At Lightbox Expo this year we met Kyky Yang, an animation artist and designer from Taiwan who’s living in Los Angeles now. She’s become well-known for her black & white “lesbian furry” web comic Detective Alice — and now, she’s self-published her first collection of it as a paperback graphic novel. Follow the adventures of British cat detective Alice and her maid Amaryllis. Visit the official web site — or check out the intro video on YouTube.
Happy December everyone! This has been in the works for a long time now, and it’s still a while away, but now seems like a good time to finally announce a project me and dozens of other local furs have been working on.
I am proud to announce
Furban Jungle
Hong Kong’s first furry convention in 2027.
The first year’s theme will be Street Life.
This will be a 2 weekend day event held in the function rooms of a hotel. This hotel is not fully confirmed yet, we will confirm it at a later date.
We are very excited to work and delivery Hong Kong’s first convention. We will work hard to deliver a new, fun, and unforgettable furry experience in Hong Kong.
The standard adult membership includes admittance to all four days of the convention. Minors age 16-17 please view the minor information page.
$99Age 16+
Sponsor Membership
Sponsors receive everything in the adult membership package, early access to the vendors’ room and convention store, sponsor gifts, discounts at the convention store, and admittance to a sponsors-only catered event.
$200
Super Sponsor Membership
Super Sponsors receive everything in both the adult and sponsor membership packages, plus access to a special badge pickup location, a commemorative medallion, and front of the line priority access at select events.
$325
Ultra Sponsor Membership
The Ultra Sponsor Membership includes everything in the adult, sponsor, and super sponsor memberships, as well as a luxury suite and a complimentary ultrasponsor badge for the guest of your choice. Membership Details
Thank you for your interest in being an Ultrasponsor. This form of support helps keep the convention accessible for a wide range of guests.
As an Ultrasponsor, you will receive:
Ultrasponsor collectible badge with front-of-the-line privileges for you and your Guest
Furry Family Winter Meal tickets for you and your Guest
VIP catered reception vouchers for you and your Guest
Daytime and Evening Hospitality Suite access for you and your Guest
50% off one of a selection of items at the Convention Store
A special gift
A prepaid luxury suite
Suite Accommodations
Depending on your level of sponsorship, you will receive either a prepaid Regency, Executive, or Summit Suite. Information regarding these suites can be found on the hotel’s website. Links are provided below for your convenience.
Suites are available for check-in starting at 4:00 PM on Wednesday, December 31, 2025. Check-out is at 11:00 AM on Monday, January 5, 2025. You may request additional days by contacting Anthro Northwest.
You will be responsible for any charges other than the base room rate and any applicable taxes and fees. These charges might include room service, gratuities, deposits, or any charges for damage.
All suites are on quiet floors and are not suitable for party rooms. Well-organized and respectful social gatherings are welcome.
Art by CMYKat
Art:  sticker</p>
<p>” data-medium-file=”https://i0.wp.com/soatok.blog/wp-content/uploads/2020/09/soatoktelegrams2020-08.png?fit=300%2C300&ssl=1″ data-large-file=”https://i0.wp.com/soatok.blog/wp-content/uploads/2020/09/soatoktelegrams2020-08.png?fit=512%2C512&ssl=1″ src=”https://i0.wp.com/soatok.blog/wp-content/uploads/2020/09/soatoktelegrams2020-08.png?resize=512%2C512&ssl=1″ alt=”High Paw (high five) sticker” class=”wp-image-1333″ style=”width:auto;height:256px”/><figcaption class=)
Art: 
 100vw, 768px” /><figcaption class=)
Art: 
 100vw, 512px” /><figcaption class=)
HONG KONG’S FIRST FURCON 
