Introducing PortaFed — cryptographic account portability for #ActivityPub
-
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.
<img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f440.png?v=42a4d91a3c1" title="
" /> new account portability spec dropped. We're at 3 now? <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f605.png?v=42a4d91a3c1" title="
" />@evan@cosocial.ca @benpate@mastodon.social @jonny@neuromatch.social
-
R relay@relay.an.exchange shared this topic
-
-
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. -
R relay@relay.mycrowd.ca shared this topic
-
@julian @PortaFed
giving a further read: I can't really imagine a case where someone would a) regularly be creating signed backups and also b) know in advance where you wanted to migrate to to set thedestination_did. Like if this is for the case where the instance has shut down, you might have some signed backup, but you probably haven't planned in advance where you would want to migrate, and if the instance is down you wouldn't be able to create the migration object after the fact.the validation strategy for the export is sort of mystifying to me. if the whole object is signed, then why would you need a merkle tree for objects and also an object count? if the contents of the object have changed post signing, then the signature validation will just fail and those are irrelevant.
true to form for LLM generated documents, several critical things are left undefined, like what
last_accepted_sequenceis or how that works.probably the most important problem is that it's not really clear how all other instances are supposed to handle this, which is the entire hard part of a migration spec. Like, if the purpose here is to preserve identity, then you would need to have all the other instances come to see the new identity as being equivalent to the old identity, and there's no discussion of how that process works for third-party instances at all. like e.g. in FEP-1580 i had to spend a long time gaming out scenarios for how third party instances would handle a move event.
so without that it's not really an account portabiltiy spec, it's an account export/import spec, which is fine, just not really needed since signing objects and collections (which this spec should use anyway) is already described by other specs.
-
@julian @PortaFed
giving a further read: I can't really imagine a case where someone would a) regularly be creating signed backups and also b) know in advance where you wanted to migrate to to set thedestination_did. Like if this is for the case where the instance has shut down, you might have some signed backup, but you probably haven't planned in advance where you would want to migrate, and if the instance is down you wouldn't be able to create the migration object after the fact.the validation strategy for the export is sort of mystifying to me. if the whole object is signed, then why would you need a merkle tree for objects and also an object count? if the contents of the object have changed post signing, then the signature validation will just fail and those are irrelevant.
true to form for LLM generated documents, several critical things are left undefined, like what
last_accepted_sequenceis or how that works.probably the most important problem is that it's not really clear how all other instances are supposed to handle this, which is the entire hard part of a migration spec. Like, if the purpose here is to preserve identity, then you would need to have all the other instances come to see the new identity as being equivalent to the old identity, and there's no discussion of how that process works for third-party instances at all. like e.g. in FEP-1580 i had to spend a long time gaming out scenarios for how third party instances would handle a move event.
so without that it's not really an account portabiltiy spec, it's an account export/import spec, which is fine, just not really needed since signing objects and collections (which this spec should use anyway) is already described by other specs.
@jonny @julian You're right on all three points. Updated the spec: destination_did is now optional the backup-before-shutdown case is the primary use case and requiring a destination in advance was a mistake.
Added Section 5.1 explaining why the Merkle tree exists alongside per-object signatures: the signatures prove per-object authenticity but not completeness. A Merkle root over the full set detects silently dropped objects.
Added Section 8 explicitly scoping this as an export/import substrate -
@jonny @julian You're right on all three points. Updated the spec: destination_did is now optional the backup-before-shutdown case is the primary use case and requiring a destination in advance was a mistake.
Added Section 5.1 explaining why the Merkle tree exists alongside per-object signatures: the signatures prove per-object authenticity but not completeness. A Merkle root over the full set detects silently dropped objects.
Added Section 8 explicitly scoping this as an export/import substrate
