Title: Dapplets__Rethinking_Dapp_Architecture_for_better_
Category: Web

Author: Ethernian
Date: 2019-03-02T18:09:47.657Z

Last Update from 25.03.2019:
full medium article is here:
Dapplets (part 1): introduce new  Dapp architecture for better UX and security
Any comments and critic are welcome!
TG: “Dapplets and Secure Signing”
============
Hello all!
1. Look at current dapp ux critically:
image1253×1108 225 KB
We will see multiple drawbacks:


Wallet is unable to present all the information required for signer to make a solid accept/reject decision. The WYSIWYS principle (WhatYouSee-is-WhatYouSign) is broken now.


We are unable to reach web2 (legacy) sites because they do not implement any web3 logic. This is one of reasons why we are trying to reinvent wheels like twitter and facebook from scratch.


The root cause is in the Dapp architecture we have adopted from very beginning. We inject web3 for transaction processing into the website (Dapp) which is inherently unsafe environment with very limited chances for audit. That is why we use now wallets for Tx verification, running in more secure environment than Dapps.
Dapp Architecture based on web3 injection doesn’t support wallets properly. Lets try re-invent it.
2. Let us imagine better UX.
image1246×1087 253 KB
Our gains:

We can let Wallet present exact we would like to sign. Make WYSIWYS great again 
Because we handle Tx processing in Wallet and not in the Dapp, we can reach legacy sites like twitter now. Not all, but many of them: we need create a control injector for that.
image1370×1015 226 KB

3. How it could work?
We need let wallets load and render small Dapps (let us call it Dapplets) depending on current context and action. A Dapplet containter will make necessary security checks and audit status. More over it will present more info about Tx and Dapplet in the Header and Footer for better security.
image1680×1284 422 KB
We will probably reuse some extended version of WalletConnect
image2014×1522 510 KB
Disclaimer:
There are security challenges here, but I believe they can be solved.
Current state:
PoC based on Metamask is mostly implemented. Architecture and Security is still a hot topic.
Summary:
A lot of thanks to @ligi and @pedrouid for review and critic.
Special thanks to @danfinlay and Metamask Team for great product and their openness.
If you have any critic, please let me know. I love fail-fast.
We will come to Paris for Council, Hackathon and EthCC.
let us talk in details.

Author: hellwolf
Date: 2019-03-03T13:59:37.832Z

The need for auditing makes a new type of hudle of adoption. I am curious what do you think of adding a restricted presentation layer (that it doesn’t allow mangling the original data visually) to https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md instead?

Author: weijiekoh
Date: 2019-03-03T15:16:44.206Z

Throwing my hat in the ring here: https://github.com/weijiekoh/eip-typed-data-translation/blob/master/EIPS/eip-typed-data-translation.md
It’s an idea for a standard way to convert EIP712 typed data into natural language.

Author: Spaded
Date: 2019-03-03T15:22:59.653Z

I’m all in favor for this idea.
Just off the top of my head… can we make it as easy as:
1.Dapp sends a call to Web3.dapplet({myDappletObj})
var myDappletObj = {
    name: "MyDapp", //name of your dapp
    url: "urlOfYourDapp", //url for your domain here for general registery
    category: ERC20, //type of asset for display purposes
    message: { //your dapp object to be displayed
    asset_name: "My CryptoKitty", //optional
    asset_image: "image.com", //optional
    traits: [...]  //optional
    message: "Hello bob"  //optional for any other types
    ...///any other fields for the category types supported 
    },
    trasactionObj: {...txData} //pass in normal transaction data
}

Where myDappletObj contains information similar to what a transaction contains, except it has extra data feeding it the object of the dapplet. Given the use of ERCs, we can accept ERCs transfers, general info such as names, images, ERC-721 assets, or DAO type interactions. Where every interaction is generalized and you are feeding a standard 1 of X number of possible type of widgets into the wallet.

