Pour ne pas simplement rediriger vers cesium.app ?
L’idée c’est bien que cesium.app arrive en première position dans les moteurs de recherche non ?
Si on fait comme tu dis, ce qui va se passer vraisemblablement, c’est que les moteurs de recherche vont juste remplacer g1.duniter.fr par g1.cesium.app dans la première position.
PS : je m’étais gouré dans les URL mentionnées dans mon message.
Ce qu’a proposé Matograine, ou un bouton “Aperçu” qui redirigerait vers demo.cesim.app.
“Demo” a l’avantage d’être le même mot dans les langues latines et en anglais.
Et puis ça vient de demonstratio, “action de montrer” donc ça fait sens, et je pense que dans l’acception générale du mot, on comprend relativement bien qu’avec une “démo”, on a un aperçu du truc, mais pas tout le truc.
Et puis le reste des fonctionnalités est visible sur le mockup de la page d’accueil, au-dessus de la ligne de flottaison, donc je pense que le visiteur comprendra bien tout ça.
Est-ce possible de gérer cela par un déploiement IPFS ? Ainsi nous n’aurions plus qu’à mettre le hash de la version stable, dans la MR. Et nous serions garantie que la code n’est pas modifié, et je n’aurais pas besoin des accès au serveur pour mettre à jour. => Action @poka et @Frederic_Renault ?
D’ailleurs du coup (c’est peut-etre une question con) mais aurons encore besoin de passer Cesium en lecture seule, si une version est publiée sur IPFS ? Il faudrait alors un noeud IPFS sur cesium.app ? cc @Moul@elois@Frederic_Renault@poka ?
oui, je peux m’en occuper.
Il faut surtout choisir un domaine pour y insérer le DNSLink vers la passerelle (si on veut aussi un lien “court”)
IPFS est un “meta Univers” du point de vue du Web que nous connaissons… On accède à la ressource sans le chemin quand on fait tourner un noeud ipfs. Sinon, il faut passer par une passerelle (https).
Le principe des DApp est de ne s’adresser qu’à son localhost.
Si on prend l’exemple de Cesium, tout son code “fullJS” est compatible DApp, mais pas ses appels backend qui nécessitent des sockets dans le Web2.0
Une façon de faire progresser le niveau de distribution de Ceisum (et Gchange) serait de s’adresser à un noeud SSB en local.
Le problème de ce Web Full P2P vient de la réplication de sa DHT (ipfs swarm peers) et de sa correspondance à grande échelle. Combiné à la sous-structure que procure SSB, cela permet de régler le swarm sans qu’il se disperse dans l’Interplanetary Code en forge cette semaine…
Effectivement l’obligation de passer par une passerelle n’apporte pas d’avantage de sécurité.
L’avantage que l’on peut expoiter n’est valable que si le code de Cesium contrôle le HASH IPFS de son code ou de ses composants pour pouvoir s’éxécuter…
Je vais peut-être dire une bêtise, mais un module firefox qui chargerait cesium à partir de son tag IPFS ? On aurait pas besoin de passerelle dans ce cas non ?
Ah ah, oui, mais le but n’est pas de contenter les geeks qui ont pléthore de jouets pour utiliser Cesium en rajoutant une passerelle inutile pour eux. Le but est de fournir à « Monsieur tout le monde » un moyen sûr et pratique de retrouver Cesium dans son navigateur, quand « Monsieur tout le monde » ne sait rien installer en dehors de son navigateur.
Alors un addon IPFS sur lequel on peut ajouter un hash aussi facilement qu’on installe un addon Firefox. Le hash serait accompagné d’un titre et d’une icône.
MR faite. Attention : je n’ai aucune connaissance en PHP, je copie la structure de ce qui a été fait avant moi. Bien vérifier que c’est bon avant de merger.
+ j’ai fixé le lien pour la version .deb à la 1.6.1 pour éviter le bug déjà remonté 3 ou 4 fois.