Nostr Web Client

hey nostr:nprofile1qqsgzu4eypfy0h07nxmcxvs8stgrztarqksen7etaz37v437yz60pcspzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uzkvpwz nostr:nprofile1qqsyy2wzruqsr27rhfzjx0shd6t4l20xwxa33fnj900hwf46y4z9l7gppemhxue69uhkummn9ekx7mp0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tc4w0e7l i've been seeing all the progress yall are making with frostr and was wondering if you are planning on advertising what's being worked on to nostr users?

it seems very promising but i don't see much talk about it which is a shame. theres also a few things i don't quite get.

how does this protocol protect shares that have not been compromised in a scenario where an attacker would have control over a share ? wouldn't the compromised device allow for a request to get something signed from other devices/shares and succesfully get it back?

i think i saw theres a way to make it so that only certain shares can make requests to others or something along these lines?

a detailed explanation on how to properly and securely adopt frostr for one's keys on that regard would probably be useful to new users.

Reply to this note

Please Login to reply.

Discussion

richard 3w ago

nostr:nprofile1qqsgzu4eypfy0h07nxmcxvs8stgrztarqksen7etaz37v437yz60pcspzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uzkvpwz nostr:nprofile1qqsyy2wzruqsr27rhfzjx0shd6t4l20xwxa33fnj900hwf46y4z9l7gppemhxue69uhkummn9ekx7mp0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tc4w0e7l

bitcoinplebdev 3w ago

Hey, so sorry for the late reply! You’re totally right we haven’t been that good about communicating the work that we’ve been doing the last six months. Honestly, we were hoping to finish the “full suite“ of our apps before we did big public announcement and have everything working at once. We are having delays on the mobile apps though so just trying to get everything out there now and update documentation and comms which is why I made @npub17uvdffljczhlpjfvfj0q30dmh4ugh8wlzm8u6w64y2v4ts7fqsqqj28tr4 (running frostr btw)

When it comes to protecting your shares, if they get compromised, it’s important to understand that the actual NSEC cannot be recovered unless you have the threshold of shares in custody LOCALLY. You cannot recover the NSEC remotely in any kind of way. It is still manual. However, depending on how your peer config is set up, it is possible that if someone steals a share, they can get a note signed in collaboration with another one of your shares (running on a signer)

Onto how to mitigate this (and your next question) right now there is very simple permissions that you can configure with peers. Basically each share can have its own peer config that simply says what shares in the keyset are allowed to make requests to it and what shares it makes requests to. In this set up, you can have a single primary share. That is the only one allowed to make request requests (this is only enforced on the networking layer right now)

Lots more updates and improved documentation coming soon!