Wallet then displays what was given in a limited form, just as it does with a transaction now.
User sees the proper info and accepts.

I’d love to see this happen.

Author: Ethernian
Date: 2019-03-03T16:48:50.000Z

Guys,
sorry for delayed response.
I am busy preparing myself for Ethereum Magicians Council tomorrow - will answer in few hours.

Author: danfinlay
Date: 2019-03-03T16:54:54.283Z

I very much like the concept, and am mostly concerned with the security of the implementation, and am interested to see the code.

Author: tbarker
Date: 2019-03-03T17:50:04.911Z

I’d see it as a more visual version of natspec notices [https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format].
I think the important thing is that it be determinable what DApplet code was running at any given block. Perhaps the default is that DApplets are immutable and deployed at the same time as the contract itself?

Author: androolloyd
Date: 2019-03-03T19:48:15.655Z

This is great, I have been working on a concept called “Smart Widgets” which sound a lot like dApplets, but they are react-native components.
The concept is similar in that expression actions should be brought to the wallet for rendering and signing and then relayed back to the network.
The end goal of giving developers access to a sandboxed environment where there is an exposed web3 object for them to interact with.
Will be following intently.

Author: Ethernian
Date: 2019-03-04T00:00:20.807Z

hellwolf:

The need for auditing makes a new type of hudle of adoption.


I have slightly another angle of view:
While contract audit became usual and desired, the dapp audit is still not in focus. This is because of inherent trade-off between UX and Security. Most projects currently follow User expectations and prefer UX at expenses of Security.
I proposed to extract security sensitive parts of Dapps into Dapplets which are much smaller, utilize simple UI and can be executed in restricted environment. That makes Dapplet audit even possible.
Dapplet audit could become part of contract audit and will not create additional obstacle for adoption.
If some project doesn’t not provide an audit, it could implement all UI as usual in a solid Dapp and without any Dapplets.

Author: Ethernian
Date: 2019-03-04T00:09:43.886Z

hellwolf:

I am curious what do you think of adding a restricted presentation layer (that it doesn’t allow mangling the original data visually) to


Yes, it could be thought as presentation layer to EIP-712 although not instead, but as an additional layer.
I confirm, I need to think deeper about EIP-712, but currently I think, the EIP targets another problem: it creates unambiguously (injective) signatures, which can not be later interpreted as valid in another semantic context.

Author: Ethernian
Date: 2019-03-04T00:45:41.867Z

weijiekoh:

It’s an idea for a standard way to convert EIP712 typed data into natural language.


Yeah, It is a valuable input, thank you!
I have similar template based way of thinking about visual layer, but I would more strictly separate calculations from data. I would be interested in detailed discussion.



 Spaded:

Web3.dapplet({myDappletObj})
…
trasactionObj: {…txData} //pass in normal transaction data


I would completely replace the txData with json object. It makes no sense to construct txData in less trusted environment like Dapp in browser and then try to recover corresponding meta-data from passed txData in Wallet. This architecture was introduces years ago because of convenience and simplicity but it doesn’t fit security requirements and should be deprecated, IMHO.
It should be the Wallet, who should be responsible to construct txData based on parameters passed or loaded from other trusted sources.



 tbarker:

… and deployed at the same time as the contract itself?


I don’t think it is necessary, but same-origin is a good security note.

Author: tbarker
Date: 2019-03-04T08:01:01.518Z

I was imagining the DApplet being represented as a hash and loaded from IPFS. Wallet is directed to a certain smart contract, queries the contract to find the hash of the canonical DApplet, and then loads it.

Author: Spaded
Date: 2019-03-04T09:23:57.925Z

Yes ofc the data can be pulled wallet side. Was just giving an example that we would include the bare minimum that is included now, plus the extra additional data.
My concern for requiring these dapplets to be hosted or related to the smart contract, is that, once a dapp is deployed, a new dapple may be wanted to be used.
Also dapplets for 721 assets and other non traditional assets most likely need information from off chain to be included within the information passed to the dapplet

