Champs "outdistanced" de /wot/requirements ambigu?

Bonjour,

Je viens suite au cas Maria44. Les informations que j’ai de Duniter, Silkaj et WotWizard sont incohérentes. Je précise :

Silkaj me renvoie ceci (outdistanced: True):

$ silkaj wot Maria44
Maria44 (HXSSj…) from block #300354-0000049C…
received 7 and sent 0/100 certifications:
|  received_expire  |      received      |  sent  |  sent_expire  |
|-------------------+--------------------+--------+---------------|
|    2022-01-31     |    Claire666 ✔     |        |               |
|    2022-01-31     |    carinecoxi ✔    |        |               |
|    2022-01-31     |     TristanG1      |        |               |
|    2022-01-31     |  Michellecuyer26   |        |               |
|    2022-01-31     | ChristineWilloth26 |        |               |
|    2022-02-06     | ChristineWilloth26 |        |               |
|    2022-02-06     |  Michellecuyer26   |        |               |
✔: Certifications written into the blockchain

Membership expiration due to certification expirations: 2022-01-31
member: False
outdistanced: True
Duniter également

g1.duniter.org/wot/requirements/HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin

{
  "identities": [
    {
      "pubkey": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
      "uid": "Maria44",
      "sig": "41zM43fpQ2SThaFPVun3u+9xwmixXhSWvMq94H41rJhBl7f+gRWn6i0g8QTvYGRnYGFNcbr7fAwlejPXYlQrCw==",
      "meta": {
        "timestamp": "300354-0000049C71DA5D9300ACE240D60A05BAC43C51EA6CBFCEF5CCD2857BDD18E71B"
      },
      "revocation_sig": null,
      "revoked": false,
      "revoked_on": null,
      "expired": false,
      "outdistanced": true,
      "isSentry": false,
      "wasMember": false,
      "certifications": [
        {
          "from": "3M4Ami4PZ3sui8KLXZSG8z4Gj6gV87s71vqrUyuT3GME",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "sig": "OEPDLR/retyWs1PCS9tP4ta6jpuGsSnamdIE8w0adVgkg2wTSpTT3i3Zzds7PWZ8ZweEbxooYkM4KX0Yw3yRAg==",
          "timestamp": 1584118184,
          "expiresIn": 62535048
        },
        {
          "from": "761wHWRX2vZSLMkVs1bzrREjKzm9xKANBthseGRguBrZ",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "sig": "9hdGzsOuiwB5XzvWKfb4/jsG81nwhtiBpKZBYE2zXxAN9gD474tmsOeYY5iaAw0JNLUmvGfBZ8L+dY0wVslrAQ==",
          "timestamp": 1584117912,
          "expiresIn": 62534776
        }
      ],
      "pendingCerts": [
        {
          "from": "3M4Ami4PZ3sui8KLXZSG8z4Gj6gV87s71vqrUyuT3GME",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "target": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "sig": "OEPDLR/retyWs1PCS9tP4ta6jpuGsSnamdIE8w0adVgkg2wTSpTT3i3Zzds7PWZ8ZweEbxooYkM4KX0Yw3yRAg==",
          "block_number": 305104,
          "block_hash": "000000C38E17B9AC1AB2B56E248CB0FC8FDF6108AFB0DE742F00F108881DF539",
          "block": 305104,
          "linked": false,
          "written": false,
          "written_block": null,
          "written_hash": null,
          "expires_on": 1589377784,
          "expired": 0,
          "blockstamp": "305104-000000C38E17B9AC1AB2B56E248CB0FC8FDF6108AFB0DE742F00F108881DF539"
        },
        {
          "from": "7Ay2uSL1zbtVBTxQMu27qMi6JWvWqFjfcCQMVKCVC7as",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "target": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "sig": "wgK3NuGt4/IXuDJNGj90O6NCVEAeR1f7rtxhzjqNDaVOLA1UZ/nOWgK09lBL27LXL/HKlLJ4SfLPyDOiKB04Cw==",
          "block_number": 305105,
          "block_hash": "000006E6AD08EA6CD84519D54EEB91F03B6E984BDB678D83732EE642E1E8B1B8",
          "block": 305105,
          "linked": false,
          "written": false,
          "written_block": null,
          "written_hash": null,
          "expires_on": 1589378067,
          "expired": 0,
          "blockstamp": "305105-000006E6AD08EA6CD84519D54EEB91F03B6E984BDB678D83732EE642E1E8B1B8"
        },
        {
          "from": "761wHWRX2vZSLMkVs1bzrREjKzm9xKANBthseGRguBrZ",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "target": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "sig": "9hdGzsOuiwB5XzvWKfb4/jsG81nwhtiBpKZBYE2zXxAN9gD474tmsOeYY5iaAw0JNLUmvGfBZ8L+dY0wVslrAQ==",
          "block_number": 305103,
          "block_hash": "0000085BF649A621FBE2A74F9B15C627F29A701A23C74685BADEE8712B558547",
          "block": 305103,
          "linked": false,
          "written": false,
          "written_block": null,
          "written_hash": null,
          "expires_on": 1589377512,
          "expired": 0,
          "blockstamp": "305103-0000085BF649A621FBE2A74F9B15C627F29A701A23C74685BADEE8712B558547"
        },
        {
          "from": "RnhoVQ6yDpM6D4Av8edRHsDKjGbpeXnRKiCcR4Dmb7H",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "target": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "sig": "PXttIS6xmLmcAtcsQgJqtHcYE5yMU2LnvHJ4NITJhqSX/IQeG7PgzJjSCTJkeSWS/Kw38r1UmzqiHkJrpateDg==",
          "block_number": 305110,
          "block_hash": "000002B372FB19662DC79EEED07EAED72EED7927B78A6374B5B101DE6ED79ECD",
          "block": 305110,
          "linked": false,
          "written": false,
          "written_block": null,
          "written_hash": null,
          "expires_on": 1589379563,
          "expired": 0,
          "blockstamp": "305110-000002B372FB19662DC79EEED07EAED72EED7927B78A6374B5B101DE6ED79ECD"
        },
        {
          "from": "C6Yz5vgyZ5KHxqRPy4zoAVqK4SNTvqq6DURTBqG2UesD",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "target": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "sig": "cj9gF1hJmmXyi+1jQv9w2j5yV9em755fIXaUIxmD5KZmyH2KZVlOa9o9T3AHAagcfkpEGaknTyVTTq5N+7NTCA==",
          "block_number": 305110,
          "block_hash": "000002B372FB19662DC79EEED07EAED72EED7927B78A6374B5B101DE6ED79ECD",
          "block": 305110,
          "linked": false,
          "written": false,
          "written_block": null,
          "written_hash": null,
          "expires_on": 1589379563,
          "expired": 0,
          "blockstamp": "305110-000002B372FB19662DC79EEED07EAED72EED7927B78A6374B5B101DE6ED79ECD"
        },
        {
          "from": "RnhoVQ6yDpM6D4Av8edRHsDKjGbpeXnRKiCcR4Dmb7H",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "target": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "sig": "z6KtLcViry/2EzDVHA/l7l3P+mzGCCuc55Nm61NGgmMtR0UAhTwNPRiZnkdgQZo1hS23f/C34azk7tMq1qYbDA==",
          "block_number": 306792,
          "block_hash": "0000011A6845D9914AE53287CC61D0183B968AD67620B06DC89CC19365D1C1BE",
          "block": 306792,
          "linked": false,
          "written": false,
          "written_block": null,
          "written_hash": null,
          "expires_on": 1589901299,
          "expired": 0,
          "blockstamp": "306792-0000011A6845D9914AE53287CC61D0183B968AD67620B06DC89CC19365D1C1BE"
        },
        {
          "from": "C6Yz5vgyZ5KHxqRPy4zoAVqK4SNTvqq6DURTBqG2UesD",
          "to": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "target": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "sig": "+U5mq5J1IMcG/13Ixm9AVXv/AZd+rJy8+Vhy9dILRGLsH/QJ+ICD5/lnkrs2whB/AZr7Kkp9a4NP50QqC53lAg==",
          "block_number": 306800,
          "block_hash": "00000276F4AFAA98AFF519F60E3423A119383E8C697546DB0537321A3BFF46DE",
          "block": 306800,
          "linked": false,
          "written": false,
          "written_block": null,
          "written_hash": null,
          "expires_on": 1589903459,
          "expired": 0,
          "blockstamp": "306800-00000276F4AFAA98AFF519F60E3423A119383E8C697546DB0537321A3BFF46DE"
        }
      ],
      "pendingMemberships": [
        {
          "membership": "IN",
          "issuer": "HXSSjJF9BBAgpwUwoDrn6xYDkqnFMPvRpp6JCD6CZyin",
          "number": 300354,
          "blockNumber": 300354,
          "blockHash": "0000049C71DA5D9300ACE240D60A05BAC43C51EA6CBFCEF5CCD2857BDD18E71B",
          "userid": "Maria44",
          "certts": "300354-0000049C71DA5D9300ACE240D60A05BAC43C51EA6CBFCEF5CCD2857BDD18E71B",
          "block": "300354-0000049C71DA5D9300ACE240D60A05BAC43C51EA6CBFCEF5CCD2857BDD18E71B",
          "fpr": "0000049C71DA5D9300ACE240D60A05BAC43C51EA6CBFCEF5CCD2857BDD18E71B",
          "idtyHash": "43EF0E6C982F70E62915DB806A6F0343B62B257CF074C9F654C7B012351F9AED",
          "written": false,
          "written_number": null,
          "expires_on": 1587901454,
          "signature": "ys+WbprlZG6ruv4iP3d12zWNB5g822WpeNGx3TuPjgX6MHqMjCDTp71nxFy8rRz31Abyo2tl2kNAwhq+un5uCQ==",
          "expired": null,
          "blockstamp": "300354-0000049C71DA5D9300ACE240D60A05BAC43C51EA6CBFCEF5CCD2857BDD18E71B",
          "sig": "ys+WbprlZG6ruv4iP3d12zWNB5g822WpeNGx3TuPjgX6MHqMjCDTp71nxFy8rRz31Abyo2tl2kNAwhq+un5uCQ==",
          "type": "IN"
        }
      ],
      "membershipPendingExpiresIn": 29501118,
      "membershipExpiresIn": 0
    }
  ]
}

