Linux Packaging Improvement

[step21]

I would like to improve the current packaging. Currently, you just run a script that adds third party software like nodejs and the whole ethereum ppa, without knowing or checking what I have installed already. Either this should be a proper install script, that asks what I already have, or it should be its own ppa with all required dependencies or a snap/flatpack with all required dependencies included. OR, most probably, a combination of all of the above, as it is unlikely/undesirable that users want multiple versions of ipfs/ethereum installed with separate data directories (such as might be the case for snap) Let me know what you think :)

[bakersemail]

As far as I know, this app is going to be a desktop application. If it is made a local web service, perhaps this could be packaged and run as a docker container instead? This would not cause the issues identified in the home page with control of resources, so long as it is kept as a locally running service that people access entirely locally. Might actually make the development of a desktop app simpler if it runs through the browser.

[step21]

@bakersemail Well, if you want only developers to run it... As far as I am aware, if there was anything mentioned like that on the github page/home page it referred to the decentralised nature of the app. More generally if you think this is a valid concern, please make a new issue for that and do not hijack this one.

[step21]

Ok maybe we are miscommunicating here. As it stands, the app is already written in such a way that it could easily be switched between running in the browser to an electron/nodejs window (what it seems to use). So I do not think it makes much difference for development. What do you mean by local webservice? To some degree that is already what it is, an app with html and javascript and/or various related technologies. But I fail to see how docker would make this better. This would be different/easier if it would be run centrally (which is a proper webservice ^^) but then there would be no need for all that decentralizing stuff. Using docker would however require every desktop user to install docker, which adds background services and other things that might not be wanted or the hardware does not support. When you say "How is it any different as developers to be the only ones to run it as a docker container" - I am not sure what you mean. Do you mean only developers would run it through docker? I guess something like flatpak/snap package for Linux could work, either using an Ethereum light client or using maybe a local ethereum node if already installed - which is probably the most difficult dependency atm. Of course I was asking for feedback, but I didn't say that I wouldn't comment on it. Apart from that I am also interested in the developers plans for that.

Edited because of wrong word.

[bakersemail]

Deleting my comments since I got this working.

[KadeMorton]

Hi @step21 and @bakersemail wanted to apologise for the slow reply, we've had some of our core contributers, including myself, moving countries recently and now we are all settling in getting back into swing. Glad to see you got this working, I'll still flag this discussion with our lead developer @roo2 to cast an eye over and see if there is anything we can improve on/take away.

[step21]

@KadeMorton thanks for replying. Just to clarify, I did get the app working, but I probably cannot count as average user. ;) The only thing that didn't work, it always said 'No ethereum peers found' (or similar) despite my Ethereum node being almost always fully synced up. Is that to be expected?

[KadeMorton]

I think it is a known issue but not sure, been trying to link up with @roo2 our developer, will continue to chase him and let you know.

[roo2]

thanks for looking into this @step21. yes we need help with getting packaging working properly. We originally designed it as a desktop app first but that's no reason not to package it properly. And as you said it's hopefully designed in a way to make it possible to build a CLI or daemon version later.

I agree that getting geth is potentially the biggest challenge and would probably be very platform specific. I'm not familliar with creating a PPA or snap but that seems like what we need to do. Are you still keen to look into improving this?

The other thing you found is the no ethereum peers found issue. We plan on running Aletheia on basically its own chain which will allow us to operate a free faucet to give users ether as soon as they join (to reduce the barrier to entry). At this point I'm still trying to get some stable bootnodes and a faucet setup for our testnet but basically the plan is to have a geth process running a private network.

[step21]

Thanks @roo2 Hope it's okay to continue this here. I don't think packaging geth is a big problem, though as all packaging it is platform specific. The bigger problem is syncing, and if to store your chain in the 'package' or in the normal platform way (homedir). I could probably work on this. At least geth also has a ppa and regular releases that can be updated by querying github. With ipfs I am not sure, it doesn't need to be installed but this 'deployment' as self contained blob I always find a bit weird or sometimes suspicious as it just goes against all platform specific packaging.

