Introducing PortaFed — cryptographic account portability for #ActivityPub
Fediverso
13
Posts
7
Posters
12
Views
-
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/portafedFeedback welcome — especially from server maintainers.
-
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/portafedFeedback welcome — especially from server maintainers.
:eyes: new account portability spec dropped. We're at 3 now? :sweat_smile:
@evan@cosocial.ca @benpate@mastodon.social @jonny@neuromatch.social
-
Something we need. Looks to be NLNet funded? The README looks to be AI written, it contains a lot of the confident triple-statements often found in LLM-generated content. I hope that is as far as it goes because this might be brushing up against NLNet's generative AI policy: https://nlnet.nl/foundation/policies/generativeAI/
@portafed@mastodon.social may I ask whether LLM was used in the production of this project/code?
-
Something we need. Looks to be NLNet funded? The README looks to be AI written, it contains a lot of the confident triple-statements often found in LLM-generated content. I hope that is as far as it goes because this might be brushing up against NLNet's generative AI policy: https://nlnet.nl/foundation/policies/generativeAI/
@portafed@mastodon.social may I ask whether LLM was used in the production of this project/code?
@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/portafedFeedback welcome — especially from server maintainers.
Bravo! I like the idea, and honestly I was thinking of making something similar myself. Maybe I’ll implement it into my platform.
-
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/portafedFeedback welcome — especially from server maintainers.
-
@PortaFed ~ do you think these ideas would work alongside the existing work being done by the W3C social web community group? https://swicg.github.io/activitypub-data-portability/lola
I *think* you're solving the issue of "my server disappeared, I don't have a backup, and I can't prove I'm still me." Is this close?
Because that's the one use case that the portability spec DOESN'T do. So, maybe there's a way for us to work together, instead of making competing standards.
-
@PortaFed ~ do you think these ideas would work alongside the existing work being done by the W3C social web community group? https://swicg.github.io/activitypub-data-portability/lola
I *think* you're solving the issue of "my server disappeared, I don't have a backup, and I can't prove I'm still me." Is this close?
Because that's the one use case that the portability spec DOESN'T do. So, maybe there's a way for us to work together, instead of making competing standards.
@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. -
@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.@PortaFed That's awesome. Let's work you into the existing effort. We could use all the help we can get.
Also: I'm pretty new to the data portability spec; so I know that "hostile server" is out of scope, but I wasn't there to know why that choice was made. I'm *guessing* is was too much to tackle at the time.
But one way or another, it would be great to have something in place for this situation, too.
I still need to read your work fully, so I understand what we're talking about :)
-
-
@jonny@neuromatch.social tracks doesn't it 😝
-
@PortaFed That's awesome. Let's work you into the existing effort. We could use all the help we can get.
Also: I'm pretty new to the data portability spec; so I know that "hostile server" is out of scope, but I wasn't there to know why that choice was made. I'm *guessing* is was too much to tackle at the time.
But one way or another, it would be great to have something in place for this situation, too.
I still need to read your work fully, so I understand what we're talking about :)
@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. -
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/portafedFeedback welcome — especially from server maintainers.
I have a couple of comments regarding the spec https://codeberg.org/portafed/portafed/src/branch/main/portafed-spec/spec.md
It contains a comparison with FEP-ef61, but it is not quite correct:
- FEP-ef61 identity is not actor-rooted. The closest equivalent of FEP-ef61 identity in normal ActivityPub is a server with a domain name. A single FEP-ef61 authority can manage multiple actor documents.
- FEP-ef61 does not lack a migration flow. Strictly speaking, it doesn't need one, because data is not attached to a server and can be continuously synchronized between multiple servers. But a more familiar migration flow is also possible via outbox export-import.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
I have a couple of comments regarding the spec https://codeberg.org/portafed/portafed/src/branch/main/portafed-spec/spec.md
It contains a comparison with FEP-ef61, but it is not quite correct:
- FEP-ef61 identity is not actor-rooted. The closest equivalent of FEP-ef61 identity in normal ActivityPub is a server with a domain name. A single FEP-ef61 authority can manage multiple actor documents.
- FEP-ef61 does not lack a migration flow. Strictly speaking, it doesn't need one, because data is not attached to a server and can be continuously synchronized between multiple servers. But a more familiar migration flow is also possible via outbox export-import.
-
@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.
-
@jonny@neuromatch.social tracks doesn't it 😝
-
-
Warm up the fire! We're LIVE!
Summer in Winter: Norcal Gma 2's Journey with her Dog - E79
#owncast #streaming #interview #fediverse #fedi #people #show #firesidefedi #FsF
-
@PortaFed That's awesome. Let's work you into the existing effort. We could use all the help we can get.
Also: I'm pretty new to the data portability spec; so I know that "hostile server" is out of scope, but I wasn't there to know why that choice was made. I'm *guessing* is was too much to tackle at the time.
But one way or another, it would be great to have something in place for this situation, too.
I still need to read your work fully, so I understand what we're talking about :)
-
@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.
-
@PortaFed ~ do you think these ideas would work alongside the existing work being done by the W3C social web community group? https://swicg.github.io/activitypub-data-portability/lola
I *think* you're solving the issue of "my server disappeared, I don't have a backup, and I can't prove I'm still me." Is this close?
Because that's the one use case that the portability spec DOESN'T do. So, maybe there's a way for us to work together, instead of making competing standards.