Mais WotWizard affiche que cette identité deviendra membre le 24/03.

Je vois un cas où une certif intermédiaire pourrait changer le respect de la règle de distance : c’est si Maria44 est juste à la limite de respecter cette règle, et qu’un membre « proche » devient référent entretemps. Ce cas me paraît improbable, mais il existe.

Questions :

  • Ce champs outdistanced indique-t-il bien qu’une identité ne respecte pas la règle de distance ?
  • Ce champs est-il valable pour les identités en attente d’enregistrement BC ?
  • WotWizard prend-il en compte l’évolution des statuts de membres référents dans le cas que j’ai évoqué ?

Il y a une seule occurence de outdistanced sur la doc BMA. Dans le protocole, la règle BR_G24 (pour ce que j’en comprends) ne dit rien par rapport à ce cas.

  • La règle BR_G24 est-elle vérifiée après que d’autres règles (5 certifs disponibles p.ex) soient True ? Dans ce cas, le champs outdistanced ne serait valable que pour des identités membres.

Merci matograine. Je vais regarder ça de près. WotWizard me donne 89% des membres référents à 5 pas au plus de Maria44.

g1-monit est d’accord avec WotWizard :

Un de ses certificateurs, TristanG1, a une qualité de 80,39% (source WotWizard). Cette qualité seule permet l’entrée de Maria44.

