Add multiple pools as argument of the pool_votes API

[DevStakePool]

Is your feature request related to a problem? Please describe.
Hi! It would be great if this query would take a list of pools instead of one in the API call
https://api.koios.rest/#get-/pool_votes
Maybe make it a POST instead of GET.

This would avoid spamming the endpoint to get the votes of several pools

Describe the solution you'd like
Once the argument can take an array of pools, the response should also include the pool-id to identify the various vote object
This solution would be very similar to the /pool_info API call

Describe alternatives you've considered

• None

Additional context

• None

[rdlrt]

Could you mention the use-case you're trying to address where single call is more beneficial for bulk query of pool votes?

Are you traversing all pools that have voted for a proposal? The only case above makes sense if yilou want to query multiple pools for every proposal made historically, which does not sound like something that'd fit in a single UI.

When using pool_info as a comparison, there are legit cases where you may want to display multiple pool's info on a single page.

We just need to be a bit defensive to have bulk calls based on popular use-cases, as it can become difficult to reverse if folks end up [mis-]using a heavier call for finding votes against a proposal (which is tended to by proposals_votes endpoint)

[AlessioDiFazio]

Hi,
in my scenario I have a set of pools (let's say 100) and I'm trying to capture new votes (any new vote) based on a block hight. This is needed to notify users when a pool of one of their wallet has voted the XYZ proposal and what they voted.

[MadOrkestra]

Just saw this. I have a similar use case: "live" tracking of most recent governance votes, be it from pools, committee members or dReps for the same reason: letting delegators know their dRep or Pool just voted. To achieve this on scale, you'd have to hit a lot of endpoints regularly.

Maybe instead of adding bulk queries to each votes endpoint individually there could be something like a /votes_history endpoint showing all governance votes from newest to oldest outputting block_time, proposal_id, voter_id (pool_id, drep_id, cc_hot_id) and their respective vote which then could be easily queried in a cronjob using block_time and selection over the voter_id or a specific proposal?

Just my 2 lovelace.

[MadOrkestra]

Actually, there is an endpoint already achieving my proposed solution half way: /proposal_votes (thanks to @hodlonaut for pointing this out)

You could set the _proposal_id to optional and return all votes on all proposals if _proposal_id is not specified (similar to history endpoints where epoch_no is optional)

And ofc add _proposal_id to the output, so you can distinguish between proposals.

The question is if this resolves @DevStakePool problem, because if you have to filter this query for 100 different pools and a proposal_id, you'd probably see a really slow endpoint. But then again, caching this regularly into your own db would be quite easy and performant.

[DevStakePool]

That's a nice suggestion! I'll investigate it.
I could use the /proposal_list filtering by expired epoch (only the active ones) and then for each proposal I could query the proposal_votes, and maybe using the block_time I could get the "new" ones, keeping in my DB track of proposal + block_time + voter_id to avoid grabbing the same vote twice. It's a bit of work and quite a lot of end-point to hit. Maybe something could be improved as you suggested