Oddbean

For whatever reason, NIP-26 didn't catch on last year. Clients weren't implementing it. This prompted Pablo to build nsecBunker, which is honestly very close to all of this discussion. He never added policies, but I'm assuming if he did, you'd be able to setup this advanced workflows for revocation and expiration.

I see. That's a shame. Well, as long as that isn't solved it will be very hard to convince any non-single-person entities to use nostr. One guy leaves your company/team/org & your nsec is forever rekt.

Agree. Revocation and expiration are very important. nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3camnwvaz7tmrda6kuarjd9jhxtnxd9shg6npvchxxmmd9urtqukr any chance to make this easier with NAK? Though, I guess for revocation, you just stop launching with bunker with the existing string and just start a new one and then give everyone the updated string. Not the end of the world to redistribute the connection string and have people sign in again.

you also need to have countermeasures for key loss and revocation for breach, and it essentially also kinda means it needs threshold signatures which are easily doable with bip-340 schnorr signatures, but you need a scheme to pre-state signatory pubkeys as tags before any signatures are applied to the event it's a whole key management protocol if it is to really be secure, and that *requires* that the organisation *must* also be caching all relevant events in order to prove authority and maintain this for events as they propagate (so they have to broadcast them) which comes back to another of my hobby horses which is the idea of broadcast vs narrowcast event types and the informal notion of authoritative archivist relays - the signatures are secure, but if the events are lost the authority is too