[Proposal] Native MultiSign Component for Xaman App
Opened this issue · 4 comments
Proposal: Native MultiSign Component for Xaman App
Issue Summary
The current process for MultiSign transactions in the Xaman app presents several challenges. MultiSign users are required to compose transactions and propose them in an xApp, which limits their ability to utilize specialized interfaces like unhosted.exchange. This proposal seeks to address this issue by implementing a native MultiSign screen within the Xaman app.
Problem Description
In the existing workflow, MultiSign users encounter limitations when attempting to perform transactions. They must compose transactions and submit proposals within an xApp, lacking a dedicated interface tailored to their needs. This lack of functionality hinders the user experience and makes it difficult to leverage external services such as unhosted.exchange. To enhance user convenience and efficiency, we propose the integration of a native MultiSign screen within the Xaman app.
Proposal Details
Our proposed solution involves the development of a dedicated native MultiSign screen that streamlines the transaction process for MultiSign users. Here's a breakdown of the key elements:
-
Automatic Recognition of MultiSign Accounts: When a user attempts to sign a transaction, the Xaman app will automatically detect if the associated account requires MultiSign approval. If the account has a MultiSign list and the user has imported the necessary signers into Xaman, the MultiSign screen will be triggered.
-
User-Friendly Interface: The MultiSign screen will provide an intuitive and user-friendly interface for MultiSign transactions. Users will be presented with a page or interface optimized for MultiSign, making it easier to review and approve transactions. This can be done trough an xApp or natively. At this stage it seems like a specialized xApp would work best.
-
Seamless Integration: External developers will benefit from this native MultiSign component as they won't need to implement specific checks for MultiSign or redirect users to a separate MultiSign xApp. This integration will save both time and effort in the development process.
-
Hash Verification: The proposed MultiSign screen will handle the necessary verification steps. It will combine the required signatures and check whether the combined signer weight meets or exceeds the Quorum. If the conditions are met, users will have the option to sign and submit the transaction.
Implementation Options
The implementation of this native MultiSign component can be achieved through the following methods:
-
Xumm API Integration: We can send the combined transaction hash to the Xumm API for verification and approval.
-
MultiSign Backend: Also the existing MultiSign Backend can be utilized to perform the necessary checks and validations in combination with an xApp.
Benefits
- Enhanced User Experience: MultiSign users will enjoy a smoother and more efficient transaction process within the Xaman app.
- Developer Efficiency: External developers will save time and effort by not having to implement MultiSign checks or build separate MultiSign xApps.
- Streamlined Transactions: The native MultiSign component will simplify the signing and submission of MultiSign transactions.
Conclusion
The introduction of a native MultiSign component in the Xaman app is a crucial step towards improving the user experience for MultiSign transactions. This feature will provide users with a dedicated interface, simplify the transaction process, and benefit external developers by reducing development complexity. We recommend moving forward with this proposal to enhance the functionality of the Xaman app and better serve our MultiSign users.
Great summary @KoenPaas. Visuals needs to be updated tho. I'll wait with that until you have a raw-technical version.
@KoenPaas @DJ-xrpl @thisistriss
What I'm missing is the user stories of the different things to cover / not to cover.
E.g.:
- User comes from multi sign xApp, [...] and [...]
- User wants to manually send with multi sign enabled, does [...] and then goes to [...]
- User comes from sign request (payload) from our own Multi Sign xApp and multi sign is required, [...]
- User comes from sign request (payload) from a third party like
unhosted.exchangeorxrpl.servicesand multi sign is required, [...]
The screenshot attached shows a regular "Send" flow, but the described example like unhosted.exchange would use Sign Requests, which would have a completely different screen.
I think it's required to go through the possible flows & come up with a solution catering all or distinct between the diffent flows & requirements. The user stories I just mentioned would be a good start.
Note regarding sending already multi-signed "combined" blobs to our backend
Multi Signatures are not to be 'stacked' in different already signed multi signed transactions. Every signer must be the only signer on a multi sign blob, then to be combined all the way in the end. This is to prevent having to combine multiple sequences of signers into one final transactions that exceeds the amount of required signers.
So the backend should always be used in multi signer mode and get just one signature, and result just one multi signed tx blob.
Combining
Something to give extra attention to: if we help users generate a multi signed blob: where do they go to, to be combined later? This process is async. This is where the multli sign xApp comes in: the distribution of multi sign requests & the tracking of multi sign status.
I think for this reason, we must:
- Always redirect Multi Sign signatures from the manual send flow to the Multi Sign xApp, where further distribution & tracking can take place - to discuss: is that final screen the multi sign xApp or a native screen with an "Open" button to the multi sign xApp & Copy button to copy the invite link to co-sign in the multi sign xApp?
- Assume that sign requests from another app (other than our own multi sign xApp) are handled by the dev of that app
Check with devs
Special attention to e.g. users using third party tools (like our own unhosted.exchange or xrpl.services):
- They may not be multi sign aware
- They may want the single multi signed signature and do their own logic (how it would work today)
- They may want to receive the end result of an entire mutli sign sequence, where we completely offload the multi sign process for them
^^ How would devs deal with this / opt in for certain behaviour?
^^ How would this show to users?
TLDR
- This is great to work on & have!
- This needs more thought
- We probably need to scope this
@WietseWind @KoenPaas @N3TC4T How about a session @hq next monday to do a brainstorm on all the usecases?
@WietseWind @KoenPaas @N3TC4T How about a session @hq next monday to do a brainstorm on all the usecases?
Invite sent.