Users don’t care

Mainstream users don’t care about blockchain. Or about decentralization. Or about a trustless, verifiable ledger.

They do care about what they can do with your application and how it can help them to do whatever it is they want to do. If using a blockchain-based app means users can do things better or in a way that somehow benefits them — great, then they will use your app. But not because it uses blockchain. They just don’t care.

Users are lazy

The vast majority of mainstream users won’t install a third party plugin or application so that they can start using your app. They won’t make the extra effort to understand what a private key is, or wallet addresses. Or what it means to sign a transaction.

Users expect the same experience they already get with existing apps. It should simply work with minimal friction. “Pay for gas? Pffttt, I’m not paying any AWS fees anywhere else, so why should I pay for interacting with your DApp?”. You can waste time trying to explain the reasoning to your users, or you can offer them a familiar experience which they will happily embrace.

Onboarding needs to be simpler

When users create an account on a web app, all they provide is an email and a password. They don’t need to install anything, understand any scary technical terms and they definitely don’t have to buy anything.

With Portis, since we are a 100% JavaScript solution, we offer users an experience similar to that of a regular web app, but there is still room for improvement.

The first problem is gas fees, required for the first meaningful interaction with any DApp. To get around that, Portis used to give new users $1 worth of Ether. But we asked for their phone number so we could prevent people from abusing our giveaway, and not all users feel comfortable providing that information. Also, that $1 will eventually run out.

Our developers are investigating the best way to implement “meta transactions” or “proxy contracts”, which will allow users to sign transactions without paying any gas fees, passing along that responsibility to someone else, either Portis, the DApp or an incentivized network of relayers. The developer community is full of interesting approaches, and we’re keeping our ear close to the ground. There are lots of factors to consider:

If the user doesn’t own the proxy contract, that means the target contract will need to change its code (as it will need to use some type of “signer” parameter instead of msg.sender). Can we really ask DApps to do that?

Giving the user ownership over their proxy contract is optimal (and plays great with giving them an identity contract, for greater key management capabilities), but how do we handle the cost of deploying a new contract for each new user? Can we perhaps deploy these contracts in advance, when the network is less congested, and gas fees are low? Who will pay for that?

How do you prevent abuse of the gas sponsors? Should DApps give out tokens to new users (i.e. gas allowances)? What happens when users run out of tokens? What about plain old Sybil attacks?

There are plenty of other questions of this nature. DevCon is right around the corner, and we know there will be fascinating discussions around this topic, especially by the MetaCartel bunch. They recently released a remarkable proof of concept at ETHSanFrancisco. We love their approach, both from a technical perspective and from their transparent and community-driven style, and are truly inspired by it.

We’ve been toying around with the concept of “proxy contracts” since the day Portis was born. We always knew the $1 giveaway was one of those workarounds that works great because it’s simple but won’t scale in the long run. We’re super excited to see that “proxy contracts” will soon become a reality.

Stop bothering your users

Imagine using an application and getting an annoying “Are you sure? Yes / No” pop up every time you carry out an action. That’s terrible UX, right?

What’s next, web3-clippy?

Well, right now, that’s the experience users get with any DApp. Let’s say they went through the trouble of signing up (which possibly also means installing a third party app) and let’s say they are even fortunate to be using a DApp which is willing to sponsor their gas fees. Yet every time they do something, they get a pop up asking them to once again confirm what they already approved when they clicked on “sign”, “vote” or “trade” in your DApp.

Sure, it’s possible that a DApp is malicious and that a user will want to make sure they’re signing what they think it is they are signing. But come on, between us, how many of you actually examine tx data and decode it to verify its contents? That’s what I thought.

We got a lot of feedback from DApp developers that this is a big issue for them. Not only is it annoying their users, but it is also quite intimidating. Not all DApps are mission critical, but we’re still asking users to confirm every little action, making it appear like they are, which drives away casual mainstream users.

To tackle this problem, Portis is releasing a “trust this DApp” feature. Users will be able to allow the DApp they are using to sign transactions for them automatically. There will be safeguards in place: it will only apply to non-payable methods and only up to a certain amount of gas per hour. Frankly, we’re less concerned about malicious DApps, but more about DApps that accidentally left a while loop in place that will clean the user’s wallet dry. We’re just making sure that nobody is asleep with their foot on the gas (buh-dum-tss).

Yes, methods can have substantial side effects even if they don’t have a payable component (for example, signing a vote that will result in the transfer of significant funds). But that doesn’t mean we need to adopt an “all or nothing” approach. We will work with DApps powered by Portis to map out such “risky” methods to make sure our users will always be aware of what’s happening while keeping their UX smooth and friendly.