À ce stade, il est clair qu’il y a un bug, mais où ?

Est-ce que Silkaj reproduit le résultat de Duniter ou est-ce qu’il fait le calcul lui-même ? @moul

Tout à fait, Silkaj reproduit l’information de Duniter. C’est pour ça que je pose la question :

Si c’est le cas, et je crois que c’est le cas, alors il est normal que outdistanced soit False pour dossiers qui ne rempliraient pas des conditions moins coûteuses à vérifier (5 certifs dispo par ex.).

Donc Silkaj, pour fournir une info valable pour les identités non-membres, devrait faire le calcul de distance lui-même.

Ping @cgeek @elois ?

1 J'aime

Le chemin wot/requirements/<pubkey> a été introduits dans le but de permettre de savoir où en est le dossier d’une identité pour devenir membre.
Le champ outdistanced permet de savoir si l’identité respecte la règle de distance et non si le nombre de certifications est respecté. Il s’agit de paramètres distincts pour l’obtention du statut de membre.
Où est le problème ? Duniter, via BMA, dit que l’identité Maria44 ne respecte pas la règle de distance alors que g1-monit et WotWizard disent l’inverse ?

Oui, tout à fait.

Il me semble qu’il avait été décidé de ne plus évaluer la règle de distance par un appel BMA afin d’empêcher une attaque qui consisterai a forcer le noeud a faire un calcul coûteux beaucoup de fois.
Donc le champ outdistanced retourne désormais toujours true, il aurait du être supprimé a la place mais peut-être que @cgeek avait décidé de garder le champ pour ne pas casser la compatibilité avec les clients.

