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?

[rndquu]

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.

I thought it should be a script that we run only once.

So we should close as unplanned?

Yes

[ubiquibot]

# Issue was not closed as completed. Skipping.

[0x4007]

I thought it should be a script that we run only once.

Any time a user wants to roll up their outstanding permits. I think the best user experience would be that the user can log on to pay.ubq.fi at any time and click a single button which collects all of the rewards that is owed to them. Behind the scenes it would do all this, for example.

[rndquu]

I thought it should be a script that we run only once.

Any time a user wants to roll up their outstanding permits. I think the best user experience would be that the user can log on to pay.ubq.fi at any time and click a single button which collects all of the rewards that is owed to them. Behind the scenes it would do all this, for example.

The latest bot's release posts payment permits as it used to post (i.e. directly in github comments, 1 solved issue = 1 payment permit), right?

I think we should get back to the "pay.ubq.fi payout interface" when we're done with taiko's NFT rewards because:

1. It is not clear how to handle NFT rewards in a single payout interface (i.e. pay.ubq.fi)
2. We may not be on time with taiko's NFT rewards feature if we start moving to a single payout interface right now

[0x4007]

It is not clear how to handle NFT rewards in a single payout interface (i.e. pay.ubq.fi)

• @whilefoo already implemented it NFT mints #146

[rndquu]

It is not clear how to handle NFT rewards in a single payout interface (i.e. pay.ubq.fi)

• @whilefoo already implemented it NFT mints #146

I meant the case when we have only pay.ubq.fi for payouts. When user:

1. Opens pay.ubq.fi
2. Sees his rolled-up rewards
3. Sees all of available NFT permits

Getting rewards info require access to a DB (i.e. via supabase's anon key) so I meant that we will have to redo the pay.ubq.fi interface even if it already supports permits both for ERC-20 and ERC-721 tokens.

[0x4007]

Perhaps you can file a new issue for this?

[rndquu]

Perhaps you can file a new issue for this?

I'll create one once we decide on a virtual cards API provider because this all looks like a new task for a single payout interface.

[0x4007]

Perhaps you can file a new issue for this?

I'll create one once we decide on a virtual cards API provider because this all looks like a new task for a single payout interface.

Just reviewing all my unresolved old notifications. Any update here?

[rndquu]

Perhaps you can file a new issue for this?

I'll create one once we decide on a virtual cards API provider because this all looks like a new task for a single payout interface.

Just reviewing all my unresolved old notifications. Any update here?

Not yet, I need ~2 more days for stripe research