Help testing NuFeeder voting manager

Hey everyone,

I’ve been working on this little application for the past couple of days. It’s still in an alpha state but it works, so i’d like to have others try it out so I can get some feedback.


The goal of NuFeeder is to help NuShares holders manage their voting in an easier way. Instead of changing votes manually on your Nu wallet you can connect your wallet to use your own personal NuFeeder repository as a datafeed. Then you can use the NuFeeder GUI to manage the votes. You will be able to manage your NuShares voting from anywhere that you have access to a web browser. Since it uses github all of your voting history will be available through the commit history. This also makes it easier for users to become a data feed provider with minimal effort. NuFeeder runs entirely from github as a github page. It’s completely open source.


  1. Fork the NuFeeder repository to your own github account

  2. delete the file in the root of the repo. A push to the repo is required to trigger the github pages generation after it is forked. Deleting this file will trigger the page rendering. Only needs to be performed the first time.

  3. Check that a github page was created for the forked repo (sometimes can take a few minutes after forking) http://<YOUR-USERNAME>

  4. login to NuFeeder by entering your github account information.

  5. Set your votes and hit save to have them updated on github.

  6. Get the RAW url to the votes.json file that’s in the root of the reposity. It will look like

  7. Add this URL to your Nu wallet as a datafeed.

#Updating your branch with latest changes

for those that already forked it’s fairly simple to update with my repo. go to your repo page:<your-username>/NuFeeder

then add /compare/gh-pages...CoinGame:gh-pages to the end of the url:<your-username>/NuFeeder/compare/gh-pages...CoinGame:gh-pages

Click the “create pull request” button (give it a title if you need to) then just merge the pull request into your repo. That will update your gh-pages branch with my latest gh-pages branch. The voting data shouldn’t be affected, but you can see if it is in the pull request.

