Cajga
Theoretical example: the transaction source account is naming hydra as transaction coordinator. But one of the accounts who has to sign the multi party transaction wants to use a second key to sign and this signature is coordinated by 3rd party service coordinator (like stellarguard) so there should be a point when hydra should hand over the transaction to the 3rd party coordinator which coordinates the signing
This could happen as well with one source account using 2FA and one transaction coordinator, so this is not tied to that specific proposal.
StellarGuard is not a signature coordinator: it is a two-factor authentication service. In this context, it is basically a co-signer and should behave as such. There's also the fact that two-factor authentification should happens when source is signing, not at a later time. Then the signatures should be sent to the coordinator, either by the signer wallet or by Stellar Guard itself. There's no reason for Hydra to pass signatures to StellarGuard.
More generally, for a transaction with multiple sources that have multiple signers, every signer would send transaction to the transaction source coordinator. This is a neat way to harmonize things over wallets, as we neutralize their power to impose their own coordinator.
This is the key point here. For me the multi-sig coordination is much more a low-level protocol than something which should have multiple external implementations. The best would have been to have it fully built-in in the core but having a decentralized off-chain solution is pretty close to that.
Well I think I agreed with that, as it was also the conclusion last time we did discuss the subject.
However, practically it ends up to be an external service which means that various wallets now use different solution, and none of those solution actually got the authority and credibility to impose itself as the only one.
Now the only way I can imagine to put things back together is to having a well-defined abstraction to achieve inter-operability.
So my point is that we should start from were we are, not from were we should have been. And that implies a bit of cooperation...
I'd like to expose my situation to bring some light on the core issue being discussed here.
I wrote a genetic signature sharing mechanism that works fine. You couldn't make anything closest to a native implementation, so I think it is very good. As a user, it's exactly what I want.
Now, as a wallet developper I know that supporting only my solution would lead to further fragmentation in the ecosystem and I'd like to avoid that. That's why I'm looking for a way to abstract signatures sharing so I can support multiple solution at once and achieve inter-wallet compatibility.
While I think Hydra is a good project on the paper, an answer such as "It is superior, throw your stuff away." is not going to work for me. Actually if we go this way I do think on-chain signature collection is better: that's why I did it. And probably someone else think this or that is better.
So we end up facing the same issue again: either each one try to dominate the scene believing it will achieve a monopoly, either we make an effort to cooperate and make it work across our tools.
It remember me about web browsers history, purposely differentiating themselves and preventing harmonization in an attempt to achieve domination. That's this kind of spirit that leads to fragmentation, not the fact that several solutions exist.
Then the most selfish failed while the most cooperative ones united around common practice and took their market shares ?
