indians have consequences
@sun@shitposter.world dw his nephew who got hired via nepotism is on the job, it'll be fiiiine
The Mitra implementation uses DIDs instead of domains I think, anyways paging @silverpill 😊
>it works its just obviously bolt-on until every server just natively supports keys
Yeah, never happening.
@phnt@fluffytail.org @anemone@ebiverse.social @sun@shitposter.world @silverpill@mitra.social @rees@pleroma.ree.social what if we had a "minimum protocol compliance specification" that includes things users actually ask for not things eugen feels like adding
@rees @anemone @phnt @jaff @sun
It's not a new protocol. ap-next currently has two goals:
1. Documenting how ActivityPub really works vs what one could find in the specs: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md
2. Extending ActivityPub protocol (the "real" one) to support new features such as cryptographic identities: https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
@silverpill@mitra.social @phnt@fluffytail.org @anemone@ebiverse.social @sun@shitposter.world @rees@pleroma.ree.social after skimming a few of the specs I feel like nomadic identity as defined there has too many moving parts and something simpler like "this web finger user also has this client public key, here it is signed by domain key, and here in the user profile the client key is attesting it is currently owned by the domain key, here is just the signature figure it out" (with a spec on how to figure it out) would get more servers implementing this feature. Having multiple key slots complicates everything and any kind of history can be derived over time by observation. I am not sure there needs to be a standardized interface for nomadic identity migration verification at first.
is there a "minimum compliance specification" for ap nomadic?