Nostr Web Client

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.

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?

Reply to this note

Please Login to reply.

Discussion

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.