NuBot development roadmap - From 0.1 to 1.0

desrever · January 19, 2015, 12:27pm

In its simplest interpretation, NuBot is the tool custodian uses to automatically keep orders at 1$ in open markets. While being open source, shareholders can steer the wheel to direct development direction.

To put shareholders in control, the first step is to create awareness around the project current and future direction. Here is the first attempt to create a shared vision on how NuBot can evolve.

Priority has been given to loss-reduction items, which can be both goals and features.

0.1.5 :
Simple implementation that allows multiple custodians to operate on the same non-USD market ;
Basic tier 2 implementation .
0.2.0 :
Completed port to gradle
Upgrade to Java 8
Major refactoring across the codebase
Unit tests inception
0.3.0 :
Run bot As A Service, with a web-interface
UI to generate configuration parameters
UI to run the bot
UI to monitor the bot
NuStringEncrypt implementation [@woolly_sammoth] ;
0.3.1 :
Price-feed streaming service implementation and deployment
Consume price-feeds via web-sockets (instant shift, synchronised)
Integration of NuStringEncrypt and NuBot
Basic HTTP API to interact with bot at runtime
API keys protection system ;
Log trades for each bot session
0.3.2 :
First implementation of (tier2) liquidity distribution model
Configurable Parametric liquidity distribution models
Default Liquidity Distribution models
Replenish Tier1 dynamically
Preview liquidity distribution model in GUI
Output file with report of executed order at the end of each session
Enforce motion 0ec0be7f113a0bf6ff603545a974cd6410458e00
Submit liquidityinfo identifier
Tooltips for configuration in GUI
: 0.4.1 :
NuBot as ALP client
Adapt authentication strategy
Visualize stats from pool
SoutXchange and Cryptsy integration
Front-end restyle
Preview orderbooks in web-browser (raspi compliant)
0.4.2
Liquidity balancing across markets
Introduce (some) orderbook models for different market conditions
Improve the dynamic t2<>t1 liquidity movement
Improve orderbook design based on 0.3.2 feedback
0.5.1
Market-aware liquidity distribution models ( adaptive )
0.6.1
Automatic liquidity balance across markets/exchanges
0.7.1
Tier3 liquidity management
NuRPCCoinClient implementation
Integration of NuRPCCoinClient and NuBot

[TBD] future releases
GUI v2 with more features
Automated test suite
Automated management of tier3 liquidity ;
GUI v3 with UX wizard optimisation
NuBot toolkit release ( trade history, balance history, price-peg execution bot, encrypt/decrypt tool, config generator )
Futures markets integration (hedging)
Real-time reports
Redundancy bots
String externalisation and translations models
Multiple bot sessions controlled via GUI

The above roadmap is a draft and will likely be refined and subject to changes.

Feel free to ask any questions.

cryptog · January 19, 2015, 12:45pm

Impressive. This roadmap shows that NuNet is also an automatic trading software company…

Shouldn’t it be 1.0.1?

And what about the time horizon? How much time needed to get to the final evolution?

desrever · January 19, 2015, 2:59pm

Its arbitrary, 1.0 is generally intended as (feature)-“complete”

The least possible time. Let’s try to stay away from estimates in such borderline complex systems.

Ben · January 19, 2015, 4:05pm

I think you mean:

0.10.0 : Bot manager GUI

Sabreiib · January 20, 2015, 12:19am

@desrever theoretically, is possible for Nubot to inspect one custodian’s activity on NBT/BTC pair and automatically report this to the public? Can the protocol itself judge the custodian’s behavior automatically? For example, retrieve the trade volume of one custodian on a certain pair.

desrever · January 20, 2015, 10:02am

Sure, that’s what I meant with

Sabreiib · January 21, 2015, 1:15am

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.

creon · January 30, 2015, 6:34pm

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.

desrever · January 30, 2015, 6:52pm

Well noticed, thank you

We already have a plan and @woolly_sammoth had a couple of interesting proposal to use BIP38 for encrypting keys .

JordanLee · February 7, 2015, 8:05pm

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?

masterOfDisaster · February 7, 2015, 8:31pm

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.

JordanLee · February 7, 2015, 11:36pm

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.

Cybnate · February 8, 2015, 1:20am

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.

JordanLee · February 8, 2015, 2:32am

@desrever @woolly_sammoth @benjyz @pennybreaker Perhaps something like this should be created immediately so @muchogusto can begin providing liquidity.

benjyz · February 8, 2015, 8:38am

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.

desrever · February 9, 2015, 10:08am

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.

creon · February 9, 2015, 10:35am

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.

desrever · February 9, 2015, 10:40am

I just uploaded some screenshot of the JavaFX UI I built last summer, which can largely be re-used .

imgur album:

http://imgur.com/a/7LdtT

Please note that html logs are already in place since 0.1.2

cryptog · February 9, 2015, 6:12pm

I am running NuBot from a desktop machine. I think I should migrate to a VPS.

desrever · February 16, 2015, 10:26am

0.1.5 out , edited original post. Release notes here -> NuBot releases