Data feed mixing

Development Wallet Interface
#1

Continuing the discussion from Cybnate’s datafeed - BETA:

It makes sense but maybe it’s something to build outside the client. Either having another software downloading these feeds and merging them, or a service provider that would give you an interface to build your own data feed from special rules.

Or do you think it’s better to have this complex interface in the official client? That would be a lot of work to handle all the use cases.

#2

I think it would be nice if the official client could provide an option to extend the local selection of votes instead of replacing them completely. Besides that I agree that complex data feed combinations shouldn’t be part of the default wallet.

Regarding the data feeds I would love to see recursion, i.e. that each value in the votes either corresponds to the hash of the corresponding vote or to a link to another data feed (maybe with signature). In the latter case the linked data feed will be loaded in order to fill the required hash value. Loops can be tackled by specifying a maximal recursion depth. This would allow very powerful combinations patterns.

#3

I agree with @sigmike’s concerns of the complexity, and I strongly supported keeping the data feed system within the client very simple during development.There’s huge opportunity for developers to create software that enhances the mixing or choice of votes before they enter the client. This is actually an area that doesn’t even need the wallet to be open sourced which is convenient.

It’s much more prudent for the development efforts of vote selection/mixing to happen outside of the client. Whether it’s from a local application, a web service, or even a simple script.

To add to this, how would such a filtering process be handled by the daemon? I think most people in the future would like to have a NuBox running the daemon that handles their minting and votes.

1 Like
#4

We shouldn’t have the mixing complexity in the client. The three different ‘parts’ custodians, park rates and motion is good enough indeed.

I do wonder about how much mixing would be useful regarding to the effort off tailoring it to your needs. Motions and proposals are dynamic and views will change all the time, so you will spend time on keeping up on datafeeds. When you have strong views on topics you should probably maintain your own feed or just set your voting manually based on your own thoughts.

I think a datafeed such as I propose here is focussed on three groups:

  1. New Shareholders who do like to contribute but are still developing their own views. They would default to one of the popular data-feeds and learn their way around till they have developed their own views.
  2. Speculators who also like to mint and don’t want to ‘hurt’ the network with ‘null’ votes, but don’t care so much that they are developing their own views and are prepared to vote with the majority most of the time.
  3. Long-term shareholders who trust/delegate a person or a small group of person to take care of their voting while their shares are minting quietly on a Raspberry (with Peerbox eventually) somewhere in a hidden corner of a place under their control.

I’m considering setting up 2 or more datafeeds to cater for all three groups, but hopefully others will also initiate datafeeds. I’m also keen to hear if the non-techies amongst us like to have their own datafeed hosted on my Github.

Edit: I do see a case where you tag some existing votes as persistent in the client so they can’t be overwritten by the data-feed. People may feel strong about a certain motion even if it was only their own, but still like to vote for the others according to the subscribed data-feed. It occurs to me that this is not easy to implement, but the devs can probably better comment on that.

#5

It had been my intention to augment the data feed functionality, probably in version 0.5.4. It is my understanding that accommodating the use of multiple data feeds is feasible with a reasonable amount of development effort.

As our network develops, I envision specialization in data feeds occurring. Doing a really good job of recommending park rates, for instance, may eventually involve complex custom software. It could be a full time job. A person or group that does a very good job of recommending park rates may know little about custodians or motions. Therefore, I believe allowing users to subscribe to multiple data feeds is useful.

Here is a mockup of the functionality I would like to see implemented for data feeds:

The gray box is a tool tip. Radio button groups are defined by the columns.

@sigmike, what is a very rough estimate of the amount of time it would take to implement this?

I encourage comments on this proposal, particularly from those who have expressed a different vision of how to implement data feeds.

Edit: If a user tries to remove a data feed that is currently selected for use, they should receive a message that they must select an alternative before they can remove it. That way, the software doesn’t have to guess what the user would like done for a particular category of data feeds.

5 Likes
FLOT compensation discussion
#6

I think there is also value in functionality where users can retain a specific vote (for a motion or grant) even when subscribed on a particular datafeed covering this. The use case is that when a user has a particular view about one key motion (might be their own) but is still happy to vote for all the others being offered by the datafeed.

Visually you could solve this by adding tick boxes in the motion or custodial grant windows. Ticked motions won’t be overwritten by the feed, but can only be removed or unticked.

2 Likes
#7

Yes the last two post would already make the usage of datafeeds very comfortable. [For developers it might also be nice to implement a “votenotify” callback command that executes a predefined script when the voting has changed (similar to walletnotify).]

EDIT: This can already be achieved with blocknotify, so no need to implement it.

#8

votenotify already exists. :slight_smile:

Check the bottom of the documentation

#9

Oh didn’t read that, thats’ great! Thank you.

#10

This is actually a good implementation. It’s still very simple but offers some flexibility to the feed selection. Would this be a GUI only feature? I’m having a hard time seeing a way for it to work without being tedious from the command line. Subscribing to a feed that has votes pre-mixed would still be easier. Though it would still be a boost for GUI users.

#11

I see a possible for a web-app : feedmix.nu :wink:

#12

A dynamic UI like this is time consuming and difficult to estimate. I’d say a few days of work. The process that downloads the data feeds would need some updates too.

We could have an adddatafeed command that would work like setdatafeed except it would keep the already existing data feeds, and just change which one is used for which votes, depending on the flags you provide.

Another option is to use JSON to describe all the data feeds and you’d reset all your data feed settings like you do with setvote.

1 Like