Author: Ethernian
Date: 2019-03-04T16:26:50.620Z

tbarker:

queries the contract to find the hash of the canonical DApplet, and then loads it.


Yes, but quering the smart contract is not the only one way to get a trusted dapplet. The trust for 3rd party dapplet can be established by audit, for example.
I would like to see Dapplet audit as the part of the usual contract audit.

Author: jeluard
Date: 2019-03-06T09:58:12.416Z

Very interesting idea!
Sounds like the gist of the idea is the website logic injection. Having wallet screens sounds orthogonal and might be useful in general, but also kind of complex to spec so that all wallet implementer can agree on.
Maybe worth separating both parts?

Author: jeluard
Date: 2019-03-06T09:58:48.285Z

@androolloyd I’d enjoy to know more! Anything you can share?

Author: Ethernian
Date: 2019-03-06T10:29:34.616Z

jeluard:

Maybe worth separating both parts?


Yes, you are completely right. Injection and Dapplets are quite independent parts.

Author: Ethernian
Date: 2019-03-06T10:34:16.503Z

androolloyd:

This is great, I have been working on a concept called “Smart Widgets” which sound a lot like dApplets, but they are react-native components.


Yeah, in PoC implementation we are going the same direction using JSX-like compoments.
Are you in Paris now? Would like to talk about more in details. May be we could join our efforts.

Author: jeluard
Date: 2019-03-06T10:44:25.772Z

I am in Paris. Any availability this afternoon? I am @jeluard on telegram.
Also this thread sparkled a semi-related idea here: https://discuss.status.im/t/extensions-to-enhance-old-web/1085

Author: androolloyd
Date: 2019-03-06T12:24:50.442Z

Sadly not in Paris. Let’s grab a video call next week.

Author: hellwolf
Date: 2019-03-06T13:33:34.382Z

Going to be in Ethparis, our team is considering different projects and one of the idea is similar to this. I would love to meet you there Ethernian. telegram @miaozc

Author: Spaded
Date: 2019-03-06T16:13:27.282Z

I’d like to get in on a call about this as well. Can we set something up for all of us?

Author: hiddentao
Date: 2019-03-06T19:08:47.247Z

I’d like to join in too. A few colleagues and myself were thinking last week about being able to generate Dapp UIs (similar to Dapplets) based on specifications. A specification would indicate what input fields are needed, and what to do with the input values - i.e. what contract functions to call and in what order.
From a given specification, different wallet and dapp browser makers would be able to generate a UI according to their design ideas, but the functionality (i.e .what the UI lets the user do) will be the same in terms of interacting with the blockchain.
The idea mainly revolves around making it easier to access smart contracts without having to build a full blown dapp.

Author: patrykadas
Date: 2019-03-08T01:16:48.564Z

Hello!
I really like that idea, I was exploring a similar approach with the product I’m currently working on:
http://ontop.team/dappi
It’s providing an easy to use web GUI for smart contracts that could be used as a standalone website or an embedded widget.
Here’s the design file:
https://www.figma.com/file/P6G4CuHmVGKZVdR9JQ5GStx9/Dappi-product?node-id=0%3A1
I have talked about this during Web3 Design Call.
I’d be happy to collaborate on this one and/or share insights and ideas.

Author: Ethernian
Date: 2019-03-08T17:48:59.733Z

We are in WTHParis. If you are here let us talk and buidl.
CC @patrykadas

Author: hiddentao
Date: 2019-03-10T12:22:41.181Z

Sadly no there this week. Perhaps we can do a call sometime?

Author: Ethernian
Date: 2019-03-12T08:34:37.165Z

moved the discussion into the Wallet Ring as the most appropriate, IMHO

Author: Arachnid
Date: 2019-03-12T19:54:17.013Z

