Oddbean new post about login | logout 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..?