New Project Proposal - Classic Dapp Browser/Client

[splix]

As an alternative to EF Mist client.

Why we need this:

1. It's a user facing app, that's what influence our users the most. We can't just say use this app, it's not ours, but it's compatible
2. We need to use our own brand style, rather than reusing it with minor changes
3. Mist is not just a browser, but it's a set of components used by developers for building their Dapps. It's better to give tools which can provide maximum compatibility and unified style for Classic Dapps
4. It's second most important component, we can't rely on a third party

What are the problems with adopting Mist codebase:

1. Codebase is not ours, we don't have developers who feels the code
2. Based on MeteorJS - we still unable to find any single developer who had any experience with MeteorJS. Popularity of this framework is about zero, and there is absolutely no reason to invest in this technology at the year 2016 (based on Google Trends it has less that 1% compared to Angular and React, and falling)
3. This also makes problem for 3rd party Dapp developers, as some components are designed to be used with MeteorJS
4. There are many questions to the quality of current code

Proposed tech stack:

1. UI based on a popular JS framework, such as AngularJS or React. The most popular these days is AngularJS, but it has own focus and limited flexibility, it can be complicated to adopt it for non-standard webapp. React on other hand is a best example of a flexible JS framework, I think it's a perfect fit for this project. Also Redux shares some core principles with blockchain
2. We can use JS2015, Polyfill and other modern js tools which have proved their usefulness
3. For CSS we can use a Twitter Bootstrap as most popular choice, or get any other layout framework and build our components on top of it. It should be easy to learn and compatible with other styles. Maybe we need to have many implementations, including a theme for Twitter Bootstrap. Let's discuss this moment
4. Use a launcher written in Go that can run geth and provide additional API (such as conversion rate for ETC, manage accounts, unlock, etc)

Let's discuss

If you're interesting in participating in this project, mention it in the comments

Roles (leads, can be more than one):

• developer for launcher (golang or rust)
• UX/UI designer
• developer for Dapp theme and reusable standard components, css & react (and this will be a separate project)
• developer for default UI

Roadmap:

• define tech stack and find people
  • go or rust?
  • React JS
  • Material UI
