Doh It’s not your fault, and you are not the only one don’t worry! So let me go off-topic just for a little while : It’s a piece of software that process data (liquidity, motions, supply, grants, parkings… ) from Nu network ,saves it on historical db, and exposes it via rest API for third-party apps to consume. The first “third party” app will be a web dashboard hosted on nubits.com that visualise all of this data and help shareholders (and prospects) to take decisions
It has been planned/designed for loooong time in a sort of stealth mode. You will hear more about it very very soon!
@desrever has delivered a very sophisticated piece of software with NuBot.
It would be a pity if the development would slow down or stop because of missing funds.
But I bet Blocks & Chains Exchange would willingly offer some development funds in that case, because BCE will need a sophisticated NuBot as much as Nu.
This multi signature grant is a nice test run for future management of the tier 4 and tier 6 funds that shall be put into the hands of multi signature custodians.
NuBot is a very sophisticated and at the same time very powerful tool.
I believe it is a mandatory tool for the total success of Nu.
Therefore I will support this grant since it s about adapting NuBot to ALPs which are the main engines for decentralized liquidity operations.
By the way, right now, NuLagoon, and the liquidity operations by @masterOfDisaster are using NuBot.
It would be great to have a feedback on the efficiency gain (decrease of liquidity costs) generated by the parametric order book if they are using the latest version.
I’ve been waiting for this for a while, very exciting!
Just a quick question though. From my understanding ALP liquidity providers have been using only tier 1 this whole time while NuLagoon has been using multiple tiers. Would this integration allow ALP liquidity providers to use tier 2 and above as well?
NuLagoon can compare it with previous operation (NuBot without parametric order book).
The results of this comparison need to be taken with a grain of salt, because the results highly depend on the market situation.
Ideally you’d compare one NuBot operation with parametric order book and one without at the same exchange, pair, time.
I can try to compare it with the ALP bots I still run. I shut my bots on liquidbits down, but still have nupond and nupool bots left to compare with.
I think it is the logical next step we need to make and would therefore support this grant. Would this also cover for some basic support e.g. when exchanges make changes or we need to add new ones.
The grant approach is a good experiment. I’m glad to see more decentralised, shareholder drive development after the NuDroid grant. Given the work is only one month one payment is fine. Could you elaborate a bit at what stage you would expect payment? After delivery or after successful testing for a week? Closely related to that question, what key criteria would the three shareholders use to make the payment.
I’m looking forward to test and ultimately run NuBot against the ALP software. It would be huge progress.
Thank you @Cybnate, was looking forward to see your comment since you have done something similar in the past with NuDroid you certainly know how to handle things like this.
Support is not included in this grant. Severe problems that might emerge later in production requires a case-by-case analysis. In some cases I am open to do that for free, but only when a fault or lack has been caused directly by myself while adding 0.4.1 code and the fix require short time (a hotfix). In most cases, that’s part of the business and this grant doesn’t include any maintenance.
And FYI, adding a new exchange is not considered support in my terms, is more like adding a new feature (and a fairly big one).
For future development of NuBot, (see new roadmap), we have to think of a more sophisticated grant (if we want to continue). A separate grant is probably needed for maintenance. For now I am only looking at the specific 0.4.1 release.
For this grant the acceptance criteria will be set in private with the grant administrators. I plan to write some acceptance test in plain english, so everybody can review it. I expect the payment as soon as acceptance test passes .
An example of acceptance test from another project can be as simple as (example from a random project) :
Story "User Login" (2 pts)
Story : after creating a user, the system will know that you are
that user when you login with that user id and password; if you
are not authenticated, or if you supply a bad id/password pair, or
other error cases, the login page is displayed. If a CMS folder is
marked as requiring authentication, access to any page under that
folder will result in an authentication check.
For the ALP integration I will limit myself to write only some high-level acceptance tests otherwise the cost of it will climb up significantly if I had to do it for each tiny bit I need to touch, and we can’t really afford it .
The motion is live for voting, I edited OP with grant information … If you support this motion please configure it into your client so I can get started asap
Not an easy one to do now without having the hashing in mind to start with when you wrote the request.
At a minimum it is the TLDR and the grant request I would say. But the information in 'Integrating with other funds is also a cornerstone to this request, so you almost end up with it all except ‘Why a grant’ and 'I want to vote for it… how?"
<motionhash><p><code>=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=</code></p><p><motiontext><h2>TL;DR</h2><p>I'm asking for 1216 NBT custodian grant to fund development of NuBot 0.4.1 that has as main feature the integration with ALP server.</p><p>I will also be using 1783 NBT I collected one year ago for a different purpose to fund development.</p><p>The grant will be assigned to a 2-of-3 multisig address controlled by @masterOfDisaster @erasmospunk and @woolly_sammoth that will act as intermediary for the payment and verifications. If any funds are left after development, they will be burned.</p><hr><h2>Grant request </h2><pre><code>Currency : NBTAmount : 1216Public address (multisig) : Bdoa6XJzzfFrMgwysASZGmvSMoXGPmQD6R</code></pre><hr><h2>Rationale</h2><p>In the last months our liquidity provision software grew along two independent branches : on one hand we have seen TLLP/ALP development bringing a huge degree of innovation to our markets and opening up a whole new generation of distributed/pooled liquidity providers. On the other hand we have seen [continued development][1], new features and more stability built into NuBot, our core liquidity provision client.</p><p>So we have these two solid pieces of infrastructure in place : the ALP server and the NuBot client. But there is a problem : now they don't talk to each other.</p><p>NuBot's sophistication could lift the standards of our liquidity operations (price feeds, parametric books, reports, run as a service... ) and the full potential can be unleashed when we let user's provide liquidity in a pooled/distributed fashion using ALP servers. This integration is feasible with very little effort when compared to how much effort has been put into these two components so far. Both NuBot and ALP architecture are API-ready and it's both my opinion and @woolly_sammoth that integration is a no-brainer. It's time for us to exploit this potential and orchestrate a plan that finally optimises the uses of our limited resources.</p><p>Improving the ALP server (its currently being rewritten from scratch) and moving away from the need of maintaining and continuously catch up the current python script originally written by creon its the way forward, imho.</p><hr><h2>Why a grant?</h2><p>It's about time we start trying to move away from a centralised book-keeping approach that puts all the burden and decision making on the shoulder of one person. @JordanLee seems to agree that this is the way to go, and indeed this is a good candidate to be one of [the roles that should be filled by shareholders][2] .</p><p>As I already expressed in [this long post][3], I expect an hybrid model to emerge, where Shareholders can elect/replace an "human resource" committee. This grant is the first step in that direction, and its amount is small enough that will give us the time to learn and correct from mistakes.</p><hr><h2>How will this grant work? </h2><p>The NBT grant will be used to compensate the development effort for NuBot 0.4.1. A first plan have been already been laid down by myself and @woolly_sammoth and a milestone has been created on bitbucket, where you can see [open issues][4]. As you can see the great majority of open issues are strictly related to NuBot/ALP integration, with only a minority of low-priority features that I believe can be packed together with the 0.4.1 release.</p><p>The NBT address, receiver of this grant is not controlled by myself : it's a 2-of-3 multisig address controlled by three shareholders (@masterOfDisaster, @erasmospunk and @woolly_sammoth) that volunteered to act as intermediary. They responsibility includes, and might not be limited to :</p><ul><li>Create the multisig address and store its private key safely for the duration of the development period</li><li>Receive the funds</li><li>Verify deliverables (NuBot 0.4.1 working as expected) </li><li>Pay contributors </li><li>Burn leftover funds, in case devs used less than originally asked for (3000 total). </li></ul><p>They will act as a micro HR department and a shield between development and shareholders. As this will be hopefully a small sprint (in the order of 1 month) the payment will be executed at the end, instead that having fractional payments.</p><p>The multi-sig custodians will keep 60 NBT for themselves (20 each) as a symbolic non-zero compensation for their time and responsibility.</p><hr><h2>Integrating with other funds</h2><p>To reduce the stress derived from creating new currency, I will integrate the amount of this grant with other funds to pay for development .</p><p>As you should already know I am still holding [1,783 NBT][5] on behalf of some shareholder (myself included ...) that decided to [re-invest some dividends in Nu][6] one year ago. Despite the original purpose of the fund was different from funding NuBot development, the scenario changed radically since November 2014, and as I explain the the dedicate thread, I decided this is a good place to invest them now.</p><p>I will transfer 1783 NBT to the multi-sig address used for this grant, as soon as this grant passes, so that funds can be used for funding development of 0.4.1 .</p><p>The total amount I will be using to develop NuBot 0.4.1 is therefore capped to about 3000 NBT ( 1783 + 1216 ). As outlined above, if I can complete development using less budget, the leftover will be burned by multi-sig custodians.</p></motiontext></p><p><code>=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=</code></p></motionhash>
Received
156b9dc4c2c352cd1b0d294282f29d0cf0526b4f and
156b9dc4c2c352cd1b0d294282f29d0cf0526b4f
I tried it on my RaspberryPi as well, but putting all from <motionhash> to </motionhash> in a file and hashing that file via rhash --ripemd160 generated bbe254325404f94914174d8b7da8209ffdddf9cf.
It’s not your fault, and you are not the only one don’t worry! So let me go off-topic just for a little while : It’s a piece of software that process data (liquidity, motions, supply, grants, parkings… ) from Nu network ,saves it on historical db, and exposes it via rest API for third-party apps to consume. The first “third party” app will be a web dashboard hosted on nubits.com that visualise all of this data and help shareholders (and prospects) to take decisions