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 @npub17uvdf... (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!