@soatok

I say “limited” because it will only not support editing or deleting messages provided by another instance. It will only append data. [...] contains an Asymmetric Public Key, the user and instance that hosts it, and other metadata

@soatok instead of using user@server.example identities, I'd recommend just using the Actor's @id property: this shouldn't include PII or usernames, and is a URI of an actor document your service could routinely check (e.g., if the server indicates a brand new identity, you could automatically revoke keys), it's also returned from webfinger already

@soatok this does pretty much match ideas I already had, just not a cryptographer so never knew how good those where.

@soatok Is this finally a problem that distributed ledgers / blockchain is a solution for?

Oh, I see...

"Oh, and best of all? You can get all these wins without propping up any cryptocurrency bullshit either."

@soatok @frost I'd definitely go with `@id`s over `@@` handles. Mastodon is the odd one out for strongly keying on the latter and it's making life much harder for other implementors if they want to allow user-visible-handle changes (which would otherwise be trivial under AP).

That said, `@id`s are definitely PII in almost all implementations too, since most use predictable name-based URLs for that. You most likely need to make the server the authority for generating primary keys on request, or someone is going to make them predictable in a way that can't be disassociated from later.

Edit: User names also aren't 1:1 for identities. There's a primary one (usually), but any number of handles can refer to a single `@id`. The most common use is probably case-matching, but it can also be done cross-domain iirc.

@soatok
Thanks for even doing the thinking about this! End-to-end-encryption and key management that isn't centralised is ... 😬 hard to get right

question: i don't see any verification of the identity. what's to stop me AddKey'ing my key as @soatok and not AddKey'ing your key until you pay up

also, what happens when someone deletes their account, ~~and also what happens when someone creates a new account with the same username~~ i guess this is no longer needed if usernames aren't the identifier

@soatok New PKI, sweet! Looks like it associates a string with a key in an append-only way? If that string doesn't need any special structure (say, a url pointing to a server that speaks a certain protocol), then it could be useful even for non AP-related projects?

Thanks for this post and your work! This will solve one of my current issues. @soatok

@soatok how would you handle a case where a server misses or is slow to process deletekey messages? Wouldn't some queries return keys that had actually been expired?

If a person tried to use an expired key, would they just fail to communicate with the recipient? (And that could present a bad experience)

@soatok The stated goals are similar to those of FEP-c390. In FEP-c390, however, the key is linked directly to an actor object, it doesn't require a separate server.

>We want Fediverse users to be able to publish a public key that is bound to their identity, which anyone else on the Internet can fetch and then use for various purposes.

@soatok Interesting that revocation is *only* allowed when another key is live.

Does this mean that there would be no equivalent of a "revocation certificate", a pre-signed message that can be stored offline and produced at any later time to just say "this key is revoked"?

I guess you could mimic that by making an AddKey + RevokeKey pair. K1 adds K2, K2 revokes K1.

@soatok Why can’t we move towards the #nostr model? This seems like bolting on a Keybase-like idea on top the #fediverse. I’d like to see derivable identities from a main secret key, which you can then use to sign/encrypt messages. This would seem to completely solve the instance-hopping issues newer users have at the same time – your identity is tied to the secret key signing the messages.