I’m glad someone’s working on this! Micah and I started (but ultimately put on the back burner) similar efforts with trustless signing.
If you structure this correctly, there’s no reason that the ‘dapplets’ need to be trusted or audited. It helps to analyse the threat models for transaction signing:

An attacker attempts to get you to send a transaction to a non-malicious smart contract, while lying to you about what it does. Eg, Alice tries to get you to send her all your cryptokitties.
An attacker attempts to get you to send a transaction to a malicious smart contract they control.

Attacks using the latter are very limited; the only one that I’m aware of is convincing you to send your Ether to a contract the attacker controls.
Meanwhile, in the former case, the contract the transaction is being sent to can be trusted to correctly identify/explain its own transactions.
As a result, a model along these lines should work:

Transactions can be explained using some kind of DSL. Inputs are the ‘dapplet’ for the contract, and a dictionary of data whose contents is determined by the dapplet. Outputs are a human-readable explanation of the transaction, and an encoded transaction object.
Each supporting contract has a isValidDapplet(bytes32) method, which takes the hash of the dapplet and returns true iff it’s an accurate description of the functionality of the dapp.
Contract identities are verified - eg, using ENS - so people are aware of what contract the transaction is asking them to interact with.

Author: Ethernian
Date: 2019-03-13T12:56:25.608Z

Arachnid:

If you structure this correctly, there’s no reason that the ‘dapplets’ need to be trusted or audited.


I think we should better talk about trust chains than about trusted/untrusted. Audit is essentially only the point where the trust chain starts.
In particular the EIP-719 trustless signing is not completely trustless. It has the same trust origin as the contract and because of that it should be audited as the part of the contract.
Dapplets can root their chain of trust in the contract like EIP-719 does, but there are other ways to establish it, like an external audit made later by independent trusted party.
For more detailed answer I need few days more to understand objections and concerns to EIP-719. I’ll write later.

Author: Arachnid
Date: 2019-03-14T03:19:06.344Z

Ethernian:

I think we should better talk about trust chains than about trusted/untrusted. Audit is essentially only the point where the trust chain starts.


However you want to phrase it, my point is that you don’t need to audit a ‘dapplet’ for accuracy independent of the contract, as long as the contract vouches for it.

Author: Ethernian
Date: 2019-03-14T03:23:33.730Z

Arachnid:

you don’t need to audit a ‘dapplet’ for accuracy independent of the contract, as long as the contract vouches for it.


now fully agree.
Nevertheless the contract is not only the one (and should not be!) who can vouche for dapplet.

Author: Ethernian
Date: 2019-03-22T11:13:49.962Z

Guys,
I have wrote a medium article (currently in draft):
I would really appreciate your opinion and critic before publishing.
Dapplets (part 1): introduce new  Dapp architecture for better UX and security
Thank you!
A Tg group is here as well: “Dapplets and Secure Signing"

Author: jpitts
Date: 2019-03-22T18:19:48.820Z

RE: the Dapplets Medium article Part 1.
Love the use of CRAZY.
image516×236 23 KB

This is a great intro, especially the summary, it really gets it across. The one thing I feel it needs is more about implementation, e.g. what does a dapp developer need to do? What does wallet developer need to do? How do these parties come to an understanding? I suppose this is for Part 2.
Still, might be good to briefly describe the basics.

Letting my mind wander a bit, this seems like a sort of UI EVM, and really only for the exact point of decision by the user.
The relevant information needs to be presented to the user, which includes an image. The action needs to be presented, in a way which is clear to the user. Certain dialogs also need to be incorporated, to represent the changing state or implications, or reflecting the status code  (pinging @expede here).
These are not currently concerns at the contract level, and implemented in a hundred different ways and often terribly by dapp devs.
A standard can be created to enable this to happen at the contract level, a data structure which guides the UI of the action and immediate steps afterwards.
Then Metamask, wallets, mobile, and so on can render the result in a standard way, using WASM even to ensure consistency. I hope I am not repeating what y’all already know LOL.

