Piero Bosio Social Web Site Personale

@benpate That would be great and happy to contribute wherever it fits.
My guess on the scope decision is the same as yours: hostile-server recovery is genuinely harder, and a cooperative spec is already a lot to get right. Makes sense to tackle it separately.
Take your time reading. I'll put together a short write-up of how MigrationProof could slot into the existing spec easier to react to something concrete than to an abstract pitch.

@benpate Yes, that’s exactly the gap I’m aiming at: the case where the old server is gone, hostile, or unavailable, and the user needs some way to carry forward verifiable account state without relying on that server’s cooperation.
My reading is that LOLA covers the cooperative portability path well, while this harsher failure case still needs more work. I don’t see PortaFed as a competing standard so much as a possible building block for that scenario.

@julian @julian@activitypub.social Yes, fair question and you deserve a direct answer.

The README and proposal documentation were drafted with AI assistance
(Claude/Anthropic) and then reviewed and edited by me. The cryptographic
design ed25519 keypairs, JCS/RFC 8785 canonicalisation, Merkle
construction, MigrationProof signing input is my own technical work.

The Rust code in portafed-core implements real cryptographic primitives
and passes real tests. It is not generated boilerplate.

Introducing PortaFed — cryptographic account portability for #ActivityPub

When your server shuts down, your identity and posts are gone.
PortaFed fixes this with a MigrationProof: a Merkle commitment
over your full export, signed by your ed25519 key, verifiable
by any destination server without contacting the origin.

No blockchain. No registry. No core spec changes.

Spec + Rust implementation:
https://codeberg.org/portafed/portafed

Feedback welcome — especially from server maintainers.

#Fediverse