You can if you use FROST. You can be the dealer and send keys that need to sign to each server. 3-of-3 is possible, but you can also do arbitrary k-of-n.
Is it possible to take an nsec you already have and split it into 3 somehow, give one shard to each server and then they somehow collaborate to make a signature? I think you can't do MuSig2 for that, but maybe some other, simpler (less safe?) algorithm? I've asked nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7 this once but he never answered.
Discussion
Good to know, that prompted me to take a better look at FROST, which for some reason I initially thought was more constrained than MuSig2 in this regard and would never support this flow.
nostr:npub1zswjq57t99f444z6485xtn0vfyjjfu8vqpnyj6uckuyem2446evqnxgc6x made a Fedimint module for for signing notes.
Is that a fork of the full Fedimint repository?
It does appear that it is. I’m unsure what is actually needed. Maybe nostr:npub1zswjq57t99f444z6485xtn0vfyjjfu8vqpnyj6uckuyem2446evqnxgc6x can explain
Pretty sure I agree that FROST is closer to the mark in what @fiatjaf is looking for, but specifically the signing algorithm and not the keygen algorithm. FROST (and Pedersen DKG before it) were advancing the state of the art by allowing for no central party (or aggregator/dealer) to be in possession of the whole private key at any time, either in key generation, or in signing. Here I guess you want to reset back to the earlier SSS basic idea of having the central party know the key in advance, then construct the individual shares such that they sum to the pre-existing key x, instead of following FROST's KeyGen to generate the shares.
But the "massive caveats" I mentioned in the other post still apply; it seems unlikely you'd want to allow the possibility to collude to take your full key.
No, I don't want to reconstruct the key, I just want these providers to construct signatures, which apparently FROST can do safely -- I don't get why you can't do that with MuSig2 (wait, I guess it just doesn't work because MuSig2 has the "distributed key generation" step built in).
So I, as a user, don't have to do any cryptography or hold any keys during my daily life as a Nostr user, I can just instruct clients to fetch signatures from a server somewhere, and that server will coordinate with the 3 entities that hold my key shards to get a signature, then return the signature to the clients and, boom, I have a signed event.
Re : "No, I don't want to reconstruct the key", I don't really understand; I didn't use the word 'reconstruct' in that. "I just want these providers to construct sigs safely which apparently FROST can do". But the point that's at issue here is you want them to do that with *your* key. FROST and MuSig both allow multiple parties to collaborate to create signatures safely, with the main difference being that the former allows it for t of n and not only n of n. *Neither* provide for the key to come from some central party. As for distributed key gen, yes they both do it, they have to; but they do it in radically different mathematical ways (because of the t of n requirement for a start). And retrofitting them to allow you to start with a key "x" and then split it up and give it to them probably can work, but my caveat point is, if you care that they can collude to take the whole key, between them, then that's not great.** In FROST's case, it happens to be polynomial evaluations that you share, but it's still designed so that t of those shares (in a t of n scheme) are enough to reconstruct your signing key.
**In any such collaborative signing scheme, by definition, the key can be reconstructed by the authorised threshold t, because they can share their nonce contributions and extract the private key using the nonce. This isn't usually discussed, but here we have an external party that'd prefer not to be attacked by the group, so to speak.
Re "I didn't use the word 'reconstruct' in that".
Indeed, sorry, I misread.
For that you need 3 keys, op asked to do multisig from an existing single key.