Proposition: Fusionner les pods Cs+ et gchange - Logins G1 sur gchange desktop - Restrictions sur gchange.fr

Lors de la réunion d’hier soir, on a parlé des clients, et quelques idées sont apparues pour Ğchange :

  • Fusion des données avec Cesium+
  • Version web en mode démo

Si le client Ğchange est installé, alors on peut utiliser un compte membre ou portefeuille avec.

Pour la sécurité, la version web pourrait refuser le login avec des identifiants Ğ1, mais afin de permettre aux gens de découvrir la Ğ1, il pourrait générer une clé aléatoire, ou modifier les identifiants par exemple avec un préfixe particulier.

La compatibilité serait donc conservée.

Qu’en penses-tu @kimamila ?

3 J'aimes

Ce n’est pas suffisant, puisque pour cela il faut donner ses identifiants et donc c’est trop tard. Il faut complètement désactiver l’authentification, comme pour Cesium.

3 J'aimes

ça ne va pas marcher :
Si le préfixe est toujours le même, un attaquant qui est en capacité de découvrir les identifiants et mot de passe n’aura qu’à les retirer.
S’il est aléatoire, deux connections successive ne donneront pas accès au même compte.

Tout ceci bien sûr dans le but de merger les pods Cesium+ sur les pods Gchange. Les clients Cesium pourront utiliser les pods Gchange pour les profiles aujourd’hui Cesium+.

En d’autres termes, on ferme Cs+ qu’on migre sur gchange+, qui sert à tous les clients et les places de marchés june qui le souhaitent.


Et bien sûr et surtout, Cela permet d’inciter les gens à utiliser les identifiants junes comme identifiants gchange et simplifie énormément l’utilisation de gchange !

3 J'aimes

Je parlais de la forme des identifiants Ğ1. On ne pourrait même pas rentrer d’identifiants scrypt. « identifiant Ğ1 » ne désigne pas des comptes membres ni des comptes possédant des Ğ1…

Il le génère uniquement au login, ensuite il reste en cookie comme c’est actuellement le cas.

1 J'aime

Je crois comprendre ce que tu veux dire.

C’est ce que tu as proposé pendant la réunion ? De créer automatiquement les comptes Ǧchange portefeuille ? Je ne me souvenais plus quand j’ai fait le compte-rendu… N’hésites pas à bien expliquer comment tu vois les choses, parce que l’idée est très bonne. Voir aussi comment migrer les comptes actuels si besoin.

Décidément, on se comprend vraiment mieux en visio ! :wink:

2 J'aimes

Vit doit faire référence à ce post qui est modifiable :slight_smile:

Oui c’est ce que j’avais proposé. Ça pourrait être fait même sans la fusion Cesium+/Gchange, en fait.

En plus détaillé :

  • Gchange, version installée
    • pas de changements dans l’interface
  • Gchange, version web
    • au lieu de demander les identifiants pour se créer un compte, on génère une seed aléatoire.
    • le formulaire pour entrer ses identifiants scrypt pourrait toujours être accessible, via un bouton supplémentaire et avec un avertissement.
    • tout le reste est inchangé (la clé privée peut rester en cookie pour conserver son compte)

Une fois que la personne a testé Gchange et l’a installé, il faudrait qu’elle puisse copier son compte vers sa nouvelle clé publique (dont la clé privée n’est jamais passée sur une page web non sûre). Il faudrait donc qu’on puisse copier (ou déplacer) les données d’un compte sur un autre. Je vois deux options :

  • depuis le compte web, en étant authentifié, démarrer la procédure en indiquant la clé publique du compte cible. Sur ce dernier, en étant authentifié, recevoir une notification et cliquer sur un bouton pour valider la copie.
  • depuis le compte installé, en étant authentifié, entrer la clé privée du compte source. Cela nécessite de pouvoir exporter et importer une clé privée.

N’'est-ce pas ce que fait la génération de fichier trousseau ?

J’ai renommé le titre de ce topic @tuxmain

Ça va finir en hackaton cette histoire … :slight_smile:

2 J'aimes

