Champs "outdistanced" de /wot/requirements ambigu?

matograine · 20 March 2020 11:00

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.

gerard94 · 20 March 2020 13:56

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

gerard94 · 20 March 2020 14:14

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

matograine · 20 March 2020 14:19

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 ?

Moul · 20 March 2020 15:03

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 ?

matograine · 20 March 2020 15:04

Oui, tout à fait.

elois · 20 March 2020 17:36

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.

matograine · 20 March 2020 17:39

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

elois · 20 March 2020 17:41

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

Moul · 24 March 2020 13:44

kimamila · 25 March 2020 10:38

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 ?

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

Moul · 25 March 2020 11:12

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.

elois · 25 March 2020 15:51

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.

matograine · 26 March 2020 12:54

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

elois · 26 March 2020 15:10

@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.

cgeek · 28 March 2020 10:32

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.

Moul · 28 March 2020 13:15

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