Over the last few days with @Sarah.Magicienne and Cristina Abella, we’ve seen a small issue with WOT’s initial operations.
What we saw, following several G1nkgo apps, was that the username pending validation wasn’t displayed as such, but rather in a state prior to the “identity create address” process, like a basic account. The same thing was shown on my duniter panel:
And in duniter panel was also not well… The thing that in my android app your certification info was ok but not in the web version (same code) and neither in duniter panel. This smell like some server was not providing well the certification info. In this case, the apps cannot do nothing.
In part, thinking aloud, I think G1nkgo should connect to a good synced node automatically, so maybe something was failling too in the auto-node-selection code, or maybe, the list of nodes that G1nkgo has now configured, is not very out-to-date, but the thing is that I will love to have some online list to retrieve the nodes, like using ginspecte and json (already reported) Issues · jnoel / Ǧinspecte · GitLab
I am wondering if this topic was discussed at last Dev Talk? @kimamila and @ManUtopiK I remember that you had a discussion about the connexion to the nodes?
I’m not sure to understand your problem. If it’s about the identity name about unconfirmed status, the hash is a normal behavior from the indexer. We juste have to mask the identity name on apps side when de status is unconfirmed, because name is not set yet.
Hugo answered about this here: G1nkgo in GTest - #26 by HugoTrentesaux
About sync nodes, I think it’s ok if you take the highest block matching same block hash from a set of random answering nodes, also matching block hash from squid.
If you have another issue about identities states, please provide a wallet address in text format that we can help to debug.
Instead of this gitlab page, this is what i’m thinking about:
Add a daemon job on squid indexers to make periodic network scan from deep RPC queries, update a new db table/query with all scanned nodes with block height and hash (and latency?).
This query should also expose a timestamp with last success scan to be sure this is up to date.
The only thing that’s a little tricky to take into account is the chicken-and-egg problem. For example, in Gecko, the current flow is:
Scan the Duniter RPC network to retrieve the best node and cache it for the next restart (scan in the background for the next ones).
Then test and connect to a squid node synchronized with the chosen Duniter node.
So this means that you would first have to request an arbitrarily chosen squid to retrieve the nodes to connect to.
Then the client falls back to a manual network scan if it is unable to retrieve the list from Squid or unable to retrieve a recent timestamp.
As @vit said, G1nkgo can scan the network. I’ll write it for Cesium in the next couple of weeks in JS (using the libp2p JS version, you have in libp2p Dart version as well). So you can include it in G1nkgo and select a node among the “synced nodes”. Note that with Substrate, the network tends to be a lot more synced than in Duniter v1.