Dans le cas d’un membre (moi par exemple), il est à False. Peut-être pas pour tous les membres.

1 J'aime

C’est probablement uniquement pour les non-membres que le calcul a été désactivé, je ne sais pas, il faudrais vérifier dans le code de Duniter

1 J'aime

Oula, non je ne crois pas. Ou alors je ne suis pas au courant. Comment les clients pourraient ils calculer ce champs eux même ? Est-ce leur role ?

Sur Duniter, on voit bien que /wot/requirements est de plus en plus lent. Ca pose des soucis de fluidité qui commence à être pénible, dans Cesium.
N’y aurait-il pas moyens de :

  • continuer à calculer ce champ, sur les noeuds
  • Gérer un cache (par exemple d’un durée de 5 min) pour éviter une recalcule systématique, en ainsi accélérer les temps de réponse ?

Est-ce du temps perdu d’investir la dessus ? bah, de toute manière, on aura le même le même soucis sous GVA, non ? :slight_smile:

Je veux bien que quelqu’un fasse cela pour moi. Je suis prêt à offrir 5000 G1 !

Pareil, je ne suis pas au courant. As-tu une référence Éloïs ?

Je suis d’accord, il n’y que wotb ou équivalent rust qui sont efficace pour ces calculs.

Calculer ce champ de temps à autre et le stoker dans la base de données pour les clients semble être une bonne chose à faire pour les API clientes.

Non je dit ça de mémoire, je sais qu’on en avait parlé, je me disais que cgeek l’avais peut-être fait du coup.

Citation @elois :

Because verifying the application of the distance rule is calculation-greedy, it is only performed when a new identity gets confirmed into the web or an existing member gets renewed.
deep-dive-into-the-web-of-trust

@matograine cet article décris les aspects protocolaire, la on parle de l’API client donc c’est hors-scope de l’article.

Ce qui est affirmé dans l’article est vrai du point de vue du protocole. Après l’API client reste libre de faire certains calculs plus souvent a titre informatif.

1 J'aime

Oui je me rappelle que l’on a évoqué le sujet.

Actuellement BMA calcule effectivement la distance car l’option computeDistance est à true par défaut et n’est pas mise à false par BMA :

Donc le calcul est bien effectué.

edit : j’ai trouvé un chemin de l’API où le calcul est sauté : URL /wot/requirements-of-pending.

Par contre à regarder le code, ce calcul tient compte de la piscine donc il peut éventuellement y avoir des variations de résultat selon le nœud. Je ne sais pas si c’est la raison de vos interrogations.

Ah, ce chemin n’est pas documenté et n’est pas implémenté dans DuniterPy.