A sneak peek into SIGNUP's new DApp Architecture for Bitcoin Cash

As introduced in the previous post Signup is a non-custodial platform as service to build DApps for Bitcoin Cash. Our plan is to make it easy for developers to build DApps and make it secure and convenient for users to use these DApps.

In this article we go through a sneak peek of our new architecture design and look for an early feedback from the community as part of our commitment to a truly community driven open source project. This architecture is still a work in progress.

Challenge

The most challenging part of using DApps across the web and mobile is the problem with having multiple wallets across these web or mobile apps. Moving funds here and there is inconvenient and slow down the adoption for the users and the developers of these apps. Solutions that require users to install a browser extension (MetaMask, Badger etc) partially fix this problem but proved by Ethereum community that they are not a good proposition for mass adoption. In the other hand, web based solutions that empower users to use DApps with one unified account from the comfort of their own browser is booming. Last month Shapeshift acquired Portis which is the web-based decentralized app solution for Ethereuem and MoneyButton raised 1.7M in 2017 for providing similar functionality for BSV community.

Problem With Current Technologies

Even though the current solutions like Portis and MonyButton work in some situations they have problems that we also faced in Signup.cash. The current version of Signup is using some kind of communication between two different threads in the browser to separate the user private keys from the web apps. So a malicious web developer couldn't theoretically steal user's credentials if they intend to do so.

The architecture that is initially developed, uses a sand boxed iframe to communicate with the isolated domain which is secure.signup.cash. User's private keys are stored in the local storage of that domain and is secured by browser. Even though this method is working fine, the browser compatibility can never reaches to 100% considering that browser developers are blocking the third party cookies to avoid tracking. This policy is already started by Safari and Brave browser and is possibly gonna spread even further to Chrome mobile.

Also regarding the early version of Signup, many developers were unhappy about the UX of their users because of the explicit confirmation on every transaction. So I considered many other solutions to tackle this problem.

New Architecture

The proposed idea here is a draft and a request for comments to the community. The goal is to empower web and app developers to use the similar techniques they are using in the current industry. Any solution that is different with how things are done in web industry is considered a slow down to the adoption of developers and users.

We already know that app developers are used to common practices like HTTP protocol, JSON Web Tokens and app/session ids. The problem with using these techniques is that all of them are implemented in a custodial way. The whole tech industry is fully custodial, mutable databases sitting in cloud servers and protected by giants like Amazon and Google instead of Cryptography. They never cared about non-custodial solutions, but we do.

Here is a sneak peek of how we propose the communication for a DApp authorization and action flow. This flow contains a Web Worker, a reverse proxy authorization server and a web app. Reverse proxy authorization server is just a relay server that connects the web app with user's non-custodial wallet in a bi-directional SSE connection. That wallet could be a Web Worker in a browser or a Mobile App.

This diagram might be overwhelming but it could be simplified into these steps:

1. Users interact with the Web App for an action (e.g payment transaction)

2. Web app request for some permission to arbitrarily spend money from user's wallet up to a limit of price and time (maximum $1 in the next 60 minutes)

3. Wallet generate a self contained token (JWT) for that permission. Token is cryptographically signed and verifiable

4. Wallet passes the token to the app using the Signup server

5. The web app now uses the JWT for any kind of transaction up to the limit

The advantage of this architecture is that with minor changes we can use it for authorization using mobile wallets. Signup will also release a mobile app for users who want to keep the custody of their private keys outside their browsers. Other Bitcoin Cash wallets can also integrate the same protocol and enable their users to use DApps using their current wallet!

Here is how the same architecture would work for a mobile app as well:

The only difference in this sequence is that user should:

1. Open the wallet

2. Enter a number (sessionId) that they see on their wallet in the web app. (similar to 2FA)

3. Now they can see the requested permission inside their wallet app and they can confirm or reject it very similar to a hardware wallet.

4. Now the app can easily perform transactions up to the limits

API is the king

Singup's API is hands down the most simple API out there. All the complexity of the architecture is abstracted into these two lines to authorize and process a transaction:

 const user = await signup.cash.authorize({appId: 'YOUR APP ID'});
 // requesting your user to pay $1 to you
 await user.pay(1, 'USD');

Developers would love it!

Conclusion

The proposed solution is not used in any other similar applications and is a combination of latest best practices in web development and the non-custodial values of crypto community. This solution does not require users to trust any third party with their private keys and do not store user's private keys even in an encrypted way in a centralized server. Also it enables nearly 100% browser compatibility because the technologies used are the same methods and technologies used in most of the web applications in the wild. The user experience is also expected to improve a lot considering the removal of explicit consent screen per transaction.

This document is a draft of the architecture and is out here for feedback and comments. The goal is to develop the most secure and reliable infrastructure for building decentralized apps across the whole crypto community so don't be hesitant to criticize it as ruthlessly as you wish to!

Thanks for reading, don't forget to join our Telegram group for latest updates, visit the website or reach out to me in Twitter to say hi!