Sure, that’s what I meant with
1 Like
Could Nubot automatically calculate the trade volume of one custodian and immune to vicious modification?
Assume in future, there are 1000 custodians on dozens of exchanges, the Nubot monitors every custodian’s trade volume and calculates how much compensation should be given to every custodian. The whole process is automatically and transparent to the public.
2 Likes
I think the NuBot can be improved regarding data security. Right now, everyone with access to the machine with a running NuBot has also access to the funds and the exchange secret. So I’d like to propose two things:
-
Wrap the unlocking mechanism in NuBot, such that you provide the wallet password to the NuBot and it unlocks the wallet internally over SSL RPC when its required.
-
Allow encryption of the options.json. Ideally separate the API keys and secrets from the json file into another more secure format. The exchange name should be sufficient as key to look them up.
Well noticed, thank you
We already have a plan and @woolly_sammoth had a couple of interesting proposal to use BIP38 for encrypting keys 
.
1 Like
Sorry I didn’t have time to comment earlier.
The most urgent concern of the Nu network should be to see what we can do to increase user acceptance of NuBot. Some haven’t been able to get it set up, others have stopped using it after a trial, while I suspect most are just intimidated by it. Three things that could help a great deal:
1. Graphical user interface: geeks forget that most people wouldn’t even consider using a program without a UI. Trusting funds to it, with no way to see what it is doing with them, must seem quite unnerving.
2. Complete accounting with reports: Every trade should be recorded in a local DB. Users should be able to easily create reports to see how much money was made or lost in a specified time frame, deposits and withdrawals made, etc.
3. Improved ease of deployment and setup: Setting up NuBot is still in the domain of IT professionals. We should be able to permit ordinary people to use it. This means you install it, it asks you some questions, then it just works.
I would like to hear more details about the plans for:
I suspect it makes sense to prioritize the three items above either after 0.2.1 or after 0.2.2.
What does everyone else think?
3 Likes
You nailed it down.
I’m not a geek, but familiar with computers.
But I haven’t proposed for an LPC position, because I think it’s still too complicated for the one or two thousand dollars liquidity I could offer right now; it’s just not worth the struggle. I can’t look after the bot etc. all day long.
Give me the image of a Peerbox equivalent that runs all necessary programs, daemons, bots and that can be configured easily (I wouldn’t care for a GUI, but I agree that a GUI is important for the masses) and just runs like a charm and I’m in!
I don’t know what went wrong here, but things like that are intimidating.
The graphical user interface could be produced in small, simple iterations. Perhaps the first version should merely contain a start button, a stop button, and the same info that is presently logged presented in the UI. The second version could permit essential options.json settings to be entered in text boxes and dropdowns so that the user doesn’t need to edit options.json directly. A third version might show information about open orders and recently executed orders. A fourth might feature reports on trading history, deposits, withdrawals, transaction fees and profits/loss.
1 Like
To increase adoption, it should definitely be made easier. A GUI helps but is not necessarily the first step. Standard setups/profiles (e.g. with images or containers for e.g. Rpi or VM ready to run on key exchanges), reliability and reports about transactions and profits/loss are. Ideally an auto-email or TXT message built-in on errors/issues, which also copies to an location accessible to the devs. Common errors should be well-documented and restarting the bot should be easy (a GUI might help here).
As releases follow each other fast at this stage, it appears that developments are still not at a level ready for mass adoption. It might be worth to focus on a stable release branch and document that properly even though it has not the latest features. With that release experience and knowledge sharing can be built upon by a wider group.
This while other releases get the bleeding edge features for those at the forefront of testing and trying the latest at higher risk or requiring scarce skill sets.
@desrever @woolly_sammoth @benjyz @pennybreaker Perhaps something like this should be created immediately so @muchogusto can begin providing liquidity.
In terms of deployment and profiles. I have implemented a build of NuBot with the tool Gradle this week - basically implementing 0.9.4 of the roadmap. Gradle offers a DSL language for defining how programs should be run. It’s a very flexible build tool. This means that deployment can be simplified, different builds defined etc. This should provide NuBot with everything that is needed in this area. The JavaVM is already a VM so there should not be a need for containers (I have tested docker for client installs before and found they introduce too much complexity). I will have to look into how to streamline the process. Besides entering confidential information (which can’t be automated), everything can put into a build script. Another option might be offering a cloud solution, but there are complex security considerations around that. Cloud providers now offer the capability to build pre-defined images via tools like Packer.
Good to see community-driven prioritisation of the roadmap. I am more than happy to adapt to it, as I said earlier.
Let me reply in line.
This is work in progress : in particular there is an utility I’ve built that custodians are already playing with that reports all executed orders. Sample output from my operation on excoin : http://pastebin.com/p2NCKq10
@Ben is working on integrating and making it more human-readable.
In terms of roadmap prioritisation this is currently in
0.4.4 : NuBot toolkit release ( trade history, balance history, price-peg execution bot)
I think it makes sense to leave it where it is in terms of prioritisation, cannot be moved much earlier than that.
There is a GUI designed and coded since last summer we can re-use. I never hooked it up as no-one ever asked for one and I avoided adding complexity. In 7 months many thing changed but most of the code/design is still re-usable.
Please take into account that the totality of custodians to date run nubot from the command line on a VPS or raspberry and they won’t be able to use a GUI.
For the above reason I believe that we should leave the “Bots manager UI” prioritised as it is now in 1.0.0 . However, what can be done quickly is another kind of UI :
So this will solve a different problem, probably more useful in the short term : nubot configuration.
Currently to configure the bot the custodian need to configure a json file (or multiple json files)
following this tutorial -> https://bitbucket.org/JordanLeePeershares/nubottrading/src/a59f70b780af8730ba92b99dc2d81e91fc7b7ddf/SETUP.md?at=release/0.1.5
Or they can download the sample.zip configuration file and try edit it and reverse engineer it.
We can build a (stand-alone) UI that does nothing but :
- provide a graphical way to configure the bot, and behind the curtains generates the configuration files for the custodian.
- allow custodians to save configurations and assign a name to each "profile
- provide a “launch bot” button that simply runs nubot with the profile created above.
However, there is no way around it… I believe that custodians must be very aware of what they are doing, and how each parameter they touch will affect the behaviour of the bot.
If you think this makes sense I can add a ticket somewhere between 0.2 and 0.3.
Perhaps the first version should merely contain a start button, a stop button, and the same info that is presently logged presented in the UI. The second version could permit essential options.json settings to be entered in text boxes and dropdowns so that the user doesn’t need to edit options.json directly. A third version might show information about open orders and recently executed orders. A fourth might feature reports on trading history, deposits, withdrawals, transaction fees and profits/loss.
Totally agree, the user interface must be built in iteration and the first logical step is making the tool that generates the .json configuration profiles and allow the user to start/stop the bot.
I can envision endless improvements and iterations (API key verification, logging, multiple bot management, move liquidity across markets, reporting, a graphical tool to model the order book etc.
However, everything but the setup UI must be built after v1.0 , where all protocol changes are ready, otherwise it will just enormously slow down the development process requiring change things in several places when we are not even sure of future directions.
2 Likes
I think a simple web UI to create the json files and to show some stats about the bot would already be sufficient + it would be accessible for the VPS / RaspberryPi people.
3 Likes
I just uploaded some screenshot of the JavaFX UI I built last summer, which can largely be re-used .
Please note that html logs are already in place since 0.1.2
2 Likes
I am running NuBot from a desktop machine. I think I should migrate to a VPS.
Edited original post with changes to roadmap
Edited original post with changes to roadmap
Updated roadmap with new short/midterm priorities
1 Like
Can we change the roadmap along the way? with motions?
Of course, but please do only for macro items at high level and only when there is a strong disagreement with current priorities.
2 Likes