I don't understand the receive/send distinction and why it's important. Is it just that you want certain shards to be passive and unable to initiate requests because they're in an untrusted context? This seems like it could be a nice complement to the usual pattern of nagging the user about every permission request. On promenade, I highly encourage you to check it out: https://git.fiatjaf.com/promenade It's currently used by https://start.njump.me to encourage new users to get started with a multisig bunker, without having to set up any signer software on their end. This seems pretty close to the ideal of abstracting away keys for new users without compromising security too much. If we get key rotation, simplier coordination, and/or encryption using frostr, that's an improvement over promenade. But third-party shard custodians have to be plugged into the nostr social layer via NIP 89 so that we can avoid collusion of dishonest signers.

Hey, would either of you guys like to come on @Thank God For Nostr Podcast and talk about frostr?

You don't want to send requests to off-line or intermittent peers, so the "send" list let's you to select which peers you expect to handle your requests. The "receive" list is less important to manage, but you may want to be restrict your node's participation with high-risk nodes, in case they get compromised.