Nostr Web Client

How does a company have (a) an nsec powering an important corporate Nostr account, and (b) full confidence that not a single person at the company has copied it or could have copied it since generation?

Who generates the nsec then? Who creates the first FROST shards? What's the security flow? I can't see any security flow that could guarantee that outcome. At best you could be somewhat sure that only a single person could have theoretically copied it.

If Nostr got big and I ran a large company, would I tolerate even the possibility of someone other than myself having seen the nsec for our wildly successful Nostr corporate account? I wouldn’t, not a single person. And if I was aware that a single person could have theoretically copied the nsec at any point since its generation, no matter how theoretically, then that’s it, I would nuke the corporate account then and there (unless I'd picked that person to outlast me and take over).

*be pretty hard to find a large company that happens to hold Bitcoin but is not in the tech or Bitcoin space AND holds its own keys too; just not workable. All would be at Coinbase or what have you.

** a souped up relay taking some aspects from how Flotilla relays work, not Flotilla the client itself

Vitor Pamplona 10mo ago

It's exactly the same procedure you run for a Corporate Bitcoin wallet. Corporations that manage Bitcoin all have a seed phrase stored somewhere. When the seed is created, all the involved parties can see all words. And there is always a backup seed somewhere. In theory any of them can make a copy to steal the coins later. So, your physical environment during the seed creating has to block that from happening as much as possible.

Also, I wouldn't have just one master account. Companies generally have multiple corporate accounts to make sure not all their eggs are in the same basket. I would create 5 or 10 and grow them all independent of one another to make sure you have a voice even if something happens.

Remember, their Nostr key is just their voice. It's not the company itself. The company will survive if the key leaks.

In the end, they will never recover a leaked account, regardless of how well you protect it. So, as a company you need to have a plan B that is outside of that account: getting another account up to speed.

With FROST, you can run a software scheme where a single computer somewhere secluded generates a key and shards it to the top level folks. As long as that computer is protected and offline, it should be fine and no one needs to see the full key. You can even copy that in 2-3 computers in separate locations to make sure you have a backup.

Once the shards are out, you can just close the location and not allow anybody in to see the seed.

In the future, this could be just a Nostr hardware wallet of some sort. You don't necessarily need a computer. The seed would be stored into that device.

Reply to this note

Please Login to reply.

Discussion

Garbage nsec 10mo ago

Thanks for the thoughtful breakdown, I think the isolated/autonomous Frost-shard generating device is a pretty interesting idea.

But coming back to relays, as far as I understand NIP-29 relays themselves have keypairs and can generate administrative events (I see now that Flotilla came to NIP 29 only later on so maybe not the best example for NIP 29, but regardless)

I also understand that the relay admin can also swap the relay's keys out. The relay would then need to update the group metadata to reflect the new public key, the update would then need to be disseminated, etc. So not the the relay URL is ultimately where the validity lies at the end of day, just as for a cashu mint.

At least that's how I *think* I understand it NIP 29 relays.

Could not this setup be tweaked to allow for relays with keypairs and that can publish actual notes in addition to administrative events? And if so, could these relays also not be surfaced by the likes of Jumble, once the parsing logic is there (check the metadata for the public key, etc.) Another NIP, but taking some inspiration from NIP 29.

That's the sort of companies-as-relays concept I'm squinting at.

Or am I missing something important here?

Vitor Pamplona 10mo ago

Relays can have keys. But those keys are not the company itself. They just manage things on the relay (groups and so on). They don't need to be the same keys as the corporate keys. In fact, I think you want them to be different to give them to different people in the organization.

I much rather see things separately. Every time we merged different concepts in one (like relays and service keys) we got a worse, more centralized solution.

Garbage nsec 10mo ago

> But those keys are not the company itself.

My thinking is what if those relay keys in fact were the company itself? They're easily managed, as long as the company retains control over the relay URL. There's no scary permanence. They potentially allow the relay itself to be personified to a degree, so to post, and take part in discussions, etc. , in standard fashion. So again more like a Facebook page versus a Facebook profile—very-different-under-the-hood and purposefully so.

It's a merged concept, yes, and centralised, yes—but companies are centralisaed, and this is a way to for to allow centralised entities to take part in Nostr in a way that doesn't require a crash courses in bleeding-edge shard and bunker based key management.

Though again maybe the whole nsec route with the right flows and hardware could be less terrifying for un-savvy companies that I suspect it is, you've put me on to some stuff to mull over there.