• make a UX design for main app
• get a good name for the app (let's brainstorm?)
• define graphical style guide for ETC Dapps (fonts, colors, etc)
• start theme development
• start launcher development
• start default Dapp development

[realcodywburns]

I fully agree with you. I do, however, think the backend should be parity or some other similar 3rd party app. Parity has shown commitment to naming their chain option as classic rather than just --oppose-dao-fork. Geth and ETH can and most likely will move to only support the HF gain at some point.

[splix]

@realcodywburns we can use our version of geth or connect to an external node. I agree that parity is much better

[marcusrbrown]

I propose Material UI instead of Bootstrap, especially if we use React (which I'm also strongly in favor for). Material UI fits into React a bit better and IMO it's cleaner looking and distinguishes the UI from the original Mist browser.

[elaineo]

I can continue maintenance of Mist in Meteor, or start a new one in Angular. Is it in need of immediate updates?

[splix]

@igetgames MaterialUI looks god, I see they have very nice components. Little bit worried that it looks too much Android, but I guess we can improve it.

@elaineo yes, we need someone to maintain Mist. It's super important at this moment, and we don't have working version yet. It would be great if you would have a look

[whatisgravity]

@elaineo I really appreciate your help on Mist, if you want to take over the project that would be preferable for me. I would like to focus my efforts on geth and possibly a new UI for it.

I have been putting together a more in depth proposal but I think we should make a different UI for geth. I have been investigating the different options for building it with golang but I'm open to other solutions. The material library in golang is not well developed but I think it would make a good candidate when it is more ready.

As for a mist replacement I propose we investigate using https://github.com/servo/servo or another browser engine as a foundation for mist browser. It would allow us to maintain it in rust which requires no additional overhead to create binaries and preforms better than JS. It also lets us make important decisions regarding scripting and have refined control over a wallet interacting with a website/application.

[marcusrbrown]

That’s a an interesting suggestion… Do we currently have Rust developers who want to pursue it? We have several developers who are well-versed in JavaScript, but I haven’t heard anyone mention Rust.

The other advantage of staying with JavaScript (at least for the core of Mist and the wallet) is we can support more platforms than Rust is available for, such as the desktop browser (or other browser-based platforms) and mobile.

On Aug 19, 2016, at 3:48 PM, What is Gravity? [email protected] wrote:

@elaineo https://github.com/elaineo I really appreciate your help on Mist, if you want to take over the project that would be preferable for me. I would like to focus my efforts on geth and possibly a new UI for it.

I have been putting together a more in depth proposal but I think we should make a different UI for geth. I have been investigating the different options for building it with golang but I'm open to other solutions. The material library in golang is not well developed but I think it would make a good candidate when it is more ready.

As for a mist replacement I propose we investigate using https://github.com/servo/servo https://github.com/servo/servo or another browser engine as a foundation for mist browser. It would allow us to maintain it in rust which requires no additional overhead to create binaries and preforms better than JS. It also lets us make more important decisions and have refined control over a wallet interacting with a website.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #17 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAywgQb6EDjJyUGLgDQYAQUgHN-RJea9ks5qhjK8gaJpZM4JluHT.

[elaineo]

Sure, I'm happy to take over Mist. I haven't done much research into the performance of Rust vs JS, but I think it's a better choice if we're going for a high-assurance system. It will also be easier to migrate from Rust to Go, than from JS to Go.

@igetgames You can build mobile libraries with Rust: https://github.com/kennytm/rust-ios-android

[elaineo]

@igetgames The point you make about lack of developer support is fair. I'm new to Rust myself, but anyone with a strong background in C should be able to pick it up quickly. It could be tough to attract casual contributors though.

[marcusrbrown]

I'm also interested in learning it ever since reading Parity source. I'm just thinking about getting the most bang for our buck in resources, and the ecosystem for JS is more mature and stable than Rust's.

Ultimately whoever takes lead of that project should make the call.

On Aug 19, 2016, at 5:27 PM, Elaine Ou [email protected] wrote:

@igetgames The point you make about lack of developer support is fair. I'm new to Rust myself, but anyone with a strong background in C should be able to pick it up quickly. It could be tough to attract casual contributors though.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[elaineo]

@igetgames We can leave this open a few more days to see if others weigh in. If no one speaks up by next Tuesday, I can take the lead in Rust.

[realcodywburns]

I'm fine with whichever language. I don't have a strong preference and can hack & slash in just about any language. I have been meaning to look into rust, now is as good a time as any I suppose

[whatisgravity]

In my opinion, we start at least two new projects:

1. A secure GUI client, the easiest path being that it will pair with existing clients like parity and geth.
2. A dapp browser/client, possibly combining parity with servo (more research needs to be done) or cpp-ethereum and a cpp engine like chrominium

Mist will work well as a stop gap while we develop alternative browsers and ways to use Ethereum. It will also ensure we allow innovation to cross between the chains easily.

I believe the alternative secure wallet GUI is a very important milestone and can be built separately from a new "web3" browser.

I think there may be an interesting way to combine docker and geth to create a framework for decentralized applications that leverage smart contracts but I'm still researching.

@elaineo I think Mist is an important enough project for both of us to collaborate until we can get more volunteers to help. I sent you an email to start the process of dividing up the available tasks.

[splix]

I like the idea of using Rust for main code, Rust's focus on security and performance better fits this project.

But we really need someone experienced with Rust. I know, it's always seems easy to learn new language, but even for experienced developer who has just switched to a new language, it takes a year or two to start writing good code. And this developer usually embarrassed of the code he has written during first year :) So to start this project we need to find a developer who wrote production code with Rust before

@igetgames javascript is still the choice for dapps and ui, we just need something for core app that run browser in embedded mode and provides an Ethereum node with JSON RPC.

I don't think it's good idea to start with Servo btw. There are two reasons:

• dapp developers want to see a stable full-featured browser that have full support for most of modern HTML/CSS/JS features. Chrome/Chromium is current leader
• also they need development and debugging tools. As I know Servo can be used with Firefox Developer Tools, but I'm sure Chrome tools are better (but I didn't try Firefox devtools for at least 5 years, maybe they made a great progress since then)

[whatisgravity]

I'm not suggesting we completely abandon the EF paradigm of Javascript dapps/ui. I believe we can maintain that work alongside an alternative that I believe is more secure.

With my understanding, most dapps are going to need to very carefully pull data from the blockchain to display in the UI because a XSS attack could leak private keys since the entire wallet is loaded in the JS too. I believe we can build a framework for decentralized application development that attempts to solve these type of problems immediately.

Working from the browser engine level we give ourselves more options. For example, we could modify the JS interpreter, control how data is handed over to the interpreter from the browser, we can store sensitive data outside of JS or even change new DOM/scripting languages but I suspect changing won't be necessary.

It may take a little longer but it will be more secure and create a better foundation to build frameworks.

[splix]

It's not necessary to provide keys to the Dapp. Dapp usually just can asks to approve a transaction from parent. Currently it's done through JSON RPC, you send a request to a node and if this key is locked it asks a user to unlock with password. That's how Mist and MetaMask works at least. Parity also haw a "Signer" feature, with deferred actions, where you can approve key usage later by using a special Signer UI. I also have some ideas how to make this more user friendly and maybe more secure, but anyway it doesn't require to provide keys to a Dapp.

What's important that our Dapp Browser must store and use this keys securely (on launcher side). I'm sure we can do it better than current implementations.

Chromium dev team is good in securing JS so far, so better to leave it for them for now. Maybe later we'll return to this moment, if it will be necessary. I think it's interesting idea actually, maybe it can give us some advantage, but unfortunately we just don't have resources for this at this moment. Let's start with minimal working solution, and choose proved solutions for parts that aren't a differential advantage of our product.

[realcodywburns]

I like the concept of Metamask providing dapp functionality in regular Chrome by using the web3.js. Chrome and firefox do many things very well that would be hard to reinvent. I guess I do not understand the need build a new browser if the only improvement is adding dapps.

Geth can be run locally and provide local accounts via rpc if desired.

[whatisgravity]

I don't think I made my point very clear about the XSS attacks. I'm taking a little more time and doing some PoC with Mist. Then I can illustrate my point better.

There are other design reasons why as a developer interested in making decentralized applications Mist is crippled too, primarily because I don't think people should be relying on centralized servers to serve assets (introduces security issues too), or storing them on the blockchain.

[splix]

@whatisgravity JFY I've started with the project, trying to structure it better, and going to split it into smaller projects

About centralization server - we use browser for js and html, this browser could not even know where from these files were downloaded. Protocol is controlled by Launcher, resulting html rendering and js execution is controlled by Browser. It's just separate things.

[whatisgravity]

My understanding was based on early Ethereum Dapps, like Etherdice.io for example (https://etherdice.io/).

In this design model, you navigate to their web site inside of Mist browser which enables web3.js to hook into Mist and provide information from the blockchain to be rendered on the page.

This is just one way XSS attacks can be introduced in a nonstandard way. For a simple example: if you can sneak the XSS into a transaction that is rendered on the site.

If this is not the standard implementation that may be why I'm not understanding.

[splix]

I mean if we do that just to add new transport protocol, it's not necessary to make a custom browser. Notice that Tor, ZeroNet and I2P are using custom protocols but you can use them from standard Chrome. Okay, Tor maybe doesn't want you do that, but it's because of other reasons.

I believe Chromium already have a security team, and if we'll find a XSS because of a browser bug they will be happy to fix it for us.

[kimisan]

I am a fully node.js/expressjs/d3.js guy ...
So maybe I can help with the default UI develop and UX/UI design.
I will start to prepare some prototype of wallet default UX/UI for your reference .

[realcodywburns]

https://etheropt.github.io/ is a good example of a fully web3 integrated site. You can reach it in a regular browser, it can interact with either a chrome plugin wallet or geth running locally

[kimisan]

Wow , a decentralized options exchange !
Good for Classic in the future !