Aller au menu du forum Aller au contenu du forum Aller à la recherche dans le forum
Logo Khaganat
Menu principal
Menu

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.

Voir les contributions Menu

Sujets - Stan`

Cliquez pour afficher le message
Hello,
Comme discuté sur la #krypte j'ai fait une liste non exhaustive de toutes les questions que j'ai actuellement sur le futur jeu.
Q1 : J'ai cru comprendre que Ryzom ne fonctionne pas vraiment, faible affluence, problèmes de mises à jour, joueurs impatients, du coup pourquoi ne pas reprendre le serveur de Ryzom actuel sans rien changer et bosser main dans la main avec eux, pour transformer le client en un client Godot, plus facilement maintenable, pour leur permettre de mettre à jour avec vous le serveur ?
Q2 : Vous parlez souvent de votre fork, en quoi diffère-t-il de Ryzom, ne pouvez-vous pas faire des PR sur le dépôt, toujours dans une optique de travail en commun ?
Q3 : Est-ce que vous avez une bonne raison de vous désolidariser de Ryzom ?
Q4 : Est-il possible que vous hébergiez un serveur XMPP mutuel pour leur faire profiter un peu de votre bonne humeur et échanger des informations ?
Q5 : Si/Lorsque vous aurez un client fonctionnel Godot, est-ce qu'il sera envisageable de faire de la publicité en vue d'un crowdfunding ? (Les crowdfundings sans publicité préalables ne marchent pas vraiment)
Q6 : Si oui à la question précédente est-ce que vous considériez d'utiliser une plateforme de crowdfunding non libre (ex : Kickstarter) pour avoir une plus grande visibilité
Q7 : Avez-vous considéré d'ouvrir un Patreon, pour un ajouter des fonds à votre caisse dans un premier temps, voire embaucher quelqu'un si ça dépasse un SMIC ?
Q8 : Est-ce que la raison pour laquelle vous voulez réécrire/supprimer le PHP pour le remplacer par du python c'est parce que « "OMG le python c'est tro b1en" ou juste à cause de Django.
Q9 : Toujours dans l'optique de travailler avec Ryzom, ne serait-il pas cool de garder le même système d'erreur, pour que leur vieux client soit compatible avec votre nouveau Shiny Frontend, fût-il finalement codé en Python. L'idée étant d'avoir les anciennes fonctionnalités tout en ayant des trucs comme l'authentification Https et retirer au client le besoin de chiffrer ses identifiants, (Comme ce qui a été fait sur ma branche du Login)
Q10 : Si vous deviez changer de base de données (actuellement MySQL) qu'est-ce que vous prendriez ?
Q11 : Dans le contexte actuel on fait des clients compatibles avec un serveur, on déglingue le serveur, on met à jour le client, on rédéglingue le serveur.  Peut-être qu'il serait temps de se poser avec deed, de créer une nouvelle branche, et de commencer à construire quelque chose de durable. Je pense et ce n'est que mon opinion, que ce serait plus motivant pour tout le monde si on arrivait à faire un petit client en lien avec le serveur en sachant que le lendemain on arrêtera pas tout. Qu'en pensez-vous ? L'idée serait de fixer les technos, de décider de si vous désolidarisez Ryzom ou pas de vos plans, et de construire en partant de là. (Dernière VM à setup pour deed) Une démo vaudra toutes les promesses.
Q12 : Est-ce que vous avez pensé à contacter les associations « féministes » (n'ayez pas peur) comme Elles bougent pour voir si vous pouviez recruter des gens et faire valoir la position des filles dans la tech et le monde du libre ?
Q42 (Bonus) : Est-ce qu'on est tous d'accord que Osquallo, ben il gère ? 😊
Voilà, désolé si je suis relou, mais j'ai vraiment grand espoir pour votre projet, et je voudrais que ça bouge un petit peu (No offense)
PAMJAI et GUIMAUVES pour celles qui veulent.

 
Cliquez pour afficher le message
Par les temps qui courent la sécurité est de plus en plus importante et c'est la raison pour laquelle je crée ce Thread.
Pour l'instant on a un système qui a été désigné à l'époque ou les certificats HTTPS coutaient très chers, et qui offrait
une sécurité relative à l'époque. @Tycho à rendu ça un peu plus robuste en passant de DES à Sha-512. Le souci de la
méthode actuelle est qu'elle requiert un travail supplémentaire d'authentification au niveau du client, que Godot ne
supporte pas nativement.

L'idée serait donc de déporter tout ce travail de hashage et de salage sur le serveur, et d'envoyer les identifiants en clair
via HTTPS. C'est une solution raisonnable, mais ce n'est pas la plus sécurisée. Le hashage passerait aussi d'une méthode
SHA-512 à Argon2 qui est plus récent, et serait plus robuste.

Link Mauve parlait de passer par le processus de SCRAM qui est utilisé par XMPP, pour chiffrer et sécuriser nos communication
ce qui demanderait un travail supplémentaire. Il semblerait cependant qu'il y ait moyen d'avoir le support natif dans une version
ultérieure, les briques étant déjà là dans le code CPP. (Via mbedTLS)

Dans la mesure du possible pour des procédures aussi simples il serait idéal d'éviter de passer par des plugins et des librairies
externes pour des soucis de compatibilité cross-plateform.

Dans un second temps pour le chiffrement des paquets UDP (qui synchronisent tous les clients) il serait bien de définir un plan
de sécurité.

Voilà j'aurais aimé avoir votre avis sur les deux questions (Login, et communications). La cryptographie n'est pas mon domaine
du tout donc je vous prie de m'excuser si j'ai écrit des horreurs un peu plus haut.

J'en profite pour poster le schéma de fonctionnement actuel




Licences Mentions légales Accueil du site Contact