Combine unclaimed permits tool

[rndquu]

Depends on #136, ubiquity/ubiquibot#644

Original discussion

Right now we support payment permits only in a single token (example). When ubiquity/ubiquibot#769 and #136 are implemented the pay.ubq.fi page will start accepting an array of permits (for payouts in multiple tokens).

It is not very convenient for a bounty hunter to find all of his unclaimed permits (issue solver rewards, issue creator rewards, comment rewards, etc...). We should create a tool that finds all of bounty hunter's unclaimed permits and generates a new permit URL which combines all of the bounty hunter's unclaimed permits.

What should be done:

• Add a new web page pay.ubq.fi/combine-rewards where a bounty hunter will be able to authorize via github and get a single URL of all of his unclaimed permits.

Notice that you can get all generated permits directly from a DB using the supabase anon key (ask for it when you start the current issue).

[0x4007]

Spent yesterday designing a new database schema which will also indicate if the permit is claimed (or invalidated) which is useful context for you to know

ubiquity/ubiquibot#787 (comment)

[b4s36t4]

Is this available to pick?!

[rndquu]

Is this available to pick?!

Not yet, depends on #136

[0x4007]

Sorry for the slow communication on architecture updates @rndquu

However, my new database architecture solves this pretty easily because 1. it'll be storing all of the permits and 2. it has a column for transaction

The significance of the transaction column is that when the permit is claimed or invalidated, the dApp can save the transaction to the database, making it very quick to see which are still available to claim.

Lastly, each permit is associated with a GitHub user ID with the beneficiary_id foreign key.

This should make it pretty easy to directly query for all available permits for a specific user.

Ref: ubiquity/ubiquibot#644

[rndquu]

This should make it pretty easy to directly query for all available permits for a specific user.

Updated description

The significance of the transaction column is that when the permit is claimed or invalidated, the dApp can save the transaction to the database

I think it is better to make the bot responsible for all write operations to a DB (i.e. the bot could search for payout transactions and match them with permits). Basically we're going to have a DB shared by 2 apps (bot and pay.ubq.fi). If both of them write to a DB then it is pretty hard to debug the changes. But if pay.ubq.fi solely reads from a DB without any write operations then it makes the development easier.

[0x4007]

But if pay.ubq.fi solely reads from a DB without any write operations then it makes the development easier.

In theory I agree, but I think its worth focusing the cost-benefits of this trade-off.

Costs

• two apps writing to the database, which can make root issue analysis more burdensome.

Benefits

• Zero wait time for users to understand:
  1. exact claim transactions
     • there's been at least five instances where people complained to me about their permits being "claimed by somebody else" and I had to manually dig up the transaction to show them that they indeed claimed it
  2. total amount of pending claims
     • so that payroll for the entire previous time interval e.g. week of work can be claimed in less than a few minutes.

Conclusions

Perhaps this is a slippery slope, which is what I'm crediting your point mostly for; but at least at this stage it is only a single column transaction in the permits table that is being potentially modified by the Ubiquity Rewards interface. This column should not be modified by UbiquiBot. This can be potentially enforced with delegated permissions to each app, and with RLS (row level security.)

[0x4007]

Question on invalidation #136 (comment)

[rndquu]

Question on invalidation #136 (comment)

Current issue seems to be irrelevant because the latest bot's version supports rolled-up permits.

Regarding the invalidation, I don't think we will make bounty hunter to invalidate anything. It is simpler to create a script to invalidate all unclaimed permits in a single multicall tx.

[0x4007]

So then for this flow to work, the bot needs to:

1. Multicall invalidate
2. Wait and confirm that the invalidation transaction was successful
3. Generate and present the rolled up permit on the pay.ubq.fi interface.

Also for accounting in the background:

4. Add to the database "debits" for every invalidated permit to the contributor's balance
5. Add to the database "credit" which corresponds to the rolled up permit.

---

Current issue seems to be irrelevant

So we should close as unplanned?