Asking the blockchain to evaluate distance result is a key part of identity creation process and membership renewal. As a spam prevention measure, some Ǧ1 are slashed in case of negative evaluation. The clients should only suggest the user to request distance evaluation when it knows the operation will result in a success. Thus clients should know distance result before the blockchain asks it to distance oracle. It is possible but cumbersome to evaluate distance result in the app because it means getting the whole web of trust and having an implementation. It would be easier to expose the result with a simple http endpoint which stays up to date with the web of trust and answers quickly to client requests. We have to set up an architecture for that.
I have a branch hugo/distance_precompute
with an additional binary /distance-oracle/src/bin/distance_precompute.rs
which runs in a cron to produce https://files.coinduf.eu/distance_precompute/latest_distance.json.
{
"height": 3294347,
"block": "0xc350d1f0711f396866c73f1430293ca7386427a3653216c180392ee233015d16",
"referees_count": 1642,
"member_count": 3400,
"min_certs_for_referee": 6,
"results": {
"11660": 1607,
"6549": 1556,
"9892": 1444,
...
identity index → number of referees reached
...
This can be used for the moment to estimate distance before requesting evaluation.
Hi !
For now, this precomputed result is created by oracle nodes and served by a web server on these nodes.
Is it planned to serve the information through indexers ? As it is done for now, client softwares must know the URL of one precomputed distance file, but they would rather use indexers if the information is there.
For now, this is not even computed by all oracles. Only a script running on mine. This is currently a centralized architecture and I have no short term plan to make it easier to replicate. The binary comes from the hugo/distance-precompute
branch.
As indexers are designed, I don’t think it is a good idea to add external data to it. It would be better to serve this directly on a part of Duniter RPC API. However, not all Duniter nodes would have this plugin installed (like not v1 Duniter nodes have transaction indexing, g1-monit, or wotwizard installed). So there should be a way to know which services are available where.
Client software must know a large list of URLs kinds (see Liste des endpoints topic). The same problem is valid for rpc endpoints, squid endpoints, datapod endpoints…