Oddbean new post about login | logout It just dawned on me that we could easily build something that would allow certain npubs to post in the name of another npub, solving the "company account" problem in terms of key rollover. Anyone working on that? #asknostr
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.
NsecBunker does that I think, and there is a nip that allows delegation, you post with another npub and clients should assume that it's like it was from the original npub.
Similar to NIP-26 Delegation?
NIP-26 doesn't allow for revocation, or does it?
It does.
And expiration dates.
Oh, that's awesome. That might be enough already. In that case: do any clients support what I'm describing already?
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?
Damus runs a server with its pubkey and exposes a stupid API the intern has limited access to. Or do it with NIP-46/nsecbunker and custom rules.
So everyone who has a company account should run a server?
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)
A small bakery might be such a company, and I don't see the bakery at the corner running a server for this. Just saying. Appreciate your thoughts, though.
yet they have a little box on the counter to do lightning payments?
i'm pretty sure you are old enough to remember when it would seem ridiculous for a bakery to even have a computer but here we are
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
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.
I see. That's a hard problem. Any proposals towards a solution?
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.
Ah. Is that why it was essentially abandoned for NIP-46?
yep. There are other problems as well, but that is the main one for company-accounts (immediate expiration is paramount)
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>] } It doesn't.
I've seen physical hardware devices that had expiration dates on their UI. So you're saying that they don't work? https://gist.github.com/kdmukai/089ff308506058973974479ae4b64b42
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.
Thanks for the clarification. You may go back to bad dad jokes now.
Of course we'd need to define an event type that will be understood as "npub1 posting in the name of company" - but that should be straightforward.
@Gzuuus
I think what I'm describing is way simpler than threshold signatures.
there is a small problem with it that it requires some consistency in the event records though... any garbage collection scheme for event data would need to respect the connection between delegations and acting in the name of events
oh yeah another tricky one, so, the identifier, is it a pubkey, and someone has the secret, or does its authorised representatives solely make event references that designate an npub to be representative (or remove them), and then you have at least 3 levels - the owner, who first registers the name, do they have extra privileges to add and remove designated npubs? or even cancel the registration, and if not, then you need some scheme of administrators for the name versus simple representatives it can all be done but it essentially amounts to an access control list it could be interesting to actually formalise the concept of access control lists altogether, as tehy can have private-to-relay meaning as well as representatives and even company hierarchy trees
I believe that this can be achieved in different ways. The determining factor will be the design you want to implement. Right now, at a high level, I see two possible approaches. One is an interactive process, where note sharing, validation, and publication are done by humans without relying on extra servers, just relays. This process can be enhanced by using off-band communication and NIP46. The other approach is non-interactive, where the process is delegated to a server that has all the necessary information. In this scenario, if an authorized npub sends an event to the server (which could be a dvm), the server will publish it under the npub of the company.
Is this idea different from @PABLOF7z was doing with nsecBunker? That is the most promising solution I’ve seen so far but not sure what’s happening with it any more. The website he had for it is down too.
nsecBunker is awesome but different idea. But I'm pretty sure Pablo will found a way to add what I'm describing to nsecBunker in some way 😂😅
No doubt 😂 Trying to understand what’s different between what you’re describing and nsecBunker as it could do what it sounds like you’re describing. I could use it to delegate access to an account without sharing the nsec, I could limit the event types the delegated access could sign, and I could revoke access.
Yeah, Pablo himself hold me he needs to rework the whole thing. The best working nsecBunker is NAK, but sadly it's not point and click easy for everyone to use.
This would be an even bigger win than integrated GIF search 😁🤣
https://media.tenor.com/t33y2vV7in8AAAAM/jimmy-mcnulty-the-wire.gif
You’re right, *almost a bigger win than integrated GIFs
We're looking at something similar in the Places NIP where authorised npubs can add info (like the labels NIP). https://github.com/nostr-protocol/nips/pull/927
Or just use Amber's NIP-46 as a signer. Your employees can write the post and send it to your phone to approve it. You hit ok and it goes back to them for publishing.
That sounds like a pragmatic and currently workable solution. I'll experiment with that. Thanks!
I am sure nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9usjfpck can help improved it if needed. (not a lot of people are using it like that today)
Thank you, appreciate it 🙏
Side question, feel free to ignore: how do you deal with permissions in the spreadsheet thing you built nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug?
not at all orthogonal, the whole subject is access control lists i think it should be zoomed back out to the generic form so we can have them properly they can then also be used to internally recognise such things as authorised readers, authorised writers, on relays, on org charts for organisations, for read/write permissions on shared documents, etc etc adlib to fade
Basically, each spreadsheet holds its nsec inside encrypted tags to each editor. If you have editting permission, you can use your nsec to decrypt the sheet's nsec and use it to modify the event. Unfortunatelly that also means that once granted, each editor can save the nsec offline and keep it forever. :(
Wouldn't block hashes solve revocation, as they can't be faked like timestamps can be faked? As in: "I hereby revoke your writing permission from this point onward: 00000000000000000003509af203f00a74cada8024e017982fe9c499751f36de" https://mempool.space/block/00000000000000000003509af203f00a74cada8024e017982fe9c499751f36de
Yep, but most clients and relays don't have a copy of the chain to access. It's the same problem of why almost no client implement open timestamps. Since delegation must be part of the core protocol to be usablel, it's hard to justify adding Bitcoin as a dependency of the base protocol.
Hm. What if we use a list of mempool instances as a multiple-and-exchangeable-source-of-truth, just like we have a list of relays? 🤔
I don't know.. everything feels so easily hackable when stakes are high... We could also not use bitcoin at all and keep the company's relay url in the expiration token. The relay url becomes the source of truth because it is controlled by the company. Clients just need to check the delegation authority written in replaceable events in that relay. In that way, we bake the "how to find the most up-to-date authorization replaceable" into the delegation token. Kinda similar to a nostr-native NIP-05. The delegation is checked every time the post is displayed. But I trully think a better solution is a hardware signer that the company can write an nsec into it and the user can never take it out or copy. Company could buy a few of those and hand them away. The signer connects to the company's system to check the expiration every time it signs. Once the company removes authorization, the device becomes a paperweight.
Thanks for sharing your thoughts. Appreciate it 🙏🧡
BTW, I think you can hand a phone away with Amber pre-installed with the company's nsec. I would just put the phone in an MDM system where the company can reset the entire OS from a distance.
The NFC n424 chips used by Boltcard are often used as pin protected ID badges, that just need to access a directory to confirm/deny verification. Seems like having that as a directory of approved Users accessible in a private Nostr relay can allow the same functionality, to create an physical Nostr-signing device. Am I wrong, or will something like Bitwarden on a Start9 OS be necessary for keeping that data directory available..?
@cloud fodder does nip 42 allow for this?
it would be an extension of an access control list system, the "name" would be a special tag and the posting rule would be "whoever has been designated a delegate to post with this tag" it would work a bit like a team blog the actual delegations don't have to be public but probably have to be public, so there would be a public (broadcast) message signifying delegation that would need to be part of what goes out to other places to syndicate it, and internally this could regulate the ACL i started working on an ACL with similar ideas just for controlling access to the relay
What if the company owner could split his key that he generated on the phone into 3 shards and give each shard to a different cloud service providers and they would collectively perform musig2 and sign stuff on his behalf using NIP-46 without ever being able to recover their key unless they all collude? And they also offer fine-grained access control for interns and employees and so on. @waxwing is this ok?
Basically Shamir's splitting right?
IIUC somewhat similar but with musig you don't have to reconstruct the secret to sign a message, so with musig there will never be an assembled secret in one place you could steal. Every participant has their own secret and then they agree on a message and share partitial signatures that can be assembled to the complete signature. With sss you first assemble the shared secret, then you could sign a message with it, but the assembled secret could be stolen and then your complete security is gone.
