Opinion: the user interface should be part of the contract

[DavidBruant]

This issue is an outcome of a discussion i've had with @Chris-Hibbert and, in a way, a follow-up to my understanding of the design decisions around invites (#109 ) At this stage, it's only intended to be a discussion. If there is agreement of the opinion, another discussion is necessary to decide how it affects ERTP and other parts of the stack

I believe that the user interface should be part of the contract

The user interface mediates how physical persons interact with the contract. If the user interface is not provided by the contract, then, it does not have the same integrity properties as the rest of the contract and i believe it weakens the security properties of the overall system

To take a caricatural example, if i play chess, i play black and my UI contains only black pieces and my opponent's white pieces are invisible, i'm disadvantaged if my opponent has a UI which provides complete information. We are playing the same game, the same contract, but the user interfaces favors their side of the game There are many subtle variations of this example, but i think this example makes the problem clearly apparent The same way one may want to audit the code to be sure that the game mechanics are not biaised, one may want to be sure that the user interface honestly reflects the game mechanics

Aside from having security benefits, having the UI as part of the contract moves the responsibility of defining the interfaces to the contract author. And it's hard for me to think of how it could be differently. Contracts will propose an arbitrarily complex and rich set of models of interactions with the contract. I don't think there is a way to generically expose such complexity as user interfaces (if there was, we'd be done with software?). Agoric may provide components/patterns/"good pratices" at most, but to preserve arbitrary expressivity, the interface itself will certainly be constructed with the contract

If there is agreement on this idea, i can share ideas on how this could affect ERTP and other projects

[erights]

If there is agreement on this idea, i can share ideas on how this could affect ERTP and other projects

Hi @DavidBruant , please share! Thanks.

[DavidBruant]

Currently, the interface with the contract is an object recovered via redeem with a valid invite. I'll call this object the "CIO" for "Contract Interface Object"

The current examples only work if you can speak "message sending" with the CIO, but that's not an interface for humans who interact with computers via keyboard/mouse/screen/voice So, for the purpose of direct human interaction, the object recovered from redeem should provide a human interface. I think it can only come as a method of the CIO. And this function would return something humans can interact with. Starting with web browsers as an example, this function would return:

• an HTML string generated from the contract state
• (and maybe a URL taxonomy for other resources like images/scripts/styles, etc. ... or should everything be inlined?)
• (and maybe a URL taxonomy for the purpose of interacting with other object functions)

It's not clear to me whether the function name (html) should be determined as part of ERTP or whether it should be left free and let conventions emerge on their own. Maybe for some cases, it's also relevant to have several functions to produce an HTML string

The last parts about "URL taxonomy" assumes an HTTP interface which will probably need to be defined. I'm not sure how much belongs in ERTP and how much should be left to the contract author. That's a full topic on its own i think Currently, this code is custom-made in cosmic-swingset as part of the solo node I wonder whether it'd be possible to have the solo node being generic code that is mostly unintelligent pass-through between the blockchain and the client-side. This would reduce the Trusted Computing Base, but i'm unsure it can happen without loss of functionnality

As far as how the UI interacts with the CIO, i'm not sure. Either an HTTP or Websocket API as currently (but this requires for the contract author to do this work for the server-side) Or there could be a client-side ERTP to setup the client-side JS as a vat (or vats) that only communicates with the DOM (for the human) and with the CIO presence (for the contract) + confine this client-side JS with SES, probably. This bridges with the discussion of SwingSet on browsers

There is a whole other discussion if the UI is not a web page

In what i've written, there are still a lot of very open questions Also, i feel like i'm reaching limits of expressivity with written language. I can produce diagrams if that would make what i said easier to understand

[erights]

Hi @DavidBruant , THANK YOU! This will indeed be a big topic. But this is an enormous first step. I knew that there was a basic trust architecture problem we still had to face in our ui design, but I didn't know how to get oriented in it. We'd gotten as far as rethinking petnames and such for a fixed ui. But we (or at least I) had not seen how to bridge to the CapDesk insights of nested custom uis and trusted path. Your observation above strikes me as the conceptual bridge we needed. I agree about how much remains to be done, but now I feel oriented about how to start.

There is a counter-intuitiveness to some of the implied layering, but it may map to some issues that @dtribble and I have previously wrestled with (@dtribble, did we ever write anything on "scaffolds"? Does it hold up under our threat models?). More on this later.

I would love to see your diagrams!

[DavidBruant]

I'm happy i can be of help ^^ If i'm being completely honest, i didn't fully understand your message In the journey to understand, i think a good first step would be to read more about "CapDesk insights of nested custom uis and trusted path". Where could i read more on this topic?

---

Here is a first diagram that reflects my understanding of the current Pixel Gallery Demo architecture: https://docs.google.com/drawings/d/1VCFIqPSJvv_iVbwc4Jng6rN0_4dIBrU-2wkrxqPJlUc/edit?usp=sharing (with edit authority)

I'll do another diagram of what i envision as an alternative soon

[erights]

Start with http://zesty.ca/pubs/icics-2002-uidss.pdf and its description of trusted path.

[Chris-Hibbert]

CapDesk description, with links to other material.

I didn't understand the diagram. What relationships is it trying to illuminate?

[DavidBruant]

New diagrams can be found in a more presentable way here: https://github.com/DavidBruant/Documentation-1/blob/pixel-code-architecture/contract-ux-code-architecture/index.md (current state of the relevent PR)

Again, lots of parts are very drafty in my mind, especially in the wording so this is more the begin (well, or continuation now) of a discussion than the end of it

---

Start with http://zesty.ca/pubs/icics-2002-uidss.pdf and its description of trusted path.

Yes, i see now that the architecture i described proposed a clearer trusted path

I didn't understand the diagram

Is it better with the new and 2 diagrams?

[Chris-Hibbert]

Yes, the 'more presentable' version actually let me see both diagrams at once with the captions.

I think the salient difference is in the change of colors in the text of the middle column bottom section, which shows that Agoric would supply a configurable web server interface for the bottom left column (supplied by the contract writer) to host UI and web interface.

[DavidBruant]

I think the salient difference is in the change of colors in the text of the middle column bottom section, which shows that Agoric would supply a configurable web server interface for the bottom left column (supplied by the contract writer) to host UI and web interface.

Yes, that is what i'm thinking

[warner]

this was issue 121 in the old ERTP repo

[katelynsills]

Just to add a consideration, we cannot have the user-interface code on-chain as part of Zoe, since that would add a huge amount of data to the state of the chain. But, we would be able to add the code elsewhere and add a reference to that code, in the same way that Cosmos references IPFS pages in their proposals. https://cosmos.bigdipper.live/proposals/5

[katelynsills]

Our current thinking is that the contract developer and the UI developer may actually be different entities. We may want to allow for an explosion of different frontends using the same contracts. Furthermore, although the user receives information about what is happening from the dapp UI, any payments or offer go through their trusted wallet, so the threat of dapp UI being able to mislead the user is diminished.

With the above considerations, I think we cannot and should not make the UI part of the contract at this point. I'm going to close this as non-actionable, but there may be further work on having a standard of referencing IPFS data along with the contract. In the meantime, the contract can always provide a custom method on the publicFacet to specify its preferred front-end, if that is desired.