Open splix opened 8 years ago
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.
@realcodywburns we can use our version of geth or connect to an external node. I agree that parity is much better
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.
I can continue maintenance of Mist in Meteor, or start a new one in Angular. Is it in need of immediate updates?
@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
@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.
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? notifications@github.com 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 https://github.com/ethereumproject/volunteer/issues/17#issuecomment-241154084, or mute the thread https://github.com/notifications/unsubscribe-auth/AAywgQb6EDjJyUGLgDQYAQUgHN-RJea9ks5qhjK8gaJpZM4JluHT.
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
@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.
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 notifications@github.com 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.
@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.
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
In my opinion, we start at least two new projects:
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.
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:
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.
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.
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.
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.
@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.
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.
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.
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 .
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
Wow , a decentralized options exchange ! Good for Classic in the future !
As an alternative to EF Mist client.
Why we need this:
What are the problems with adopting Mist codebase:
Proposed tech stack:
Let's discuss
If you're interesting in participating in this project, mention it in the comments
Roles (leads, can be more than one):
Roadmap: