Instant Boost

[GriffGreen]

Given the situation in turkey... it would be awesome if GIV holders could impact the rankings in real time....

Would love to prioritize this!

[laurenluz]

We can make default sort according to the amount of GIVpower that is on each project at that moment, and have it update pretty regularly (maybe we do it to update every boost?)

We should change the name of "sort by" from "rank" to "GIVpower"... so default sort is by GIVpower.

This would actually encourage more people to use GIVpower for the immediate impact... however, the "rank" number should not change, as this affects GIVbacks.

cc @aminlatifi

[laurenluz]

To solve the issue regarding Turkey projects, we decided on a quick fix via Giveth/giveth-dapps-v2#2155

However, this feature would be really nice for making more demand for GIV - by making the impact on sorting more immediate. We should figure out the best way to do it - @aminlatifi is thinking about it :)

cc @MoeNick

[aminlatifi]

I think one of these options may fulfill the requirements of immediate rank change

1. Single frequent update snapshot: We can implement a separate table containing snapshots of percentages and users' GIVpower balance, and make a ranking based on it. It will be separate from all other tables we have used for calculating power boosting ranking till now but will mostly have a similar mechanism. This data cannot be updated so frequently because on each snapshot we must fetch all users' balances from the subgraph. So we may be able to update it every 10 minutes. Nevertheless, will need less development effort.
2. Instant Ranking: We keep an updated users balance in some table and keep it updated by just fetching updated balances. Then we can recalculate the powers so often, maybe every few minutes. It needs continuously fetching the updates of the balances change, using either JRPC or by the help of a subgraph. For that purpose we may need some development on the subgraph

[MoeNick]

I'd love to have an estimation and risks for all those options/

[laurenluz]

Well, in order for this to have the impact desired, it would need to update "instantly" (or at least every few minutes).

let's talk about option 2 in the GIVeconomy call today and see if people think it's a good idea to implement.

[laurenluz]

Notes from GIVeconomy call:

• mitch: project page is slow/bulky to load, will this change make it worse?
• griff: use case of GIV is to control the platform - giving people that power is high demand. if this was implemented, people could have bought/used a lot of GIV to move projects up.
• moenick: if we want to make it simple, we can add another sort option called "instant GIVpower", rather than rank. need more user research
• griff: people don't care about GIVbacks, as much as they care about the project sorting.
• lauren: can get more user feedback in the givpower workshop today
• amin: project page won't load slower with the instant ranking impementation, this would be offline. adds complexity to backend.
• Rod: people don't want to have to come back after donating... could have option for GIVpower to auto-back a project.

[laurenluz]

Some notes from the GIVeconomy call:

• Currently snapshot gets value from the network every 4 hrs, so impact graph won’t have the correct GIVpower balance for users except for once every 4 hrs 👀
• We would need to add a moduel to monitor the network and have the updated balance for everyone
• If we have this, we would need to update the net table
• We might be able to make it work for each user on their particular screen, then have it update after 4 hrs for every user
• Could we make the snapshots every 30 min? increase them? 15 min?
• We could be blocked by impact graph - backend would be querying the subgraph a lot… subgraph has a limit on queries for each IP address
• On operation side, we can change the duration, but we’d need to make sure we wouldn’t be blocked by 3rd party services
• If we use this snapshot for the project sorting, we don’t necessarily have to use it for GIVbacks (we could still do GIVbacks based on every 4 hrs)

@aminlatifi - can you do a little research?

[laurenluz]

• Amin chatted w/ subgraph guys to see if it's possible to get info faster
• We can change subgraph to only save changes - every 5 min we fetch the changes to the balances
• Otherwise, we can make it so that all of giveth has higher rate limit so giveth is source query
• Every 5 min we could have the sorting update
• we can make a frontend hack to have the individual to see the change immediately. Cherik things it would become buggy.

@MohammadPCh to investigate if it's possible. project sort would change on frontend, then change after based on backend.

[MohammadPCh]

@laurenluz I investigated it, It's possible, but it's making our code messy, hard to understand, and hard to maintain. and we need to get some new data from the backend. also, since we need more requests and calculations to calculate new rankings in the front end, makes our projects page slower. Besides that, we have problems that don't have a clean solution, like the pagination part. consider we fetch 10 projects from the backend and calculate their new ranks, and found out that one of our projects move down to rank 20. so we need to show only 9 projects and take care to show it when we want to show 20 first projects. So, yes it's possible, but I think it's only worth implementing if we're sure it will create a lot of value for the user.

[laurenluz]

@MohammadPCh - thanks for looking into it. that really sounds like a mess to me 😅 if it were up to me, I think we should skip it in that case, but I will check in as well with @GriffGreen since he felt very strongly about this idea.

[GriffGreen]

Hmmmmm This is an important feature.

What features are we prioritizing over it?

How edge case are these pagination issues?

Is there another more fundamental change that we can do that would make this feature cleaner?

I heard there was something about the graph updating every 5 minutes and it would be ok?

[aminlatifi]

Hmmmmm This is an important feature.

What features are we prioritizing over it?

How edge case are these pagination issues?

Is there another more fundamental change that we can do that would make this feature cleaner?

I heard there was something about the graph updating every 5 minutes and it would be ok?

Updating the graph design is part of enabling the backend to update ranks faster, aiming for every 5 minutes. But immediate rank update in the user interface is something that needs some backend support and complicated frontend implementation.

[laurenluz]

@GriffGreen you said before that if there is no "immediate" effect, then it's not worth doing. is that still the case?

As Amin said, the only way to make the sorting update immediately is by doing this complicated frontend implementation (with additional backend support) that Cherik said would be a mess.

If we want the resorting to happen every 5 min, I do think it's possible with the graph. Are you happy w/ having sorting update every 5 min?

[laurenluz]

@MoeNick can work with @mosaeedi on design to tell the user that the project sorting will change within 5 min.

@GriffGreen is happy w/ this solution.

@aminlatifi can work on the backend implementation

[laurenluz]

To clear up confusion around this issue, I made a mini-spec for it: https://www.notion.so/giveth/Instant-Boost-Mini-Spec-cea340e1bbf2456f8c7b237c07e5f8aa

Hopefully that helps.