Je ne sais pas ou placer ce sujet. Merci aux modérateurs de le déplacer si besoin.
Je ne sais pas non plus ce qu’il est possible de faire techniquement et si le sujet est correctement posé. Je le pose tel quel car de nombreux utilisateurs aimeraient avoir une appréciation correcte de la situation devant l’accroissement du nombre de Gmarchés.
Lors de Gmarchés en zone rurale, et en absence de wifi, nous nous connectons avec le réseau téléphonique. Nous avons du mal à enregistrer les transactions.
D’après mes connaissances, il peut y avoir deux raisons :
surcharge du relais 3G ou 4G ou puissance insuffisante.
ralentissement volontaire de Duniter qui capte beaucoup de transactions émanant des mêmes serveurs.
Serait-il possible d’envisager :
qu’un électronicien nous fasse un amplificateur de réseau (à moins que cela n’existe déjà ?)
permettre à Duniter de faciliter les transactions lorsqu’un Gmarché a été déclaré. (Quelle serait la procédure de déclaration ?)
Si tout le monde est sur les mêmes antennes des mêmes opérateurs, donc sur les mêmes adresses IP, les nœuds Duniter sollicités par plusieurs personnes différentes appliqueront l’antispam comme si c’était un unique client. (cependant la réponse de Duniter à un trop grand nombre de requêtes émanant d’une IP n’est pas un ralentissement du service, mais une coupure nette pendant plusieurs minutes)
Solutions :
que chacun utilise des nœuds différents pour limiter le risque de bannissement
que quelqu’un mette en place un nœud dans le marché, connecté à Internet et à un réseau wifi local, et que les gens s’y connectent. Tout sera alors plus rapide pour les utilisateurs, il y a moins de risques de pertes de transactions dans des forks, et une seule machine a besoin de communiquer avec les autres nœuds. (l’antispam du nœud peut être désactivé dans la config)
Si c’est du réseau téléphonique uniquement, alors Duniter n’est pas en cause, car ce n’est pas du spam sur une même IP.
La seule cause ici est le fait que Cesium est extrêmement lent sous faible débit, je l’ai expérimenté moi-même de nombreuses fois. Cesium demande beaucoup trop d’informations au réseau tout le temps, vous pouvez déjà désactiver Cesium+ pour contourner en partie de problème, mais ça ne suffira probablement pas.
À moyen terme il faudrait qu’on ait des wallet qui soient mieux optimisés sous faible débit, par exemple qui détecte dynamiquement la qualité de la connexion et qui adapte la richesse des informations à celle-ci, et qui n’affiche que le strict nécessaire pour réaliser un paiement dans le cas où la connexion est mauvaise.
En attendant,il vous reste l’option d’inscrire vos échanges sur des livrets papier pour les effectuer une fois rentré chez vous, ça reste qu’une promesse de paiement avec un risque de ne pas honorer sa promesse, mais c’est exactement les mêmes risque que pour tout système de pièces/billets Ğ1.
J’approfondis tout haut une idée qui traîne dans ma tête depuis un moment.
Peut-être qu’un client ultra-light dédié au paiement devrait être développé sous Androïd/iOS avec les fonctionnalités suivantes :
Enregistrer ses identifiants secrets pour éviter de les retaper à chaque paiement (peut-être une saisie unique à l’ouverture de l’appli pour une session de quelques heures ou alors enregistré une fois pour toute dans les paramètres de l’appli, là où on saisirait/sélectionnerait l’adresse d’un noeud duniter par ex)
Afficher le montant de son compte et ses dernières transactions paginées par paquet de 5 (avec un bouton « Voir plus »)
Effectuer un paiement :
Rechercher une identité dans la blockchain et/ou scanner un QRcode contenant une clé publique
C’était un des objectifs de gecko : déverrouiller par code PIN, scanner, enregistrer des transactions hors-ligne et les publier quand la connexion revient.
Il me semblait bien que c’était un peu le but de Gecko Mais comme je n’ai encore vu aucun prototype ni cahier des charges (par manque de temps surtout), je posais ça là au cas où.
Pourquoi parles-tu au passé ? Le projet est abandonné ? Ou juste en suspens le temps des futures évolutions de duniter ?
Gecko fonctionne sur GVA, mais GVA ne sera jamais mis en prod, donc je ne peux pas passer Gecko en prod. Mais il est utilisable, voir le sujet gecko pour trouver le dernier apk.
La dernière version de Gecko utilise l’API RPC de substrate pour se connecter à Duniter v2.
Manque subsquid pour requêter l’historique des transactions, et les méthodes adéquates pour gérer la wot via RPC côté Duniter (je crois que c’est déjà le cas mais je n’ai juste pas encore regardé).
Mais je ne vais pas refaire la même erreur qu’avec GVA. J’étais à peu prêt certains que GVA arriverai en prod tôt ou tard donc j’ai tout misé dessus.
J’attends un peu que Duniter v2 soit prêt à voir le jour pour continuer Gecko dans cette voie.
Mais comme je n’ai encore vu aucun prototype ni cahier des charges (par manque de temps surtout), je posais ça là au cas où.