Oddbean

How it could work: give npub1 npub2 & npub3 permission to post in company's name. Use replaceable events signed by company to keep a list of permissioned npubs. No need to share company's nsec to post. Permission to post might be revoked at any time.

Example: Vanessa, Will, and the Damus intern might want to post as the Damus account, but the intern shouldn't necessarily have access to the Damus nsec. Do we have clients that support this already?

Every company requiring this type of functionality I'm the non-nostr world has to run a 'server'. Sure they can get free up to 10 seats from Google or whatever to have their employees send email from their domain, but that's not really free that's a trial of a paid server. Nostr is no different. If you're a company you should probably have a relay suite, and this server acts much like googles suite for your company. It can have extra features there like, keeping company notes, running bunkers, have apis, manage nip05s, run bots etc. So as nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp said, it would be easy to have a bunker or API to handle the access to a single company key and revokation would be instant. The eventually inconsistent nature of the public nostr network is not going to be able to come to a consensus on something like a key rotation. Just like delete is in the spec, the deletes are very hard to propagate. The same would be true for any attempt to revoke a key. However, the NIP87 spec for private groups does do key rotation for a private group, but this requires the group to be on a limited number of relays as part of the spec. Perhaps delegation could work this way, but the reach of the notes would be limited to a set of relays. Notes would be more relay specific, and a combination of outbox and relay specific notes would need to be implemented in clients. At which point you would likely still want to run a relay for the company, but you could 'trial' the functionality on any set of relays that you trust enough for your purposes.

mainly for public viewing you just need the essential authority events to be broadcast along with the rest broadcast vs narrowcast is critical in any attempt to make nostr usable both as an open public network and as the basis for private/business use and being able to define boundaries... this also definitely requires custom relays as this simplifies the issues of how to make what is intended to be public, public the relay would respond to certain event types by activating some kind of functionality where the relay becomes a client to broadcast to other relays (like a selective version of blastr)

The number of startup companies that onboarding just gives you shared access to a set of shared passwords is near 100%.. so I guess with nostr the only difference is we can't change the password easily 😎

I also don't see a bakery at the corner holding keys -- I guess the owner would have some keys on his phone or something? But this is trying to fit a dystopic world (yes, people with phones is a dystopic world, in a saner world people would have computers where they could run an nsecbunker). But I also agree with you.

Don't be dismissive about the future tech prowess of "ordinary businesses" or "ordinary people". Ordinary businesses and people managed to type on a keyboard, run wifi or send email amongst others which all seemed need stuff out of reach at some point.

Small businesses do run servers, and if they don't they will use a provider to help them with this, e.g. WP Engine and Woocommerce for small business is actually big business. Don't underestimate the multitasking that small business has to do, bakery or not, we have to do all the things ( I'm speaking from first hand experience here in an industry that is not software/tech heavy) . Also the bakery in my area has its own IT, and its a small bakery but also a cafe/restaurant, which has its own separate needs for IT

We talked about this recently will said clients didn't adopted : nostr:nevent1qqszzrj0tvacpg0m24dvm70k8z0s4hppjxkau8xsql8gjfrt73xwgsspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzymswzmwwrl0tma6f90m8t22lre7xypwhhkcl5detttzsnr360pvpsgqqqqqqsd8ae7q

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

NIP-26 has broken expiration. Because the key continues to have access to posting as the other account as long as the post has a created_at within the active dates. Ex-emplooyees have the right to post in the past FOREVER.

Lots of half-backed solutions that no one ever implemented. The reason I proposed deprecating NIP-26 was to make it clear it doesn't work as people expect and we need a new solution for delegation. If NIP-26 stays there it just confuses everyone and leads to people giving up new ideas because something already exist.

NIP-26 also uses a full word "delegation" tag that most relays don't index. It should use a single letter tag with the companies pubkey so people can get all company posts with a query { "authors": [<company-pubkey>] } union the results of { "#D": [<company-pubkey>] }

Sorry, expiration dates yes, but not arbitrary revocation. Anyway, none of these delegation schemes works without some giant bloat or clients and relays and/or a lot of state required for the most basic tasks. Maybe it's a good idea to make the entire protocol a magnitude more complex so we can offer that kind of stuff, but for now I'm firmly in the camp of it-isn't-worth-it and nsecbunker-is-probably-enough, but also most-people-will-use-custodial-keys-anyway and that's-fine-because-most-people's-keys-aren't-really-super-important-and-can-be-rotated-manually. We also have https://github.com/nostr-protocol/nips/pull/829 for migrating compromised accounts, which is somewhat related to all of this and pretty reasonable.