Voici la roadmap grossière que j’ai en tête:

  • Lancer un pod gchange de dev sur une VM
  • Ajouter les champs Cs+ si il en manque dans le schéma de la DB ES gchange
  • Forker Cesium app et le build en mode dev
  • Choisir le noeud gchange de dev précédamment tweerké au lieu d’un noeud Cs+ dans le build de notre Cesium app (théoriquement, les requêtes devraient êtres les mêmes, sinon il faut les adapter dans le code)
  • Voir si on arrive à créer des profiles Cs+ correctement ainsi (sur le pod gchange de dev donc)
  • Préparer un script de migration de la DB Cs+ actuelle vers le pod gchange de dev (bash)
  • Clarifier ce qu’il advient des profiles gchanges actuellement utilisés

Vous avez 1h

(@Spencer you get it ? ahahah)

2 J'aimes

Pour moi, le fait de devoir passer par une appli pour un système de petites annonces est complètement absurde. Je veux bien croire que j’ai des pratiques numériques atypiques, mais je pense ne pas être le seul pour ce cas precis. Un site web me semble le standard pour cet usage.

D’autre part, mélanger les données CS+ et les annonces Gchange me semble un mélange des genres dangereux… Mais je ne sais pas bien fonder ce sentiment.

Ceci étant dit, je vois bien l’avantage de sécurité qu’il y a à faire de Gchange un logiciel local, compte tenu du système de connection actuel.

Donc, à prévoir pour qui veut le faire : un site qui utilise la db Gchange, mais avec un système de connexion classique.

1 J'aime

Non tu n’as pas compris dans ce cas. Il est question de maintenir à tout prix gchange.fr

Seulement, en lecteur seul, et bien réfléchir les appels à actions, pour créer une annonce proposer d’installer le plugin navigateur par exemple, ou l’app desktop.

Avec un interfaçage bien foutu avec un plugin navigateur, ça deviendrait aussi simple de consulté les annonces gchanges, de tapper dans l’api publique pour les geeks, et l’utilisation loggué serait à peine plus compliqué, si c’est bien foutu encore une fois.

Moi je ne vois pas en quoi ce sont 2 genres différents. Ce sont des données de profiles publiques. Voilà.

Au contraire, cela clarifirait tout. Finit Cs+ et l’ambiguité de Cesium et ses données, tous ce qui concernes les données utilisateurs pour Cesium et gchange serait au même endroit, les pods gchanges.

Je comprends l’incompréhension (elle est belle cette phrase, c’est presque un oxymore non ?) de matograine. C’est en partie dû au nom du pod.

A mon avis, le pod fusionné doit changer de nom. C’est la base des indices (index) de métadonnées des utilisateurs et des annonces de l’éco-système Ğ1.

Allez, proposez vos noms !

  • g1-metadata-pod
  • g1-metapod
  • metapod-g1
  • data-pod-g1
  • g1-datapod
  • g1-index-pod
  • g1-bigdata-pod

Bref, you get the point… :wink:

2 J'aimes

+1 :slight_smile:

2 J'aimes

On peut changer de nom, mais pas forcément, pour moi gchange veut tout dire aussi. « Gchange mes données ». Je sais pas je trouve qu’on peut donner du sens aussi à appeler ces pods juste gchange-pods.

Ou pas.

1 J'aime

Le problème est d’avoir deux choses différentes portant le même nom :

  • Le client de petites annonces bien connu
  • Le serveur multi index qui sert plusieurs clients (Cesium, Gecko, Gchange, ptet Tikka un jour).

Changer de nom pour refléter cela me paraît plus simple, en terme de communicatiion, que d’expliquer aux nouveaux contributeurs que pour avoir les profils comme dans Cesium+, il faut utiliser l’api de gchange-pod…

Je suis d’accord, le terme gchange irait aussi bien, mais il est déjà pris. :sweat_smile:

3 J'aimes

ğlient+ :smiley: ?

c’est joli, mais j’ai pas compris comment je dois le lire … dis nous en plus :wink:

Je pensais au contraire qu’il fallait éviter que les gens utilisent les mêmes identifiants car Gchange est plus facile à pirater et donc à récupérer les identifiants ?.. je ne comprends plus ?

1 J'aime