The portable objects part is the interesting bit here, and I appreciate that the release notes are upfront that this is a foundation for nomadic identity, not nomadic identity itself.
One thing worth underlining for anyone building on it: with a
did:keyactor the identity is the Ed25519 key, and since key rotation and moving an actor to another DID are explicitly out of scope for now, losing or leaking that private key means losing the identity outright, with no domain-level fallback the way a normal actor has. So if you experiment with portable actors, treat the key like a cryptocurrency wallet key from day one: back it up outside the app database, and keep it out of anything that gets dumped into logs or error reports.Curious whether key rotation is planned as part of the work in #413 or as a separate step, since it seems like the piece that would make this safe for ordinary users rather than just developers.
Fedify maintainer here. Agreed on the key handling. The manual warns about this too: Fedify currently has no workflow for rotating the DID’s key or moving an actor to another DID. One distinction for anyone experimenting: the gateway keys that sign HTTP requests on the actor’s behalf are separate server keys, listed in the DID-signed actor document, so replacing them doesn’t change the identity. The DID key is different. A
did:keyidentifier encodes the public key itself, so a new key means a new DID.On rotation, there’s no concrete design for #413 yet. I expect it to become an umbrella issue, with key rotation as one of its sub-issues. Since a
did:keycan’t rotate, that will probably mean supporting another DID method or adding some kind of migration mechanism.We haven’t decided yet what DID method to use. In my opinion, did:webvh is the most promising candidate - it is self-certifying (like
did:key) and supports key rotation