As I said above the application is still in an **alpha state**. The UI needs some improvements. Functionally it works okay for me. if you have any troubles, feedback, or questions leave an issue on the [github issues page](, or here.

Does the GUI show the names of grant proposal and motion?

No. It’s just the raw voting data. Though I have some ideas on how to add notes and other elements to the GUI.

Nice. I ll give it definitively a try

So if I use this tool, my voting configuration will be publicly available in any case?

Yeah. For now the only way to obscure yourself personally would be to create a dummy github account and use that.

Is it possible to use private Bitbucket repo?

I don’t think so. The way this works right now is by using what is called Github Page. It takes the source code of the repository and hosts it like a regular web server. So github is both hosting the application that creates a GUI to manage the datafeed, and it’s the datafeed itself. I don’t think bitbucket offers a service like that. I’m not sure how you would give the Nu wallet access to the voting data file if the repository was private

I’ve updated the usage instructions. You need to do a push to the repo in order for the github page to be generated after you fork the repo. So I’ve added a useless file to the root of the repo. When you delete this file after forking it will trigger the github page generation.

1 Like

It works well! Tks for creating such a tool.

  • park rates: how is “null” is interpreted by qt?
  • any plan to add a signature generator?
  • any plan to add “signature url” and “signature address” fields?
1 Like

For park rates do you mean null as in not adding the park rate at all? I believe it considers that a vote for 0.

I have not thought about the signature part yet, but if it can be added I will ad it.

EDIT: to add on I think there’s a number of improvements that need to be made before the signature. The UI needs to be cleaned up a bit. I want to allow the user to select between the same durations that are in the client (like 3 month, 6 month, etc) instead of having to enter in block numbers. Some back end stuff as well. Right now it requires having the vote file pre-structured with the correct voting structure, but it should have that memorized internally. Lots of little things. Glad the current state is working for you for now though.

It works well, good work!
What I like to see is a way to nicely display the current voting configuration with the links to the forums for anyone.
That way the content of the actual datafeed is easily accessible.

Edit: and same here the signatures is a must have for datafeed providers I believe

Ok so based on the few responses i’m starting to see a bit of a design change that I wasn’t thinking of originally.

I can make the main page like a “status” page which displays the current configuration for that users repo in a nice organized way. That way people can see the current voting without having to log in. I think that should be really easy and I can make it part of the next UI updates.

The part about linking back to the actual proposals is a bit more difficult . There’s a few ways to do it that I can think of off the top of my head. Have NuFeeder fetch from a curated list that has links associated to motions and custodial addresses. Then there’s trying to parse the data from somewhere. Third option is just adding a field next to custodial grants and motion in NuFeeder that allows to add an optional link and an optional comment.

Wherever the information gets pulled from I can then turn motion hashes and grant addresses into clickable links on the users NuFeeder status page.

The first one requires a person or some people to manage this repository of the associations between links and hashes/addresses. The second option I think is outright impossible because there’s not single place or uniform structure to pull this information from reliably. The third option is probably a lot easier. I would just create a separate file somewhere in the repository that stores the association between the voting data and the meta data. This would be stored separate from the vote file.

Am I missing some other easier way of implementing it? I would love for the link associations to happen automatically by pulling from some curated API like in the first option, as it would take the extra effort from users managing their feed in the third option. I’m not willing to say that I myself would commit to managing and updating such a listing. Maybe the third option is the most feasible?

1 Like

I would like to see that, hope I’m not alone in that.

I’m already doing the associations anyway in my datafeed thread for the items I’m adding to my feed. Instead of making the links in there I can make the links on Github in a designated field. One step further would be to have this accessible for any feed, but that would require a primary host and someone making sure any proposal is added. Happy to host it. The block explorer could also benefit from that.

The other option is pulling them from the Voting thread. We could structurise that a bit and then you could potentially scrape it.

Don’t know if this is easy to do but how about this -
somehow allow the proposal writer to generated a link to put in the proposal, such that when proposal reader clicks on it, a new page will open showing the reader’s NuFeeder’s page, with this proposal’s hash/amount and name added, and ready to be voted with one click. This basically gives an incentive for the writer to add the voting info (to the link) himherself because it brings convenience to the voter to vote yes.

Ok cool.

that’s possible I think. I can look into it.

I’ve made some updates to the repo. I fixed how it handles some things internally. There’s now some color coded alert messages that I will use to notify users of events. the “development” button works now. It will basically point changes to a branch on the repo called development. If you want to test things or make changes to the code without it impacting the actual gh-pages branch with your votes just click the development button. make sure you create a “development” branch first. Fixed some small layout bugs as well.

for those that already forked it’s fairly simple to update with my repo. go to your repo page:<your-username>/NuFeeder

then add /compare/gh-pages...CoinGame:gh-pages to the end of the url:<your-username>/NuFeeder/compare/gh-pages...CoinGame:gh-pages

Click the “create pull request” button (give it a title if you need to) then just merge the pull request into your repo. That will update your gh-pages branch with my latest gh-pages branch. The voting data shouldn’t be affected, but you can see if it is in the pull request.

Sorry I think I misunderstood your question, but I went to your repo and I see the issue. That’s a bug. If you accidentally left votes without data being entered it should discard those instead of creating entries with null values. For now just delete the empty entries from the GUI and save the results again. I’ll fix it in the future.

1 Like

Cannot merge. It says “This branch has conflicts that must be resolved
Only those with write access to this repository can merge pull requests.”

Also, [quote=“CoinGame, post:18, topic:3253”]
For now just delete the empty entries from the GUI

deleting (leaving a blankvalue for the fields I do not want to vote anything for) will put a null value…

Sorry I made a lot of changes yesterday that could have caused the issue. I think the structure needs to be organized better to handle people updating through github. I’m trying to make the process as simple as possible so that non-technical users don’t need to deal with git, but it’s a bit of a learning process in how to set things up correctly myself. For now the easier way might just be to copy the contents of your votes.json file, delete the entire repo, then fork it again and copy the data back into votes.json. Note that votes.json that moved to the _data folder.

I made some big changes yesterday. The biggest being that the application was restructured to use jekyll templating, which is what github uses to generate the pages. It makes things a bit more flexible. The second big change is that now the main page of the application is a “status” page which will show the current settings for the votes. You can click “edit” at the top to see the familiar login screen and vote editing functions.

The status page is still very ugly. I need to redo it, but it was good enough for my testing. I’m going to try and figure out a consistent way for uses to update their repo, or figure out what I’m doing that’s causing the merge errors. It could take some time though.

regarding the null issue… why are you leaving blank form items in the first place? Just delete those items. Items that don’t exist count as no votes with their default values set to 0. For instance delete all of the park rate inputs and those votes will be considered as setting park rates to 0. I will have the application automatically remove empty inputs when I get a chance.