Keyrxng commented 6 months ago

Resolves #45

A basic ass leaderboard
shows earnings to date
shows date they joined (according to supabase)
shows meta-info panel

QA

https://github.com/ubiquity/work.ubq.fi/assets/106303466/33e4d517-45c8-44b1-b072-dcda5295f29b

Keyrxng commented 6 months ago

I was going to suggest a UI feature of sorts incorporating the output as an input:username > unspent permits w/ url sort of thing but no probs was my pleasure

Please feel free to make a proposal under the appropriate repository.

@0x4007 remember this from when I authored the CLI? Is this still something that you'd be interested in seeing? It would work much like this PR, pull CSV/JSON from up-to-date source and allow a simple address aggregation search?

I saw it in TG but not sure if it happened, but a script to populate the current permitDB with all previous permits using the cli and then the source could just be supabase for individual users searching for their own unspent permits

I've been using the CLI personally to grab my unspent permits after leaving gathering a couple up if I can 🤣

ubiquity-os-deployer[bot] commented 6 months ago

cb0af44

e3969ea

Keyrxng commented 6 months ago

two things:

The preview deployment login is redirecting to the live deployment meaning you can't effectively sign in via github into the preview url and the leaderboard uses GH api to grab the source CSV and Supabase for (all) usernames, date created etc unless cached, so that's a trouble.

Seems there's a DB schema mismatch looking at the logs.

What is the users and wallets table supposed to look like at the moment, or where can I find the most update to date db stuff? I used queries from old ubiquibot repo I'm sure, old saved queries anyway

Keyrxng commented 6 months ago

wallets = id | address | created | updated users = id | wallet_id

where wallet_id is just an auto-incrementing ID and user.id is their GH id right?

Keyrxng commented 6 months ago

Pulling from DB successfully now but I expect that the GitHub auth on the preview deployment still will not log you in which you'd need to be otherwise you get rate limited

0x4007 commented 6 months ago

This should be on a separate page. It clutters the UI for searching for new work.

Also the numbers don't look right. I'm pretty sure the core team members collected more that what is shown on your screenshot.

Otherwise pretty interesting feature!

Keyrxng commented 6 months ago

This should be on a separate page. It clutters the UI for searching for new work.

So leaderboard button should push to a new page completely i.e /leaderboard and not just remove and replace the bounties? On page load the leaderboard is not shown until clicked and it's a psuedo-nav by just removing the taskContainer and filling it with leaderboard entries.

Should the leaderboard button be up-top or should it join the "help" button down-low?

Also the numbers don't look right.

I was thinking how can I be sitting up there with the big boys myself lmao, but the CLI is only parsing permits from comments posted by either yourself or the bot, not manual payments. I'll need to check if it's checking the new Ubiquibot org for permits too

rndquu commented 5 months ago

@Keyrxng What supabase instance did you use for testing?

I'm getting an empty leadeerboard without any errors when I'm trying the following credentials which are used for the pavlovcik's supabase instance which is currently used for production (@gentlementlegen pls correct me if I'm wrong):

SUPABASE_URL=https://wfzpewmlyiozupulbuur.supabase.co
SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6IndmenBld21seWlvenVwdWxidXVyIiwicm9sZSI6ImFub24iLCJpYXQiOjE2OTU2NzQzMzksImV4cCI6MjAxMTI1MDMzOX0.SKIL3Q0NOBaMehH0ekFspwgcu3afp3Dl9EDzPqs1nKs

Keyrxng commented 5 months ago

That's the one I used.

I'll add a loader/toaster. You need to be signed in with GitHub, open the leaderboard and wait and it will populate. It'll store the info in localStorage so that the next load is instant. I implemented a naïve refresh/update but it'll be better after https://github.com/ubiquity/.github/pull/107 and the subsequent workflow to run every 1-3days? and then we just update the cache if it's beyond whatever the timeframe for the workflow is since the last update.

I'm just after trying it again myself.

rndquu commented 5 months ago

I'll add a loader/toaster

Yes, pls add a loader. I cleared the local storage and then everything worked fine.

Keyrxng commented 5 months ago

Since this depends on the CLI and an update to the workflows, should I aim to clear those up first and then see this through? Because this is currently pulling static leaderboard data from my repo

rndquu commented 5 months ago

@Keyrxng Questions:

This PR reads permits only from supabase, right? I mean this PR doesn't check all_repos_contributors (introduced in https://github.com/ubiquity/.github/pull/107) or anything related.
This PR simply parses multiple orgs and is not really a requirement for the leaderboard to work properly since all permits are read from supabase, right?
This issue implies implementing a workflow that runs on a schedule and updates all_repos_contributors.csv file, right?

Keyrxng commented 5 months ago

The permits table only has 10 permits in it as far as I can tell, I just pulled and logged to find out. This PR uses Supabase for Wallet > Username tracking.

https://github.com/ubiquity/.github/pull/107 updates the CLI which this PR uses the output for payout history.
https://github.com/ubiquity/.github/issues/108 right, this updates the CLI workflow situation so the leaderboard data all_repos...csv is up-to date

A better idea might be to open a task and have the payout history that the CLI is able to pull and pipe that into the current Permits table then as you say this PR could simply read from DB for the data instead.

rndquu commented 5 months ago

The permits table only has 10 permits in it as far as I can tell, I just pulled and logged to find out. This PR uses Supabase for Wallet > Username tracking.

Parse multiple orgs for payments .github#107 updates the CLI which this PR uses the output for payout history.

Implement leaderboard workflow .github#108 right, this updates the CLI workflow situation so the leaderboard data all_repos...csv is up-to date

A better idea might be to open a task and have the payout history that the CLI is able to pull and pipe that into the current Permits table then as you say this PR could simply read from DB for the data instead.

So the plan is:

Refactor this PR to read permit data only from a DB
Create a new issue for https://github.com/ubiquity/.github/tree/main/airdrop-cli to implement a script that will: a) Collect permit data across ubiquity and ubiquibot orgs b) Insert this data in the permits table (idempotently)
Close https://github.com/ubiquity/.github/issues/108 as not planned since all permits will reside in a DB

Correct?

Keyrxng commented 5 months ago

Yes this sounds good to me @rndquu

0x4007 commented 5 months ago

Can you instead make a new repo for this? Just fork the code and make a separate page and remove all the complex logic around displaying GitHub issues.

It really doesn't make sense to me to make work.ubq.fi handle leaderboards, but I understand why you did it (the rows are a useful structure to display the leaderboard.)

If you create leaderboard.ubq.fi repo, my cloudflare worker should automatically map it to the domain.

Keyrxng commented 5 months ago

If you create leaderboard.ubq.fi repo

I assume you mean @rndquu here, once the repo is created if you could ping me and I'll jump on it rndquu

rndquu commented 5 months ago

If you create leaderboard.ubq.fi repo

I assume you mean @rndquu here, once the repo is created if you could ping me and I'll jump on it rndquu

@Keyrxng https://github.com/ubiquity/leaderboard.ubq.fi

0x4007 commented 5 months ago

If you create leaderboard.ubq.fi repo

I assume you mean @rndquu here, once the repo is created if you could ping me and I'll jump on it rndquu

@Keyrxng https://github.com/ubiquity/leaderboard.ubq.fi

@Keyrxng if you open a pull there we can test the feature live on the website.

Keyrxng commented 5 months ago

@0x4007 I am due out just shortly for an apt but will open one by this evening.

I had been working on https://github.com/ubiquity/.github/issues/109 trying to ensure the data is as trustworthy and accurate as possible but it's been tricky to know if it's 100% accurate without a lot of manual inspection at first but it's not far off so that's why I haven't made any further progress with this PR.

Data without confirming isNonceClaimed

  "0x4007ce2083c7f3e18097aeb3a39bb8ec149a341d": 19282.950000000008,
  "0x0fc1b909ba9265a846b82cf4ce352fc3e7eeb2ed": 10631.3,
  "0x7e92476d69ff1377a8b45176b1829c4a5566653a": 9030.150000000003,
  "0xae5d1f192013db889b1e2115a370ab133f359765": 7944.9,

Data with confirmed isNonceClaimed

  "0x4007ce2083c7f3e18097aeb3a39bb8ec149a341d": 10515.099999999999,
  "0x0fc1b909ba9265a846b82cf4ce352fc3e7eeb2ed": 9724.999999999998,
  "0x7e92476d69ff1377a8b45176b1829c4a5566653a": 8201.449999999999,
  "0xae5d1f192013db889b1e2115a370ab133f359765": 6873,

ubiquity / work.ubq.fi

Feat/leaderboard #46

QA