So does this mean that right now there is neither a private chain, nor a public chain to connect to? Based on what you told me, you should maybe think again about what you hope to gain by using a blockchain or using the ethereum blockchain. If this is just for testing, this is fine or you could also use one of the official ethereum test nets, which would be much easier than running your own. (Or, if you look at eth dev frameworks, some of them for development automatically create a local test net) However if this is the long term plan, I am not sure using Ethereum is a good solution. With a presumably small number of nodes, where probably only your nodes are mining (this for PoW as it currently works, disregarding future switch to PoS) there is not much decentralization and no benefit of the network effect for security, censorship resistance etc that a public blockchain hopes to provide. There are some alternatives that might make more sense, such as bigchaindb or I am sure there other, more efficient solutions.

[step21]

I made a snap package for Linux, that can provide all parts at once. It mostly works but with the current state of the app it does not make sense to distribute I guess. Later, this could be automated through use of electron-builder which you might use anway.

[roo2]

Dude, awesome. Let me know when it's ready to test and I'll try it out on my VM, will it take the form of a script that lives in the main repo? Yea even though we're not far along this will be good to get sorted early like you said.

WRT the private chain, I think you good points about not enjoying much benefit of decentralization without using a competitively mined chain. Here's my reasoning for why I hink a 'private' testnet is a good approach for us.

Upsides of a testnet:

• I think that the overhead of needing a traded currency to submit a paper is just too high. Getting actual ethereum usually means signing up for an exchange, generally handing over your proof of ID, and making a cash deposit at a bank branch.
• It's important that we get enough users to have a pool of reviewers and something like a network affect for reputation
• Our threat model is not as extreme as other projects using ethereum. Other projects such as DAOs or finance applications have attackers looking to earn large sums of money via hacks, since our system only deals with reputation and articles, there isn't the same level of direct incentive to attack us.
• A 'private' testnet allows us to make the underlying token invisible to users, when they open the app, it would connect to our faucet, and we can do traditional rate limiting

Downsides of a private testnet

• Reliance on some centralised infrastructure such as faucets and keys to prefunded accounts
• Vulnerability to DoS attacks such as have been happening to the ethereum testnets recently
• Overhead of setting up these networks and hosting infrastructure such as network monitoring, bootnodes etc
• Small number of nodes available
• Not really contributing to the wider adoption of Ethereum

I think that in order to deploy to a mainet we would need either: ether to be much easier to come by or Us to figure out a way of granting ether to new users (maybe, they can earn it via peer reviews? but if that's done on chain, how do they get the gas to do a peer review?)

[roo2]

I mean to type the reasoning up properly into a blog post or something, that was a bit of a brain dump. Anyway, thanks for looking at the snap packaging I'm excited to play with it and get to something worth distributing soon

[step21]

It is in my fork now https://github.com/step21/aletheia-app or here https://gist.github.com/step21/44d2050470b0d78752a7d89d25eabb8f It doesn't start properly yet because of some node error and so far geth and ipfs are included but have to be started manually. As this results in a development snap without signature, installation requires specifying sudo snap install --devmode <snapfile>. Then it can be run with aletheia

[roo2]

awesome, nice work I'll check it out asap

[roo2]

For starting geth, it needs to be with ./scripts/start-geth-testnet.sh I'm looking at it locally now

[roo2]

I think the best way to run it would be to have one main process which controls ipfs and geth, what do you think @step21 ? I'm not sure whether to do this from the electron app or have something wrap that too.

[roo2]

I got to the same node error with the snap package, I think we should look into getting the electron part package up with https://github.com/electron-userland/electron-packager before installing.

[step21]

@geth: Yeah, though in principle with the snap geth and ipfs would start automatically, there is just some error preventing that atm. For the snap/linux that should be fine but you would have to say if you want to be cross platform, for linux/win it would have to be different. Fort starters, maybe a shell script that starts both (as separate processes) could work, later you could check how for example Ethereum Mist Browser does it, it also starts a geth node at least and is based on Electron or something similar. @Error Sure, can be fine to package it first, mainly I wanted to get it to 'snap' and to put everything together. Either way the error could/can be fixed.

[step21]

Another app you could look towards re its use of electron-packager (how to use it etc) is sciencefair if you want.

[roo2]

awesome, I'll check out sciencefair and try to get electron packager set up tomorrow, I think that will get us past the current npm install error at least and hopefully then ipfs, geth and electron will all be started with snap, then we can think about doing something similar to the Mist browser after that