I had trouble opening the 30617 event that you had quoted. O...

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l
hex
ed9651019105ab97880b2d6826ff2c17bc19265751a487c0da55e7ae8b6eef26nevent
nevent1qqswm9j3qxgst2uh3q9j66pxlukp00qeyet4rfy8crd9teaw3dhw7fsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gc4hcp2gKind-1 (TextNote)
↳ Reply to Event not found
570f10994b4e79de0bb58f21bd82287a75579c80b833fd973acb4ab2d69f2c38...
I had trouble opening the 30617 event that you had quoted. On imwald, I saw this, but clicking on that link just sent me to a broken page:

I was trying to understand what your frost scheme means in practice.
So the first observation was that, in your particular setup, your privkey is only as secure as your Google credentials, and Google needs to be trusted.
Otherwise, this scheme seems like an enhancement to NIP-46 if I'm understanding it correctly. If you yourself run one operator and require all shards for signing, it seems like it would be at least as good as current NIP-46. The operator you are running would be analogous to your NIP-46 signer app in that you have direct control over these, so that would presumably never be worse than current NIP-46 even if all the other operators are compromised.
If that's correct, your scheme composes with a key delegation system in the same way as NIP-46 does.
Raw JSON
{
"kind": 1,
"id": "ed9651019105ab97880b2d6826ff2c17bc19265751a487c0da55e7ae8b6eef26",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1788872812,
"tags": [
[
"imeta",
"url https://image.nostr.build/9007260b9f43440ccc506b8c74b2e88d9d7966624ec821843867aa9d5f455f92.jpg",
"ox 9007260b9f43440ccc506b8c74b2e88d9d7966624ec821843867aa9d5f455f92",
"x 88c7491469df09f6c962b77a3ccea9d0ce97862bc814b3d8376e7e09d2a770ce",
"m image/jpeg",
"dim 922x372",
"bh L8RyvpVt4n%g~W9GIURjM_xtt5Rj",
"blurhash L8RyvpVt4n%g~W9GIURjM_xtt5Rj",
"thumb https://image.nostr.build/thumb/9007260b9f43440ccc506b8c74b2e88d9d7966624ec821843867aa9d5f455f92.jpg"
],
[
"e",
"0bb4daf107c109410d85a15391dd4961e47fa97cfc7d35f83c1a1df0bb44d531",
"wss://nostr.mom/",
"root",
"50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63"
],
[
"e",
"570f10994b4e79de0bb58f21bd82287a75579c80b833fd973acb4ab2d69f2c38",
"wss://nostr.wine/",
"reply",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
]
],
"content": "I had trouble opening the 30617 event that you had quoted. On imwald, I saw this, but clicking on that link just sent me to a broken page:\n\nhttps://image.nostr.build/9007260b9f43440ccc506b8c74b2e88d9d7966624ec821843867aa9d5f455f92.jpg\n\nI was trying to understand what your frost scheme means in practice.\n\nSo the first observation was that, in your particular setup, your privkey is only as secure as your Google credentials, and Google needs to be trusted.\n\nOtherwise, this scheme seems like an enhancement to NIP-46 if I'm understanding it correctly. If you yourself run one operator and require all shards for signing, it seems like it would be at least as good as current NIP-46. The operator you are running would be analogous to your NIP-46 signer app in that you have direct control over these, so that would presumably never be worse than current NIP-46 even if all the other operators are compromised.\n\nIf that's correct, your scheme composes with a key delegation system in the same way as NIP-46 does.",
"sig": "da1b1058a40c91607d9c3d4563ea2ea0be047fa02f6d0c6697cee46d4416fcaa450ed9ac505348545f93dbe08c226c012848bcaf6762f4a124a05a37cbc408f1"
}