Author: Ethernian
Date: 2019-03-23T11:00:12.711Z

jpitts:

The one thing I feel it needs is more about implementation, e.g. what does a dapp developer need to do?


Hello, Jamie!
I have improved the article accordingly.



 jpitts:

Letting my mind wander a bit, this seems like a sort of UI EVM ,


I am unsure what do you mean by UI EVM? Is it the EVM or just some VM for the UI calculations?
My thoughts in that directions are DSL-centric. It seems to me we should define a DSL firstly and only then think about the VM executing the DSL.



 jpitts:

A standard can be created to enable this to happen at the contract level, a data structure which guides the UI of the action and immediate steps afterwards.


This is my way too, definitely.
Anyway I would start with MVP for now. It will facilitate a broader discussion what the standard should look like.

Author: jpitts
Date: 2019-03-23T15:35:05.715Z

Ethernian:

I am unsure what do you mean by UI EVM ? Is it the EVM or just some VM for the UI calculations?


RE: The “UI EVM”, I mean this conceptually! The dapplet constrains the UI of the final approval/signing process in order to ensure secure and predictable interaction with the user, and separates the final approval/signing UI from the rest of the potentially insecure UI of the dapp.

Author: Ethernian
Date: 2019-03-25T15:55:16.792Z

I have published the medium article:
Dapplets (part 1): introduce new Dapp architecture for better UX and security

Author: Ethernian
Date: 2019-03-30T16:38:18.097Z

On another topic


I think you’re trying to make ‘dapplets’ responsible for too much. It’d be a lot easier to ensure they’re secure if they’re restricted to presenting and transforming transaction data for user display and submission.



Generally I am fine to implement the most restricted version first, but what is the advantage of the restriction?



On another topic


Making dapplets able to grab information from third-party services like thegraph seems likely to introduce hazards in terms of both trustlessness and security.



yes, you are completely right.
If the TheGraph/Fluence service provides no cryptographic proof for response (the situation right now) or can’t be trusted in some other way (like node ownership), dapplet should make a web3 call instead.



On another topic


I’m not sure why you anticipate dapps not querying web3 any longer. That seems like something pretty crucial, and it’s not clear to me how a dapp would display information if it can’t do that.



I am not against web3 calls generally. I have just proposed a way to work with existing legacy sites built without any web3 support in mind.
The second aspect: the web3  in its current state is damn inefficient for querying blockchain data. But if web3 will have efficient querying facility like TheGraph/Fluence, why not use it?
Another aspect is the trust: there is no sense to use web3 to create sensitive objects like transactions in such generally mistrusted environment like dapp and the browser.
May be it was a little bit exaggerated to say “don’t use web3 in dapps”.
More nuanced message could be: it is more efficient to replace web3 reads with TheGraph-like service and move web3-writes to the signer; may be you will not need the web3 dependency in your dapp at all.



On another topic


I think there’s too much focus on audit, which should be out of scope. If you make the trust domain for the contract the same as the one for the dapplet, the user can trust the transaction presentation if they trust the contract they’re interacting with. How they come to trust that contract is out of scope - audit is one possibility.



agree: audit is pluggable and out of scope of the architecture. Nevertheless the infrastructure should offer the way to check the audit status and the trust path, thats why I have mentioned it in the article.
“The same domain” policy is not only the way to create the trust: dapplets may be created by 3rd party and should not need any allowance from contract author to operate properly.



On another topic


The trustless signing proposal doesn’t try to reverse engineer data from the transaction as you suggest; it aims to accept transaction data in an app-specific format and present it for the user, as well as transforming it into transaction payload.



I have used words like “recover” or “guess the View” to describe what the Wallet/Signer generally should do in order to display the binary transaction correctly. May be the wording doesn’t fit exactly to EIP-719, but  essentially it doesn’t matter: it is not about how the Signer does it technically (“reverse engineeriring” or “querying the method registry”). It is about how secure, how informative and how flexible it is.
IMHO, an EIP-719 is quite secure, but could be more flexible (supporting other view verification sources than the contract)  and more informative (supporting images or additional context parameters).

