After I finish implementing rate-limiting and finish the docs, the server-side software should be feature-complete.

The PHP client is essentially feature-complete already.

However, I still need to write proofs and generate the official test vectors. And then update tests. And then improve test coverage. And write more docs.

The work isn't finished when the features exist. They need to be proven good enough (secure, at the very least).

That said, I wish I had anything more interesting to talk about during all this.

It's just... the work that needs to be done. Nothing exciting or sexy, I'm afraid.

If you want your Fediverse software to be "PKD ready" when v1.0.0 is tagged, all you need to do is:

1. Support RFC 9421 HTTP Message Signatures
2. Support FEP-521a with Ed25519 keys

If anyone wants to help with PKD adoption, this is the nail that needs hammering across all of Fedi.

As long as those requirements are met, the rest of it can be done client-side without the instance software's involvement.

(Publishing messages is just sending a protocol message over a DM. As long as your instance includes an Ed25519 signature on outgoing messages, it'll "just" work.)

If you want your moderators to be able to issue a BurnDown for account recovery (in the event that you lose all your signing keys), the software will need a small patch to be able to enroll in TOTP and send BurnDown messages to the correct API endpoint, but that's not essential.

PKD adoption does not by itself give you E2EE.

See https://swicg.github.io/activitypub-e2ee/ by @evan, et al. for that project's draft specification.

However, tying the two together will be very simple: https://github.com/swicg/activitypub-e2ee/issues/35#issuecomment-3738855995

I made a small website (hosted by GitHub pages) to track the project status at a glance: https://publickey.directory

In the coming months, this should include some basic demos and possibly a Proof of Concept :3

@soatok i'm about 80% done setting up a bot on grilledcheese that will help check and echo back if a server's RFC HTTP signature and/or FEP assertion proof are working right...

admittedly this is more like handing out hammers & nails than actually building the house, but i'm hoping it helps make these less daunting