Handle ENS

[technophile-04]

Description:

We already have ens row for builder which is optional and we are not filing it because:

bg-ponder-indexer/src/CohortContract.ts

Line 13 in bc349e9

// TODO: Add ENS lookup: ChainDoesNotSupportContract: Chain "mainnet" does not support contract "ensUniversalResolver".

We need to explore this or we could also even use https://ensdata.net/

[damianmarti]

The issue with adding the ENS when the builder is added is that if the builders change the ENS later, it will still appear as the old one. It's true that the ENS names are not changed often.

The names are resolved using the address component when the members are shown now. Since there are a limited number of members, this is not a current issue, right? And the sites where we show the members are not heavy on traffic. Maybe if we are thinking about other projects with a lot of members using our stream platform makes more sense this change.

Anyway, if we decide to add this, I can work on it!

[carletex]

Hey @damianmarti

Some context: We are using the GraphQL endpoint to get the data for some internal scripts (like getting the amount withdrawn for each person on a given period of time). So for those, after the data comes back from ponder, we need to fetch the ENS for them to know who is who (which is not very efficient haha)

Adding the ENS here would be like a caching mechanism.

when the builder is added is that if the builders change the ENS later, it will still appear as the old one. It's true that the ENS names are not changed often.

Yes, but we don't really care, right? Since this is internal, even if they change the ENS we'd know who they are by their old ENS :D

---

Also: is there a standard way to run migrations/scripts on Ponder?? Like if we add this functionality, it will work for new builders but the old ones won't be updated (unless Ponder deletes everything and starts again every time we deploy... which I'm not sure).

@damianmarti assigning it to you!

[damianmarti]

Hey @damianmarti

Some context: We are using the GraphQL endpoint to get the data for some internal scripts (like getting the amount withdrawn for each person on a given period of time). So for those, after the data comes back from ponder, we need to fetch the ENS for them to know who is who (which is not very efficient haha)

Adding the ENS here would be like a caching mechanism.

when the builder is added is that if the builders change the ENS later, it will still appear as the old one. It's true that the ENS names are not changed often.

Yes, but we don't really care, right? Since this is internal, even if they change the ENS we'd know who they are by their old ENS :D

Thanks for the explanation @carletex

Also: is there a standard way to run migrations/scripts on Ponder?? Like if we add this functionality, it will work for new builders but the old ones won't be updated (unless Ponder deletes everything and starts again every time we deploy... which I'm not sure).

I will take a look at it, I think that we need to ask Ponder to reindex all the data...

@damianmarti assigning it to you!

Thanks!

[damianmarti]

Also: is there a standard way to run migrations/scripts on Ponder?? Like if we add this functionality, it will work for new builders but the old ones won't be updated (unless Ponder deletes everything and starts again every time we deploy... which I'm not sure).

After changing the indexed code, Ponder flushes all the data and reindexs all again, so no migration is needed and the ens field will be populated to all the builders. There is an open Issue to avoid this behaviour ponder-sh/ponder#934