Author: Arachnid
Date: 2019-03-30T19:24:07.745Z

Ethernian:

Generally I am fine to implement the most restricted version first, but what is the advantage of the restriction?


It’s easier for clients to implement, and it’s more secure.



 Ethernian:

agree: audit is pluggable and out of scope of the architecture. Nevertheless the infrastructure should offer the way to check the audit status and the trust path, thats why I have mentioned it in the article.


I really think this is orthogonal to what you are trying to achieve.



 Ethernian:

I have used words like “recover” or “guess the View” to describe what the Wallet/Signer generally should do in order to display the binary transaction correctly. May be the wording doesn’t fit exactly to EIP-719, but essentially it doesn’t matter: it is not about how the Signer does it technically (“reverse engineeriring” or “querying the method registry”). It is about how secure, how informative and how flexible it is.


My point is that 719, iirc, doesn’t do either of these things; it uses the same kind of interface you’re proposing for dapplets, where the data format passed to them is application specific.

Author: Ethernian
Date: 2019-04-01T14:42:11.544Z

Arachnid:


agree: audit is pluggable and out of the scope of the architecture. Nevertheless, the infrastructure should offer the way to check the audit status and the trust path, that’s why I have mentioned it in the article.

I really think this is orthogonal to what you are trying to achieve.


Yes, it is. But why are you mentioning this?
Is there more than “It does not belong to the standard itself, but important for standard adoption”?



 Arachnid:

My point is that 719, iirc, doesn’t do either of these things; it uses the same kind of interface you’re proposing for dapplets, where the data format passed to them is application specific.


I’ve got an idea of Dapplets independently from EIP719 and become aware of it later from people’s feedback. I see similarities and consider the EIP719 as one of simple ways to implement an initial version of Dapplets. Nevertheless the scope is Dapplets is broader, so I see EIP719 as a possible part of it, not as replacement.
Disclaimer: I have to read and think about EIP719 deeper in details. My understanding of it is still not complete.

Author: Arachnid
Date: 2019-04-01T20:25:00.492Z

Ethernian:

Yes, it is. But why are you mentioning this?
Is there more than “It does not belong to the standard itself, but important for standard adoption”?


Smaller standards are generally better, and more likely to get reviewed and implemented. And separation of concerns is good too.

Author: Ethernian
Date: 2019-04-02T09:53:57.191Z

Arachnid:

Smaller standards are generally better, and more likely to get reviewed and implemented.


My belief is different: adoption of the standard is not a function of its size, but of the strength of incentives to implement relative to efforts needed. Enabling legacy sites, Dapplets creates sufficient incentive for adoption, I believe.



 Arachnid:

And separation of concerns is good too.


It may be a valid point. What concerns do you see unreasonably mixed now?

Author: Arachnid
Date: 2019-04-02T20:10:00.333Z

Ethernian:

My belief is different: adoption of the standard is not a function of its size, but of the strength of incentives to implement relative to efforts needed. Enabling legacy sites, Dapplets creates sufficient incentive for adoption, I believe.


Larger standards increase the effort required to implement, too.



 Ethernian:

It may be a valid point. What concerns do you see unreasonably mixed now?


Anything explicitly concerned with audit.

Author: RSivakov
Date: 2020-09-11T20:13:12.956Z

Очень интересная тема. Когда-то мы с напарником тоже экспериментировали на эту тему (только дальше эти действия подписывались пин-кодом на банкомате, т.е. не метамаск, но, немного похожа логика =))]
Это очень старые первые наброски.

Author: Ethernian
Date: 2020-09-18T01:32:16.404Z

RSivakov:

(только дальше эти действия подписывались пин-кодом на банкомате, т.е. не метамаск, но, немного похожа логика =))]


How it is related to my staff? Unclear…