This discussion was inspired by comments from
@Stephan_Tual? in two other recent posts so I though I'd put here because I really want to see what other people believe is the future of Etherum and the reference clients.
http://forum.ethereum.org/discussion/751/so-i-designed-a-concept-ui-for-the-alephzero-clienthttp://forum.ethereum.org/discussion/711/web-components-marketplace-for-ethereum-ui-markupThe question is either Smart contracts should, in the future, have UI information. I see mainly two ways this could evolve:
* Ether contracts start having more code related to UI and how to present the information to the final user. New GUI elements are created and can be reused. Ethereum evolves into a whole decentralized OS.
* Contracts have information on what commands they accept and what's the data format or options each command takes. Ether provides the apis, and data for the backend of any app, in any platform. Clients can use whatever native OS code they prefer, and use Ether as the cloud api, a decentralized always persistent network.
I truly believe the second one is by far a better approach. First, because it's simpler and isn't a boil the ocean kind of approach. You don't need to implement custom interface elements, reinvent the browser, recreate 30 years of GUI code from multiple platforms.
Also, it promotes a separation of code in the Data/Model/Controller layer and the View/Interface layers. This creates cleaner and easier to maintain code.
Finally, it allows UI to flourish and Ether to be future proof. A OS built for the desktop isn't necessarily good for tablets and smartphones, and a mobile OS might not be good for wearables, robots or microwaves. OS's and interface needs change and separating Ether as just the data api we allow it to flourish in any platform.
A good example is Twitter clients. When twitter started, it was an open platform that allowed anyone to build clients on top. This created an environment where UI design flourished as everyone tested different approaches, on multiple platforms. The best innovative UI of the time came from twitter third party clients.
So in my vision, the reference client should only have a very basic "contract navigator" that permits you to use and test any contracts, but allows you to launch it in an external client for a better experience. This contract could have a list of accepted commands and a basic UI to provide the correct data in each command (a api request builder) but not more. The way data is presented, and how the interface is displayed, should be left to developers. (see attached)
Does everyone thinks similarly or am I too off the mark?
Comments
Right now there is no standard way for a contract to publish details of expected inputs. In fact POC-4 takes us to a place where this is more necessary because inputs to a contract are no longer a simple list but a binary blob format that will differ for each contract. A standard way for a contract to expose "API metadata" would make general-purpose contract browsers like yours feasible, and I think that would cover the UI needs for 99% of the contracts.
Whoever builds the first contract browsing GUI with widespread use -- that person will essentially set the standard. It might be the core dev team, but I'm not sure they've thought this far ahead.
I definitely agree with @avsa? that trying to make the ethereum client itself the primary means of interacting with contracts is going a bit too far. I appreciate that HTML5 is supposed to allow you freedom to do "whatever you want", but I just don't see that actually panning out when you account for all the design assets and UI specialization logic required to be bundled with it.
Insight into the thinking around this part would be appreciated.
@avsa, could you mock up a simple contract parser based on @mode80 etherscripter blocks or something similar? Your GUI would grab the contract code, get the details a la some blockchain viewer for additional information and then ok known code vs. unknown code and give free hints/paid solutions for anyone needing to discover the intent of a contract. I see only upside if we agree on WiA/BP but I am willing to entertain other solutions that avoid a muddy protocol.
I think we'll eventually need an EVM decompiler that's useful for auditing a contract's actual behavior, combined with some kind of reputation system.
From what I can gather here (specifically the last paragraph), is the idea that you point the client at a URL which can be a local file or a traditional web server, that provides you the content including javascript that has access to your ethereum client. All you really need is strong UI elements in the ethereum client/browser to provide an ACCEPT/DECLINE for create(), transact(), key() and keys(), and you're good to go. DApps can be served like a traditional website with the power of ethereum for the parts that need it, or can be packaged and distributed over something like a DHT-tracked torrent to run entirely locally.
The relevant take-away is that there seems to be very little hints yet of the ethereum client forcing any one particular UI onto DApps.