d’embarquer plusieurs fois smoldot dans différentes applis (Ǧecko, Césium, Wotwizard…)
que l’utilisateur débutant attende 100 ms de trop
que l’utilisateur avancé puisse croire être connecté à son nœud p2p local éteint alors qu’il est connecté à un seul nœud
Ma proposition est la suivante :
par défaut, l’appli est en mode « naïf » et se connecte à un seul nœud qui répond parmi une liste prédéfinie
l’utilisateur avancé peut activer le mode « avancé », renseigner des nœuds custom, dont un smoldot local, et si la connexion au smoldot échoue, il est prévenu, ce qui lui laisse le choix de rallumer son smoldot ou basculer sur le mode naïf
Je suis contre cette idée, et plus généralement contre l’idée que les light clients seraient réservés aux utilisateurs avancés.
Je veux qu’un utilisateur lambda qui ne comprend rien à la technique puisse utiliser un light client, qu’on est juste à lui dire, tu installes tel programme et que ça juste marche, sans configuration manuelle à faire.
Moi je suis pour qu’un utilisateur lambda qui souhaite utiliser un light client le fasse en deux étapes
installation du light client
configuration de son / ses wallets
Ça me paraît être la base de la responsabilisation : comprendre qu’un app se connecte à quelque chose.
Mais on peut aussi faire ça de manière astucieuse avec un bouton dans le light client qui mène à l’écran de configuration du wallet. Par exemple dans Android, quand tu installes Fdroid, il te mène à l’écran qui l’autorise comme source d’installation de logiciels.
Dans un premier temps de toute façon je compte pas m’attaquer à smoldot tout de suite (trop de choses bien plus prioritaires) donc ce sera liste locale directement pendant un moment.
Quand on commencera à intégrer smoldot, bindé ou non, on commencera par une saisie manuelle uniquement comme le propose Hugo, le temps de bien tester dans la durée. Puis on envisagera plus d’automatisation plus tard.
Attention, il faut avoir en tête la réalité : tous les noeuds n’auront pas les indexeurs, et tous les indexeurs ne seront pas forcément configurer avec la même stratégie.
Il faut donc bien savoir quel noeud propose quoi.
J’ai compilé sur master, ça marche bien ^^. Et j’en profite pour te rappeler le bug que j’ai toujours en saisissant le dernier mot de mon mnemonic « lawsuit » où le clavier se replie avec le « law ».
Je viens de télécharger et installer l’app, chez moi ça ne fonctionne pas, l’app ne s’ouvre pas
Quand je regarde toutes mes app, pour gecko j’ai un écran blanc, et quand je clique sur l’écran de gecko la fenêtre disparaît et ça retourne sur mon menu principal.
Je pense que quelque chose plante au démarrage, mais je ne sais pas comment obtenir plus d’informations
Je viens d’installer la stack de dev ğecko sur le laptop que j’emmène aux RML16 et ğecko plante au démarrage avec le message dans la console de debug :
Launching lib/main.dart on sdk gphone64 x86 64 in debug mode...
✓ Built build/app/outputs/flutter-apk/app-debug.apk.
Error waiting for a debug connection: The log reader stopped unexpectedly
Error launching application on sdk gphone64 x86 64.
Exited (sigterm)
[edit] ça avait l’air dû à une collision entre le adb système et android studio. Et maintenant ça crash avec :
Launching lib/main.dart on sdk gphone64 x86 64 in debug mode...
✓ Built build/app/outputs/flutter-apk/app-debug.apk.
E/AndroidRuntime(12227): FATAL EXCEPTION: pool-3-thread-1
E/AndroidRuntime(12227): Process: gecko.axiomteam.fr, PID: 12227
E/AndroidRuntime(12227): java.lang.IllegalArgumentException: gecko.axiomteam.fr: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
E/AndroidRuntime(12227): Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
E/AndroidRuntime(12227): at android.app.PendingIntent.checkFlags(PendingIntent.java:375)
E/AndroidRuntime(12227): at android.app.PendingIntent.getBroadcastAsUser(PendingIntent.java:645)
E/AndroidRuntime(12227): at android.app.PendingIntent.getBroadcast(PendingIntent.java:632)
E/AndroidRuntime(12227): at androidx.work.impl.utils.ForceStopRunnable.getPendingIntent(ForceStopRunnable.java:196)
E/AndroidRuntime(12227): at androidx.work.impl.utils.ForceStopRunnable.isForceStopped(ForceStopRunnable.java:128)
E/AndroidRuntime(12227): at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:93)
E/AndroidRuntime(12227): at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
E/AndroidRuntime(12227): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
E/AndroidRuntime(12227): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
E/AndroidRuntime(12227): at java.lang.Thread.run(Thread.java:920)
Une fois qu’on a un environnement qui marche c’est génial Flutter, mais avant d’en arriver là c’est un enfer
Alors d’abord, quelqu’un avec un fairphone 3 a rencontré ce pbm hier :
LateInitializationError: Field 'cesiumSeed' has not been initialized.
Preuve que le runtime Dart fonctionne bien, l’attribue late Uint8List cesiumSeed; n’était plus initialisé au démarrage de l’app, car plus utilisé nulle part, ce qui n’est pas possible pour un late.
Pas contre je ne sais pas pourquoi ne pas avoir eu ce problème en debug, d’habitude c’est le cas. Ni sur mon téléphone d’ailleurs !
C’est corrigé.
E/AndroidRuntime(12227): java.lang.IllegalArgumentException: gecko.axiomteam.fr: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Ok merci @HugoTrentesaux, je pense que c’est l’origine du pbm d’@elois qui doit être sur Android 12:
// required to avoid crash on Android 12 API 31
implementation 'androidx.work:work-runtime-ktx:2.7.0'
Mon émulateur et mon phone son sur Android 11 donc j’avais pas cette erreur.
C’est corrigé aussi, tu me dira @elois si ça corrige bien ton pbm, et @HugoTrentesaux dans ton debug.
Maintenant Ğecko se lance bien, je viens de créer un portefeuille, c’est vrai que la procédure est longue, mais il faut bien ça pour s’assure que l’utilisateur comprenne bien les implications
Par contre quand je paramètre l’url d’un nœud duniter-v2s, ça ne marche pas, il dit que le nœud duniter est injoiniable, c’est normal ? À noter que c’est un nœud dont le endpoint websocket est derrière un path, peut-être que tu ne gères pas correctement les path ? Fausse alerte, je n’avais pas saisi la bonne URL.
Alors je n’ai encore jamais testé sur des path, je n’avais à disposition jusque là qu’un noeud en local.
Dès que tu me donne un endpoint avec path, je pourrais tester et fix si nécessaire.
Il faut bien mettre wss:// au début si c’est un noeud ssl, mais ça je pense que tu le sais ^^
