bee
bee copied to clipboard
Make `bee start` and bee.service run by default without errors
Summary
After a fresh install, starting a bee node automatically as a service or manually with bee start
results in a vague error message and a process exit. This is a huge obstacle from a DevRel perspective for developer adoption. The default configuration (or/and config parameter values) should be modified to ensure that the bee node runs without exit errors.
Motivation
Most developers who set out to install and run bee for the first time are faced with an error that is not too obvious how to fix. This also severely impacts developer adoption from a DevRel perspective.
Running bee start
after a fresh install should just work! It should not throw errors or expect dapp developers to rely on documentation to figure out what the error message means.
In a fresh machine with no prior installs:
wget https://github.com/ethersphere/bee/releases/download/v1.11.1/bee_1.11.1_amd64.deb
sudo dpkg -i bee_1.11.1_amd64.deb
# not really needed as bee.service wont start the node anyway
sudo systemctl stop bee
# start bee manually using default configuration
bee start
Implementation
Two possible ways to do this (maybe there are other ways to do this):
- Change the default value of
blockchain-rpc-endpoint
from""
to a valid rpc url (as is the case for Swarm Desktop) - Change the default value of
swap-enable
fromtrue
tofalse
(default start as Ultra Light Node) Probably not the best option
Drawbacks
There might be historical reasons for this, but I can't see any problems with this proposal.
Swarm Desktop starts with swap-enable: false
. I advise against implementation 1., as the end user would immediately have to supply xDAI to the node, otherwise it is also an error.
really good idea to review this, thanks for the initiative @rampall, i concur with @Cafe137 - then the user can be directed to find the eth address, fund the node and then convert to light/full
i mentioned it as "Two possible ways", however i see Swarm Desktop sets both of those parameters in its default (ultra-light mode) configuration :
-
swap-enable
tofalse
-
blockchain-rpc-endpoint
to a valid url (unless there is the risk of ddosing it)
In the desktop app the decision was made to set the blockchain-rpc-endpoint
to a known, reliable public RPC endpoint because a light node in general only accesses it as an effect of a user initiated action from the UI and if there is a problem with it, it can be reported back to the user and worst case scenario the user can change the RPC endpoint to a working one.
This is very different in a case of a full node. It runs in the background and there is a constant communication with the smart contracts, and often this is critical from an operational perspective. For example if a node fails to follow the steps in the protocol defined by the redistribution smart contract, it can be punished (currently with freezing, later with slashing the stakes). So it is imperative that the RPC endpoint is reliable and the node operators are aware of the consequences of choosing an RPC endpoint. This is why currently the documentation recommends the node operators to run their own RPC endpoints as well.
Another important aspect is decentralisation. If there is a recommended RPC endpoint by default and most node operator runs their node with that then in the case of that RPC endpoint goes down may render the whole network unusable, defeating the purpose of using a decentralised network at the first place.