En fait tout dépend de ce que l’on nomme “meilleur”. Il me semble que la concurrence est plus “efficace” plus “rapide” mais au prix de dommages collatéraux. La coopération est plus lente mais elle tire tout le monde vers le haut. Ce dilemme me semble être bien résumé par l’excellent proverbe : “Tout seul on vas plus vite, ensemble on vas plus loin.”.
Difficile a dire, ce qui est certain c’est que la concurrence fait toujours des perdants par définition, c’est peut-être utopique mais je préfère quand personne ne perd
Quel équation ? Quelle action collective ? Il y a déjà une section privée dans ce forum ou les principaux contributeurs techniques discutent des points a discuter, et il y a déjà naturellement certains d’entre qui jouent le rôle de médiateur quand il y a des tensions
On peut certes toujours mieux faire, mais je ne sais pas s’il est possible ni même souhaitable de mettre en place un “organe facilitateur” entre les contributeurs techniques de l’éco-système Duniter/Ğ1.
Dison qu’il nous faudrait une proposition précise, et la on pourrait décider de l’expérimentée ou pas. Mais un “organe facilitateur” ce n’est pas très précis
A quelle question précisément ? Chaque projet logiciel a déjà son workflow souvent très précis et détaillé, parfois moins, mais chaque leader de logiciel est bien libre de définir son workflow comme il l’entend, on peut tout au plus le conseiller, ce que @Moul fait déjà très bien avec son expérience en qualité logicielle.
Mais il me semble qu’on est déjà très bon coté workflow, notamment avec tout ce qui est automatisation Ci/CD, build reproductibles, signature des artifact (quelques projets ont encore a progresser sur ce derneir point mais c’est en bonne voie).
On ne peut pas en dire autant de G1sms, donc stp avant de donner des conseils a la terrre entière balaie un peu devant ta porte
Pourquoi faire ?
Tout dépend de ce que l’on appelle robuste, mais ce que sous-entend Moul c’est qu’il y a un travail colossal a réaliser coté cœur, notamment de nombreux changement de protocole qui vont s’étaler sur plusieurs années, pour permettre justement au cœur Duniter puis futurement Dunitrust d’être bien plus rapide. C’est relativement lent pour l’instant mais pas du tout pour les raisons que tu pense.
Mettre quoi en load balancing ? Cesium, ça ne sert a rien tout se passe déjà dans le navigateur de l’utilisateur. Duniter ? Le réseau est déjà décentralisé il suffit de changer de noeud.
Lol non, on reconnaît bien là que tu n’est que bidouilleur et pas dev,
Non c’est faux. Il suffit d’aller voir le TPS d’autres crypto blockcahin sur PoW pour s’en convaincre, je suis d’accord que la blockchain n’est pas faite pour les paiement instantanés, mais aujourd’hui ça peut prendre plus d’1h pour qu’une transaction soit validée quand il y a beaucoup de trafic (vécu aux RML), alors qu’a terme (avec les améliorations de protocole et du cœur), on peut descendre a quelques minutes maxi (grâce notamment a un temps plus court entre 2 blocs mais pas que).
Et bien tu a tord d’avoir cette impression. Des milliers d’ingénieurs ont vu ce problème venir bien avant toi ou moi et ont trouvés une solution après de nombreuses années de recherche, les Lightning Network :
Ils permettent des paiement instantanés (moins de 5 secondes si connexion internet fiable), garanties par la blockchain, et complètement trustless (pas de tiers de confiance).
Pour désengorger le réseau Duniter (qui n’est engorgé que lors de RML ou autre très gros event Ğ1), ils conviens par ordre de priorité de :
- Optimiser le protocole DUBP (réduction du temps moyen entre 2 blocs notamment)
- Optimiser l’implémentation (projet Dunitrust)
- Créer un client LN et un module LN pour Dunitrust.
Tout ces points concernent directement Duniter/Ğ1 car ils interviennent sur le cœur ou sont trustless. Les projets tiers (qui ne sont pas trustless), sont hors-sujet ici. C’est pourquoi on a demandé a kimamila de créer son propre forum pour gchange, et de ne pas parler de sa place de marché gchange ici.
De la même façon G1sms est un projet tiers qui n’a pas sa place sur ce forum.