I’ve implemented a board component that retrieves the $HYPE balance of a (so far) hard-coded list of accounts. It uses a wallet connection stored in a newly introduced application-wide state, which is applied by the $HYPE registration button during sign-in process.
In the spirit of decentralization, this seems like something well suited for a Graph Protocl subgraph, as I hear they’ll be working with NEAR soon!
In the meanwhile we could cache data server-side and query blocks ourselves… I dont know the best way to go about that, do you have any input @EV3RETH?
As far as getting the data goes, we either need to cache/index transactions ourselves or wait for Graph to provide a similar service.
UI wise I was actually thinking the $HYPE button on the left would act as the portal to all things $HYPE related. Although we do need to figure out a system for sub/pages and navigation as we add more areas to the site. Looking forward to chatting with you about it all!
@mxjxn Thanks a lot for the hint. I managed to build a CLI tool called near-ft-query that can find and decode contract calls to hype.tkn.near for in interval of blocks:
@EV3RETH I think it would be cool to develop that further and cache all $HYPE balances in a JSON file, that an update would only append to. We could then try to run this update once a day from somewhere (Github CI, if it allows such a long-running “blockchain task”) and store it on IPFS or Arweave?
I’ve continued working on this a bit and might have come up with an intermediate solution prior to GraphQL support.
The CLI block query tool near-ft-query can now be used to
a) Initialize a cache file that contains timestamps, the oldest block and all active accounts. These can be passed via the commandline: near-ft-query init erikli.near,mxjxn.near
b) Update an existing cache by querying all active accounts between the oldest block and the current one (currently hard-coded)
This gives us the opportunity to create a cache file with a (so far hand-compiled) list of active accounts from the time of HYPE creation until today. This file could be stored on Github where the leaderboard component reads it from. We could move on with that.
The next step could be to test the update mechanism and decide on an environment to run the CLI in. From here the cache file could be updated daily by taking only the blocks since last update into account.
Thank you for all the work thus far. I will say anything that needs to be updated manually is kinda outa the question.
We are going to be building a DB of active users and artists shortly, I think the best short term yet scalable solution is to wait on that and have "$HYPE amount just be a field/column in the profile table.
Every-time a user logs in we would update their total HYPE amount, and we could also make a master function that iterates through active accounts and manually updates their info in the DB
If your CLI command can check the entire history in an efficient way, then we could just have it be a button that people click to build the leader board in real time. That would be sufficient for now till the db is up
Spent some time thinking about that earlier today. The most important part is getting all accounts that received $HYPE through the contract, right? As long as I’m not missing something here, we’d either need an indexer that updates that list every time ‘ft_transfer’ was called or scrape recent blocks and do the update ourselves (pseudo-indexer). Both need some thinking where that account list is stored and where the (pseudo)-indexer should run. The pseudo-indexer needs more thinking on how and when to efficiently retrieve new blocks.
So if we have that list somewhere stored and updated, the actual amount an account has can be retrieved from the contract via direct call in realtime.
@EV3RETH Could you give some more information on how you’d imagine the mechanism to work considering your idea on the login update?
My thinking is we just have a API call that updates a users stored HYPE amount on our soon to be db every time a user connects their wallet/makes any meaningful tx through our site. We wouldn’t really be interacting with blocks at all. Just logging info when we observe it via user activity.
Obviously this is a very limited way of doing things. But I don’t think we have the capabilities to run our own true indexer.
Omg, I couldn’t stop working on it. But I came up with a system that could for us until the internal database is ready (because I also liked the idea of updating it on login, @EV3RETH).
I moved the CLI tool into the HypeDAO repository and created a Github Action. That action runs the CLI update command in order to automatically update a manually initialized JSON cache file every hour. This cache file lives on a separate branch in the monorepo.
This is amazing, you’re an absolute legend! Looking forward to taking a closer look as soon as I can! Got a big bounty coming your way for sure for all the great work you’ve done!