Join and earn Bitcoin Cash for participation

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

31 301
Avatar for p0oker
Written by   21
1 month ago

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.

Fig 1. Sequence of communications for authorizing an action in a web browser


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:

Fig 2. Sequence of communications for authorizing an action using a mobile wallet

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!

Sponsors of p0oker
empty
empty
empty

21
$ 2.29
$ 1.00 from @jan
$ 0.53 from @Telesfor
$ 0.50 from @DrNums
+ 4
Avatar for p0oker
Written by   21
1 month ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

If the goal is to develop the most secure and reliable infrastructure for building decentralized apps across the whole crypto community. It 's the best of the best idea

$ 0.00
3 weeks ago

Please develop more Dapps games to Play and Earn Bitcoin Cash i really thank you for this post liked and subscribed

$ 0.01
4 weeks ago

[Removed comment]

$ 0.00
4 weeks ago

I have a suggestion concerning this your platform, founder and co-workers. In other to draw attentions of many people to your site, could you please put it this way; register today and receive 0.00000009 btc.

$ 0.00
4 weeks ago

Well done Mr pooker

$ 0.00
1 month ago

If the goal is to develop the most secure and reliable infrastructure for building decentralized apps across the whole crypto community. It 's a very nice Idea

$ 0.05
1 month ago

Absolutely.

$ 0.00
1 month ago

Looks like it'd be a much nicer UX, I'd just be worried about storing the private key in localStorage.

$ 0.01
1 month ago

In this new architecture for web it's either stored in IndexedDB or your mobile app storage. But may I know why storing in localStorage is worrisome to you?

$ 0.00
1 month ago

Encryption solves part of the issue. The decryption key needs to be entered only on signup.cash domains and the user needs to be trained to check the URL before entering a password. The reason I'm a bit hesitant is because this is designed to be used across multiple sites by 3rd party devs, meaning that the user interaction context is outside of your domain.

$ 0.00
1 month ago

Signup is passwordless login and the keys are made only in the Signup domain. But I'm not sure what attack scenario are you trying to cover with encrypting it with a password?

$ 0.00
1 month ago

Perhaps he fears that it is stored unencrypted and can be read by a malicious application?

$ 0.00
1 month ago

That's why it's moved to an isolated domain, so app developers cannot technically access it (it will compromise the whole web development security model)

Signup on the other hand can access it technically, but the code is kept on high velocity serverless cloud platforms and the source code is open source to be reviewed by everyone. I think risk is negligible compared to the value offered.

$ 0.00
1 month ago

When it comes to money, trust is the most important thing. Most people have neither sufficient technical knowledge nor interest in learning the technical details. Either they trust a currency or they do not trust it. Either they trust a wallet, an app (or whatever) or they don't.

$ 0.00
1 month ago

I definitely agree. Hopefully in order to use Signup micro transactions suffice. Takes time to build trust.

$ 0.00
1 month ago

It could be useful for microtransactions. You don't have to keep a lot of money on the wallet. Trust grows with time. You might need logout, or optional 2FA for the security conscious

$ 0.01
1 month ago

I agree logout and withdraw is very important. Will surely consider all on the roadmap.

$ 0.00
1 month ago

some good schematics in your post and well thought out app solution to the technical problem at hand. Some engineering smarts for sure.

$ 0.01
1 month ago

Thanks, yes it took me a while to come up with this. Examined many failed solutions, no one really implemented something like this without compromising the ownership values.

$ 0.00
1 month ago

I just tried your login demo and 600 sats tip. It worked fine with Chrome on Android. It's a good idea if it will work across browsers (that's how I understood it). I used to use MoneyButton a bit before it switched to BSV. Your project is very similar to it. One problem I see is that the private keys are stored outside the browser on your server (this is also the case with MoneyButton). Therefore the users have to trust that the keys are not abused or stolen. For very small amounts it is not a problem, but I'm afraid that some users might refuse.

$ 0.00
1 month ago

Thanks for trying it out. Signup is fully non-custodial, while delivering the same values as custodial ones like MoneyButton. There is no database to store the private keys, your private keys are stored in your browser. You can visit https://secure.signup.cash to check your balance, that domain is where you private keys are stored.

$ 0.00
1 month ago

I get it now. Then how can I log in on a different device or browser?

$ 0.00
1 month ago

Right now it's not possible because I didn't add the import wallet during testing period (safety reason). Soon you can import it in any other device using your mnemonic or scan a QR code using Signup mobile app (in future)

$ 0.00
1 month ago

This with mnemonic is a good solution. MoneyButton works with login (email and password) and stores the priv keys centrally. This is much worse. As far as I can tell, the reverse proxy server must solve the problems with the cookies. Then it should work with all browsers and apps.

$ 0.01
1 month ago

Yes I'm also not a fan of custodial solutions. The reverse proxy auth server provides a safe channel for any kind of wallet to connect to the app and automatically sign the transactions up to the limits user specified. So not only better browser compatibility but also more convenient UX compared to current system.

$ 0.00
1 month ago

I don't understand - why do you need third-party cookies in the original iframe idea? What's stored in the cookie?

$ 0.00
1 month ago

It's a local storage but a block on third party cookies include all sort of storages. Users private keys are stored in the iframes localstorage and the iframe is processing transactions through postMessage from the web app.

$ 0.00
1 month ago

The signup.cash is a welcomed development. Once the challenge of multiple wallets on Dapps are overcome, the project is going to be awesome. Good job!

$ 0.05
1 month ago

Thanks, the important part would be having developers who actually use it to build their new products.

$ 0.00
1 month ago

Thanks for upvoting my comment with some BCH. I appreciate it. I'll continue the good work.

$ 0.00
1 month ago