Allow a different format for votes in 'bridge' API response

@rishi556 @good-karma @dan feel free to comment on this one and share your opinions :)

The new possible format with an optional param which lets you define what you get might be the best(rshares, percent, or both) with it defaulting to the current behavior without it to not break anything current. Should give devs the most amount of flexibility on what they need to display.

Would be great to remove this field altogether as it is increasing payload and add flag indicating vote information about observer. Plus extra: #133 (comment 43665)

This array mostly used because it is the only info about vote but really inefficient one, most dapps already use get_active_votes with popup click, so we can remove and add observer indicator instead.

I'm ok with something like this but not if we only include the observer. There are infinite use cases for apps interested in retrieving voting details for multiple accounts. Mostly as I've added here (#133 (comment 43687)) I would like to at least specify an array of observer accounts. So we can get the total count and only the vote details from account we really need.

My concern with array of observer accounts, is complexity it involves with changing multiple endpoints/apis. Step by step approach is better, first make active_votes: [] empty or better yet, only include observer vote information with everything (perc, rshares, etc.) and in 2nd iteration make observer field array, not only for get_ranked_posts/get_account_posts but for every endpoint that utilise observer. Similar working reblogs field would be super great addition reblogs: []

Could you specify the use case of array of observers? Most APIs that can use observer have completely separate queries for cases where observer is present and when it is not - the observer being single account is very much hardcoded in there. They also make sense when there is single observer as it reflects the reality of a person being logged and reading an article, but what would it mean to have multiple observers?

condenser_api.get_active_votes is very bad - it has no paging nor limit capability (it has hardcoded limit - exceeding votes are never included in response). We should either extend it or database_api.list_votes with by_comment_voter order should be used instead.

In this ticket I only suggest to change from rshares to perc as I think it's more useful for frontends (and reduce payload).

The case for the observer array is better explained in the other ticket. There are situation where it's important to get not only the vote of the observer but also other accounts. For example for comments on a post I want to know the vote of the current logged in user, but also if the post author upvoted/downvoted some comments. And there are other useful use case too.

changed the description

mentioned in issue #133

As a side note, new vote which results in rshares == 0 counts in hived as downvote (see https://gitlab.syncad.com/hive/hive/-/blob/develop/libraries/chain/hive_evaluator.cpp#L2112 ). I'm not sure if it matters though, since hivemind counts it as "no vote" ( https://gitlab.syncad.com/hive/hivemind/-/blob/develop/hive/db/sql_scripts/update_posts_rshares.sql#L28 ) and that's what most frontends will use as source of data. As you can see neither treats it as upvote based on weight.

Well ...if you ask me this is very bad. New users with very few HP should be able to vote and their vote should be counted based on the weight, not the resulting rshares. It's just too confusing for a new user to click the vote button and see his vote 'disappear' because it's not powerful enough to be considered an upvote. Even worse if you consider it a downvote.

Just adding vote_percent (I stand corrected - I thought weight will reflect up/downvote *) to active_votes might address this issue, however in the same time it will make #133 far worse, so I think we need to fix both problems at once.

Instead of removing active_votes, we could fill it with only vote of observer (and we won't need much change if we ever decide to support array of observers). This way we have at most one vote per post (fixes #133) and it won't matter if we add extra information to it (fixes this issue). The existing tools won't be crashing as it might have happened in case we removed active_votes - they will just present incorrect data about votes until they are updated. It gives us some leeway to make necessary changes in frontends. We will of course need to add new vote statistics, so frontends have something to use in order to present correct vote data. Since stats post field already contains total_votes (number of effective votes - those cast before payout) I propose we add all needed information there as well. We just need to compile the list of new fields. Looking at different sites using @ura-soul/justin-sun-conversation-with-witnesses-is-online-ned-sold-out-the-community-failed-to-disclose as example I see the following vote information presented upfront (without the need for user to click on anything):

peakd seems to show number of effective upvotes and downvotes (it looks like it filters out the ones with rshares == 0)
hive.blog shows total_votes already present in stats
ecency shows number of all votes (effective or not)
worst case is with hiveblocks as it shows a list of voters - that is something it will need to either hide, or ask for with separate vote specific call

Anything else that might be needed here?

(*) update: I finally know the source of confusion - the weight in vote_operation translates to vote_percent in comment_vote_object (and in API), but it also contains weight that, while somewhat related, actually means something different.

Thanks for sharing this detailed explanation. I agree almost on all your points, only if possible I would like to have the 'array of observers' right from the beginning. Maybe we can just use a comma separated list and not a real array to make it compatible with the current API request format.

Because I fear we'll never come back to implement the array of observers if we don't do it now.

PS: peakd filters rshares == 0 because it's interpreted as a 'removed' vote. In the next update I'll change this behavior.

I understand your concern regarding array of observers never coming to fruition, they are certainly not baseless. However it is not because of some strong opposition to make such change. That's why my proposition takes into account such future possibility. The problem still should have separate issue where you could describe reasoning behind such change, what "user realities" you want to express with many observers as well as address the various aspects of API calls with multiple observers such as:

blacklists
mute lists
community context (see f.e. bridge.get_community/bridge.list_communities but more importantly bridge.get_ranked_posts with my tag)
follow context (see f.e. bridge.get_profile)

Surely we don't need to allow array of observers in every call that now allows single observer, but it needs to be specified where we do and where we don't. Also when you look for observer in the hivemind code you'll see how many queries will need to be adjusted for such change (and each will need new tests that use multiple observers - at least one per situation+call params, f.e. testing blacklists for single call with single combination of params needs test for when both observers have some author on blacklist, just one of them, both or none) - it is not five minutes of work :o)

I fully agree. And this is why I fear it will never be implemented :D

mentioned in issue tasks_without_projects_yet#38

Allow a different format for votes in 'bridge' API response

Designs

Child items ...

Activity