Read permit URLs from DB #110
Comments
|
/assign |
Tips:
|
|
Awaiting ubiquity/ubiquibot#547 to merge. |
|
Do you have any updates @aditygrg2? If you would like to release the bounty back to the DevPool, please comment |
Perhaps it makes more sense to assign yourself to the task when you actually start the task. In the meantime it might be better for you to work on another task. |
|
/unassign |
|
@rndquu project url is needed too |
Updated the description |
|
Hi, I am here from alex's (pavlovcik's) podcase |
|
how should i do issue's? |
|
/help |
Available Commands
|
|
/wallet 0x3b07d616EC780b22148b190A07F3829A11B11042 |
+ Successfully registered wallet address |
|
@rndquu issues are spread out throughout many many repositories, is there a tool to check all the issues at once? |
|
|
/start |
Tips:
|
|
@rndquu Just wanted to clarify on this task to understand better: If so, I'd like to know what to use inside |
|
I think it might be more complex and involved to work on database related tasks because the schema is still in flux. I can share a snapshot but I already have ideas of how it will be changed again which makes the schema/database structure unstable. I'm not a super pro working with databases but if you have ideas on how to wrangle the situation in a fast moving development environment let me know. Otherwise it may be simpler to start with tasks that are not dependent on the database? |
|
@pavlovcik I am pretty familiar with Supabase, but I think this would be a discussion way beyond the scope of this issue. If the Supabase schema changes, that would indeed break all the projects relying on it. But if for each project the types are generated from reading the Supabase schema (Supabase comes with tools for that) at least it is very easy to spot the changes, since TypeScript will highlight the errors. Is there any value for |
|
That private key is the GitHub app private key to authenticate as the GitHub app (for example for commenting) In this case you should create your own GitHub app and then use its private key so that you can authenticate as your own app. Also I think the property name is deprecated I think we changed it just to |
|
@FernandVEYRIER
TBH I've totally forgotten the context of the current issue. As far as I remember, right now the bot generates permit URLs (example) and passes base64 encoded permit params in the
You may use this script. It a little bit obsolete but it was fixed by @barebind in one of his PRs so you may take this updated version. Current issue may refer to the https://pay.ubq.fi/audit page which does (as far as I remember) read permits from github comments so it makes sense to read permit URLs from DB in that page. |
|
After digging into this for a while, got a few questions: The current shape of a payment entry in the Supabase db looks like (hex shortened for clarity) {
"id": 1,
"created_at": "2023-08-10T13:06:13.238+00:00",
"organization_id": 76412717,
"repository_id": 534616569,
"issue_id": 1843851788,
"network_id": 100,
"bounty_hunter_id": 4975670,
"bounty_hunter_address": "0xfff",
"token_address": "0xfff",
"payout_amount": "56250000000000000000",
"nonce": "44018718530163796483577731670361750520301523549581891070913854055733144704107",
"deadline": "115792089237316195423570985008687907853269984665640564039457584007913129639935",
"signature": "0xfff",
"wallet_owner_address": "0xfff"
}First question is, what does the Same goes for Finally, in the UI there is a |
|
GitHub has globally unique issue IDs, and user IDs, which do not correspond to the issue number that you describe, or their username. We don't use the username because contributors can change them easily (we have also seen this in real world testing which has broken systems) When a permit is claimed from the pay.ubq.fi "claims" interface, a blockchain transaction is created. I want the claims UI to write to the database when the contributor invokes the claim so that we can keep track of 1. which ones are claimed and 2. The actual claim transaction for proof (in real world testing some contributors would complain that "somebody took their money" and I had to manually dig up their transaction to prove that it's impossible that somebody else took their money) |
|
Righty, but how do I use these IDs to look the issues / users up? The GitHub API doesn't seem to find anything when using these ids for querying. Edit: |
|
I am planning to replace the This will solve the problem you're talking about. |
|
Indeed would be very helpful. Is it not usable right now? |
|
The database is "usable" its just not integrated into all of our systems yet. As I mentioned earlier in other threads, the database schema is still a bit in flux. But I am confident that the rest of the changes will be even smaller than this URL bit that I proposed. I already personally laid out the main groundwork based on what I anticipate the system to be able to achieve in 2024 (including XP leveling etc.) However I am starting to wonder if it makes more sense to associate a database (or table) PER plugin. Perhaps that can allow for faster development? We can also consider bundling in some shared "global" databases in a To keep our infrastructure as simple as possible, I am also very keen on using GitHub for storage. We have experimented with this by embedding metadata inside of bot comments in the form of an HTML commented out
|
|
/assign |
Try using /start |
|
/start |
Tips:
|
Thank you it worked. Any reason why ubiquibot would remove assignment like this? |
The feature seems to be partially broken, but in the past, based on two values in our configuration, it would
This was extremely useful when we had a lot of would-be contributors self assigning a ton of tasks and then not actually completing them. So the bot would unassign them and free up the tasks for others to try. |
|
@pavlovcik This might have broken the process of Ubiquibot, which I believe should have closed the issue now isn't it? |
|
That's a GitHub issue actually. GitHub automatically should close as complete when an associated pull is merged. Not sure what happened here. |
+ Evaluating results. Please wait... |
If relevance was working as expected I would have received far less rewards. Will need to push a fix soon. |
|
@pavlovcik @FernandVEYRIER the deadline is at 2024-03-20T04:38:35.356Z |
# These linked pull requests are closed: <a href="https://github.com/ubiquity/pay.ubq.fi/pull/164">#164</a> |
Depends on ubiquity/ubiquibot#547
When ubiquity/ubiquibot#547 is implemented we should read permits from a DB instead of parsing github comments.
What should be done:
Supabase public/anon key which can be safely used in the frontend:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6Iml5eWJoaGlmbHdic2pvcHNnYW93Iiwicm9sZSI6ImFub24iLCJpYXQiOjE2ODUxMTA1MTMsImV4cCI6MjAwMDY4NjUxM30.R_c29S9xFbZmqHxi4HTdhP8uqHt2v6DnUSCEAxBeTTMSupabase project URL:
https://iyybhhiflwbsjopsgaow.supabase.coThe text was updated successfully, but these errors were encountered: