Sommaire
Bon, je n’ai pas besoin qu’on m’explique pourquoi le Web n’est pas parfait, ça je suis au courant. J’imagine que vous aussi, mais je peux faire un petit résumé de ses problèmes :
* Le Web est devenu tellement complexe que seuls des clients très costauds permettent d’y naviguer confortablement ; par conséquent, seules des entités puissantes peuvent développer et maintenir lesdits clients. D’ailleurs, le 4 janvier 2021, la plus puissante de ces (trois) entités ne devrait accepter de connexion à ses services que depuis son propre client ou celui des 2 autres, tandis que la moins puissante en est réduite à mettre de la pub dans la barre d’adresse de son client.
* En se complexifiant, le Web est aussi devenu lourd. Il pèse sur les serveurs (je ne sais pas si la mode du Jamstack et des CMS statiques aura un impact positif là-dessus) et sur les clients (mais ça, on en avait déjà parlé dans les commentaires de ce journal sur Brave). Ne serait-ce qu’écologiquement, le fait qu’il faille un smartphone à 2 Go de RAM pour faire scroller un site moderne n’est pas de très bon augure.
* Vous connaissez la blague : aujourd’hui le Web, c’est 5 sites, chacun remplis de photos des 4 autres. Les portails de jadis ont muté en réseaux sociaux qui ont centralisé le Web, au grand dam de ses créateurs comme Tim Berners-Lee qui envisageaient le fonctionnement inverse.
* Et le pistage. Seigneur, le pistage. Vous imaginez si en l’an 2000, un voyageur du futur vous faisait lire le RGPD ?
Voici pour les problèmes. À présent, laissez-moi vous parler des solutions. J’en ai découvert récemment deux, mais je vais avoir besoin de vous pour mieux comprendre en quoi elles consistent.
Gemini
D’où ça sort ?
D’un certain Solderpunk, avec le soutien notable de Drew DeVault, illustre hacker minimaliste connu pour le gestionnaire de fenêtres Sway et le réseau de code Sourcehut. DeVault s’est beaucoup lamenté de l’état du Web, et notamment de Mozilla à l’occasion de la récente vague de licenciements. Depuis quelques mois, il a donc travaillé à cette alternative.
Qu’est-ce que c’est ?
Gemini est un protocole. DeVault explique sur son blog que c’est « une évolution de Gopher ». Ne me demandez pas ce que c’est Gopher, je n’en sais pas plus que ce qui est écrit sur sa fiche Wikipédia.
Et donc, ça fait quoi ?
Ça fait des sites très, très minimalistes.
Les pages Gemini sont écrites dans un dialecte de Markdown réduit à peau de chagrin. On ne peut même pas mettre plus d’un lien par ligne ! Pour la décoration, ça se fait exclusivement côté client. D’ailleurs, pour surfer sur Gemini, il vous faut un client dédié, ou alors passer par une surcouche HTML telle celle liée ci-dessus.
En d’autres termes (si j’ai bien tout compris) Gemini est spartiate et compte bien le rester. La FAQ officielle de Gemini explique que le protocole est conçu pour être difficilement extensible, notamment dans un souci d’empêcher tout pistage. Elle explique également que la mission de Gemini n’est pas de remplacer le Web, mais simplement de proposer une alternative pour ceux qui préfèrent consulter du contenu ainsi.
Contrairement à la deuxième alternative dont je vais vous parler :
Solid
D’où ça sort ?
De Tim Berners-Lee en personne. Le patron du W3C y pense depuis 2009, et le projet Solid proprement dit existe depuis déjà 4 ans.
Qu’est-ce que c’est ?
Ce n’est pas exactement une alternative au Web, puisque Solid, que ses créateurs qualifient de plateforme, est fondamentalement un serveur qui fonctionne via le Web. Mais l’ambition du projet, résumée dans sa bio Twitter, est bien de remplacer le mode de fonctionnement actuel du Web par un système réellement décentralisé, où les utilisateurs contrôlent leur contenu, comme les ingénieurs du CERN l’avaient pensé dès le départ.
Et donc, ça fait quoi ?
C’est là que j’ai du mal à comprendre. J’ai ouvert un “pod” (c’est comme ça que ça s’appelle) sur une des 3 instances mises en avant sur le site officiel de Solid, et voilà à quoi ça ressemble :
Là-dessus, ne trouvant pas de documentation à l’usage des simples utilisateurs, j’ai commencé à cliquer un peu partout pour voir ce qu’il se passait, et j’ai pas eu l’impression qu’il se passait grand-chose. Le « pod browser » proposé sur Inrupt (la société commerciale de Berners-Lee) est moins moche, mais ressemble à une sorte de stockage nuagique sommaire – où je n’ai pas trouvé comment partager de contenu. Sans quoi, votre “pod” vous permet également de vous connecter à des applis ; là encore, sur les deux que j’ai testé, une (Notepod) n’avait rien de spécial, l’autre (Twee-Fi) m’affiche des pages vides. Je me trompe peut-être, mais tout ceci me semble encore très peu utilisable.
Et donc, comme je disais en titre de ce journal : faut qu’on m’explique. J’imagine bien qu’aucune de ces deux approches a vocation à résoudre tous les problèmes du Web, mais les démarches me paraissent intéressantes, et je serais curieux d’entendre votre avis éclairé à ce sujet.
En attendant, il y a un truc que je connais (un peu) mieux : l’IndieWeb, ce mouvement qui prône des pratiques de développement loin des plateformes fermées, en s’appuyant sur des technologies cool comme le Fediverse mais aussi les microformats, les Webmentions ou encore IndieAuth. Je me suis basé sur ces préceptes pour coder mon propre site ces derniers jours, et je compte bien continuer à creuser le sujet. en attendant de pouvoir proposer un site Gemini à visiter depuis son raspi400 ou bien son Mutida Pure :)
# jamais entendu parler de solid, mais gemini si
Posté par freem . Évalué à 6.
Et j'ai lu les specs d'ailleurs. L'un des trucs qui m'ont marqué, c'est le fait que ça spécifie explicitement une dépendance a un protocole de chiffrement.
Ce qui est triste, parce qu'il n'y a aucune raison de faire ça, et je pense même que ça risque de bloquer l'évolutivité à plus ou moins court terme, la ou les gens qui fournissent des fichiers via http, s ou pas s, peuvent juste exposer un serveur http sur un port, et un proxy pour le chiffrement sur un autre port qui appelle le 1er (c'est ce que j'ai sur mon serveur: darkhttpd sur lo::8080, hitch sur lo::8443 qui redirige sur lo::8080, et des règles iptables qui redirigent comme il faut les ports par défaut).
Bref, pour du minimalisme, c'est raté de mon point de vue.
Je suis aussi sur un IRC ou ça aime causer de ce genre de trucs, et je suis pas le seul a avoir relevé ce point, même si ça veut rien dire.
Il y avait d'autres points que j'ai relevé, mais je me souviens plus.
Au final, je ne vois pas l'intérêt. De mon point de vue, c'est bien moins chiant d'exposer un serveur http qui laisse le client explorer l'arborescence et faire sa propre interface.
En aucun cas, un client http ne se doit d'être un client web, et tous les clients web que je connais sont loin d'avoir les fonctionnalités que j'attendrai d'un navigateur: je suis obligé d'utiliser les liens fournis par un document pour pouvoir trouver les autres ressources, je ne peux donc pas naviguer, et encore moins explorer, mais soyons honnêtes: c'est pas la faute de http si les gens ne s'en servent (quasi) que pour exposer des fichiers html (qui sont le vrai problème pour moi) et des scripts cgi.
Pour rappel: HTTP veut dire «HyperText Transfer Protocol». Et non «Hyper bloaTed Transfer Protocol». Au final, c'est le même problème qu'il y a eu (qui se calme, il me semble) avec XML: utilisé pour tout et surtout pour n'importe quoi, sans exploiter les vraies fonctionnalités. Encore que, XML au moins a encore un standard et des specs claires, qui ne changent pas selon le vent, lui.
Cela dis, je m'en vais creuser autour de ton autre machin, on sait jamais.
PS: pour gopher, il existe dooble qui est un navigateur web tout en supportant gopher. C'est un peu moins inconfortable que les clients de type cgo (par exemple) ou les proxy web, mais on y voit, justement, les limitations d'un protocole couplé à un format de fichier (ce qu'est en réalité gopher, tout comme gemini) «minimaliste».
[^] # Re: jamais entendu parler de solid, mais gemini si
Posté par freem . Évalué à 7.
[edit]
Bon, ok, solid, en fait, ça a juste l'air d'un gros bloatware aussi. Ce qui a l'air du site officiel mets 3 plombes a charger avec la co pourrie que je me tape depuis quelques temps (déménagement à la cambrousse, initié pile avant le 2nd confinement…), à savoir 130Ko/s le vent dans le dos.
Pour comparaison, les pages gopher sont quasi instantannées, et pèse moins de 1meg.
Sans lien plus pertinent, je dirais donc: Solid? Dans la poubelle grise.
# Plus qu un protocole, une porte lights.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Moi ce que j aimerai parfois quand ma connection galère c est pouvoir me connecter sur le web mais via un portail qui dépouille tout et compresse un max. Genre pas d encapsulation https, on vire les pubs, on simplifie les site, au moins pour les plus populaire avec des APIs on peut faire ligth. Et on remplace le XML par le plus ligth des protocoles genre protobuf de Google.
Gemini est une étape mais c est encore trop lourd.
Pour consulter les nouvelles un texte de 1000 caractères suffisent amplement : 1ko non compressé…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Plus qu un protocole, une porte lights.
Posté par ted (site web personnel) . Évalué à 6.
Le navigateur mobile Opéra Mini fait plus ou moins ça, mais ça implique qu'ils font passer le contenu des pages qui te sont destinées par leurs serveurs. Sinon, c'est aussi un peu ce que je fais grâce aux flux RSS/Atom quand les sites web le proposent (mais il y a aussi des programmes ou services en ligne qui permettent de se débrouiller pour les sites qui n'en ont pas).
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Plus qu un protocole, une porte lights.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
Dans ces conditions évidemment que l'on accepte la perte de confidentialité car il faut a minima que le portail puisse voir ce que l'on consulte pour virer ce qui n'est pas nécessaire. Évidemment que l'on ne peut pas avoir le beurre et l'argent du beurre.
Je connaissais pas Opéra Mini, ça me dérange pas de passer par leur serveur, mais j'aimerai que le le navigateur soit Open Source. (Ils abusent de dire "Navigation sécurisée et privée" juste parce que il y a le mode ou on garde pas les cookies…)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Plus qu un protocole, une porte lights.
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 6.
C'est ce que pèse un fichier .gmi avec le même nombre de caractères, modulo une dizaine de caractères pour la syntaxe (j'ai testé en téléchargeant quelques pages au pif). Qu'est-ce qui fait que selon toi, Gemini "c'est encore trop lourd" ?
[^] # Re: Plus qu un protocole, une porte lights.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
Je me trompe peut-être. Mais Gemini de ce que j'ai compris ne permet pas d'aller sur LinuxFR, sur ma messagerie, sur Google ou Facebook… C'est un réseau a part.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Plus qu un protocole, une porte lights.
Posté par freem . Évalué à 6.
Gemini n'est pas un réseau mais un protocole réseau doublé d'un format de fichier.
Le web n'est pas non plus un réseau, mais un ensemble de protocoles doublé d'un ensemble de formats de fichiers.
Facebook n'est pas non plus un réseau, mais un site web, sur lequel peuvent éventuellement se construire ce que l'on appelle des réseaux sociaux, c'est à dire entre personnes.
Je pourrais très bien décider d'héberger un serveur HTTP et héberger uniquement des fichiers de texte brut. Ça ne serait pas le web, les navigateurs standards seraient à chier dessus parce qu'ils considèrent que l'interface graphique est le boulot du site web. Pour moi, ces logiciels que sont firefox, chromium et safari ne sont même pas dignes du titre de "navigateur", ce sont au mieux de (mauvais, très mauvais même) outils de téléchargement et de rendu de "documents HTML5", ce qui est la seule chose qu'ils arrivent à peu près à faire correctement.
Certains sites web bâtissent des réseaux, c'est vrai. Au travers notamment des «rings», mais c'est un peu un truc du passé, ça.
[^] # Re: Plus qu un protocole, une porte lights.
Posté par ploum (site web personnel, Mastodon) . Évalué à 5.
Sur Linuxfr, si.
Je me souviens d'être tombé, au hasard de mes pérégrinations sur Gemini, sur un proxy qui « traduisait » Linuxfr pour le rendre disponible sur Gemini. Wikipedia est disponible de la même façon.
J'adore Gemini, je suis complètement fan.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Plus qu un protocole, une porte lights.
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
Pour ceux que ça intéresse, je viens de faire un article qui détaille ma vision de Gemini et pourquoi j'en suis fan.
https://ploum.net/gemini-le-protocole-du-slow-web/
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Plus qu un protocole, une porte lights.
Posté par Anonyme . Évalué à -3.
Désolé, je peux pas ne pas faire cette remarque : est-ce que c’est à ranger à côté de ton article qui détaille ta vision d’Elon Musk et à quel point tu en es fan ?
[^] # Re: Plus qu un protocole, une porte lights.
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Tu dois confondre avec un autre, je ne vois pas de quoi tu veux parler.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Plus qu un protocole, une porte lights.
Posté par Anonyme . Évalué à -4.
Je sais pas, c’est pas toi @ploum, auteur de Printeurs qu’on peut contacter pour toute question ou soutenir ton travail ?
C’est pourtant ce qu’il y a d’écrit à côté de l’article « Elon Musk est-il un voyageur du futur ? ».
[^] # Re: Plus qu un protocole, une porte lights.
Posté par ploum (site web personnel, Mastodon) . Évalué à 8.
L'article que tu mentionnes ne fait que mentionner, sur un ton humoristique, l'analogie entre Elon Musk et un personnage de roman. Je n'y fait à aucun moment part de mon admiration pour le personnage (que je n'ai jamais spécialement éprouvé même si je trouve son parcours initial particulièrement intéressant et même si, dernièrement, sa part d'ombre semble ressortir particulièrement).
Je ne vois pas non plus le rapport avec Gemini. Mes articles sont de toutes façons entièrement personnels, libre à chacun d'y prendre ce qu'il a envie. Je ne comprends pas ce que t'essaye de démontrer. (enfin si, j'avais une hypothèse : "Elon Musk est le mal absolu en 2020 -> En 2016 Ploum a écrit un article qui parle d'Elon Musk -> Tout ce que ploum écrit est mal" mais cette hypothèse me semble d'une logique tellement puérile et facebookienne que je l'ai repoussée immédiatement en me disant qu'on est sur Linuxfr ici, pas sur Facebook)
Mes livres CC By-SA : https://ploum.net/livres.html
# Gopher
Posté par tisaac (Mastodon) . Évalué à 7.
Plus d'information sur Gopher d'après un site de grande qualité ? C'est par là !
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Gopher
Posté par Denis Bernard (site web personnel) . Évalué à 6. Dernière modification le 26 novembre 2020 à 02:46.
J'ai lu (en diagonale) la présentation de Gemini et sa FAQ. Ma première impression est que son auteur n'a pas compris le protocole Gopher de la même manière que je le comprend. Voici mon point de vue.
Il existe une rfc 1436 "Informational" dont leurs auteurs on déclarés à l'époque de sa sortie (1993) quelle avait pour but de stabiliser la précédente version de Gopher alors qu'ils publiaient la nouvelle spécification "Gopher+" (disponible sur ce site).
Bien plus tard, en 2005, est sorti la la rfc 4266 portant "The gopher URI Scheme" qui, elle, est en catégorie "Standards Track". Clairement, la rfc 4266 fait bien état du protocole Gopher+ totalement ignoré (ou snobé ?) par le projet Gemini. Il se trouve que bien des lacunes relevées à juste titre par le projet Gemini concernant la première version stabilisée de Gopher telle que décrite dans la rfc 1436 sont comblées avec la seconde version du protocole Gopher dite "Gopher+".
Alors je m'interroge sur la démarche des porteurs du projet Gemini : le lien ci-dessus vient du site de Goerzen (personnalité bien connue du petit monde Gopher) et on trouve aisément cette feuille de route pour Gopher+ un peu partout dans le gopherspace.
Le second volet de mon commentaire concerne les définitions du Web d'une part et celle de la page Web d'autre part.
Ma définition du Web est celle d'un espace sur Internet partagé par des protocoles qui ont tous en commun le fait d'être accessible par une URI (ftp://, gopher://, http://, telnet://, etc). La notion d'URL a été gravée dans le marbre avec la rfc 1738 en 1994 par deux auteurs : T. Berners-Lee, que l'on ne présente plus, et M. McCahill qui était le leader de l'équipe Gopher. On présente souvent le projet du World Wide Web comme rival à celui de Gopher alors que les deux équipes ont toujours collaboré ensemble. Ces deux projets avaient des buts absolument différents et n'empiétaient en rien l'un sur l'autre. Il est navrant de confondre Web et World Wide Web. L'un est la toile que l'on peut parcourir avec l'un des quelconques protocole (ftp, telnet, http, gopher, wais… et j'en oublie) et l'autre une suite de protocoles porté par le W3C.
Concernant la définition de la page Web, on touche le cœur du problème ! D'abord on devrait dire "page de texte encodé en HTML" (plus divers autres encodages). Rien n'interdit de télécharger un fichier Text/html depuis un serveur ftp ou Gopher ! Certes, on peut dire que la grosse nouveauté du format HTML a été l'en-tête apportant tout un tas de renseignements intéressants. Mais Gopher+, apporte également bien des renseignements nécessaires à n'importe lequel des fichiers à télécharger (contrairement à la version première de Gopher).
Enfin, et je crois que c'est le fond du projet Gemini), la définition de "page Web". Je pense qu'on est bien d'accord que le souci principal est le côté "métier du livre" qui n'est pas un métier facile. On ne sait toujours pas bien faire un traitement de texte et seulement un ou deux squattent le marché. De même pour le format PDF. Et là, on voudrait avoir ces deux logiciels en un…
À ce que j'ai compris des fanatiques (le mot n'est pas trop fort !) du protocole Gopher : ils sont nostalgiques des anciens BBS. Alors ils détournent l'usage premier des menus Gopher, qui ne sont strictement qu'une liste ordonnée de liens, en y incluant des lignes de texte débutants par la balise de type "i" (qui est non officielle mais reconnue par "Lynx" qui domine tous les navigateurs Gopher). Ce contournement permet de présenter une "page Web" en mode texte avec des liens mais sans le très honni HTML.
Reste le volet de la sûreté des communications. Un faux problème, à mon avis ! En effet, le protocole Gopher transporte en clair et sans authentification. Mais si on veut brouiller ou authentifier, rien n'interdit d'encapsuler Gopher sous HTTP(S). Déjà, en 1996, la rfc 1945 pour HTTP/1.0 prévoyait le transport d'autres protocoles comme SMTP, NNTP, FTP, Gopher et WAIS. Et c'est toujours le cas dans la section 1.1 de la rfc 2616 pour HTTP/1.1 .
# Solution technique à un problème économique
Posté par ted (site web personnel) . Évalué à 10.
Je trouve moi aussi que le web est devenu lourd, lent, désagréable. La navigation sans bloqueur de pub est un calvaire. Mais je n'imagine pas que ces projets soient une solution: les personnes susceptibles d'utiliser ces solutions sont très bien capable de faire un site web correct, et pour les autres ça ne changerait donc rien.
Même aujourd'hui (et encore plus aujourd'hui) on peut toujours faire des choses très bien avec du HTML, HTTP, CSS voire JavaScript, mais ce n'est pas la priorité des entreprises.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Solution technique à un problème économique
Posté par freem . Évalué à 10.
On peut pas faire un client correct supportant ces techno, de nos jours.
C'est ça que ces projets (enfin, surtout gemini) essaient de résoudre: avoir des specs claire, implémentables aisément, et pas réservées à google, apple et mozilla.
Enfin, si tu dis qu'on peut, vas-y, je suis curieux de voir le résultat (les gens de netsurf essaient depuis des années, ils avancent, mais ils en bavent, et sont très loin de supporter correctement les "specs" de html5).
[^] # Re: Solution technique à un problème économique
Posté par gnumdk (site web personnel) . Évalué à 8.
HTML4 quoi…
[^] # Re: Solution technique à un problème économique
Posté par Clément V . Évalué à 3.
SGML est une syntaxe trop horrible, l'XHTML2 c'était bien.
[^] # Re: Solution technique à un problème économique
Posté par Glandos . Évalué à 7.
HTML5, CSS3 et leurs évolutions sont beaucoup plus du côté de JavaFX et Qt que de HTML4 / CSS1. C'est pour faire des applications complètes. Donc oui, faire des logiciels capables de tout gérer, c'est vraiment pas évident.
Et faut dire que la combinaison HTML5 et CSS3 a permis la mort de Flash. C'est pas beautiful ça ?
[^] # Re: Solution technique à un problème économique
Posté par vv222 . Évalué à 9. Dernière modification le 25 novembre 2020 à 11:43.
Mouais, je dirais plutôt que HTML5 + CSS3 + JS sont le nouveau Flash.
On a remplacé Adobe par Google, je ne pense pas qu’on gagne au change.
[^] # Re: Solution technique à un problème économique
Posté par vieille_moule . Évalué à 3.
Si pour la simple raison que ça marche partout et en libre.
[^] # Re: Solution technique à un problème économique
Posté par vieille_moule . Évalué à -1.
GEMINI ne se prédestine pas aux entreprises du coup, je ne vois toujours pas son intérêt.
Ce genre d'utilisateur sait coder proprement un site web en HTML/CSS avec un respect sémantique.
Que des sites issues de vox.com ou facebook ne marchent pas parfaitement avec netsurf, ben, on s'en fout un peu non?
Et il y a tout de même QtWebEngine et WebkitGTK en libre donc on n'est pas obligé non plus de revenir au TeleType.
Personnellement, je n'aime pas le côté extrêmiste derrière la mouvance gemini, faudrait garder à l'esprit que Drew est un autiste d'un certain degré avec des sensibilités questionnables.
[^] # Re: Solution technique à un problème économique
Posté par freem . Évalué à 2.
Perso, je constate déjà que même linuxfr.org ou lwn.net ne marchent pas avec dillo, et de mémoire pas non plus avec netsurf-gtk (de mémoire, parce que je le trouve pas dans aptitude, je creuserai plus tard).
Ce ne sont pas des sites qui sont a franchement parler bourrés de JS et autres cochonneries, pourtant. Non, c'est juste cet horrible CSS.
En même temps, tous les moteurs de rendu actuels sont libres. C'est pas le souci.
[^] # Re: Solution technique à un problème économique
Posté par patrick_g (site web personnel) . Évalué à 9.
La réponse, assez convaincante je trouve, est dans la FAQ.
The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. Simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they can't. You can do all this with a client you wrote yourself, so you know you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
# Frogans
Posté par Lutin . Évalué à 2.
Dans le même genre d'idée il y a Frogans. C'est un réseau à part (pas du web quoi) et il n'y a a peu près personne qui l'utilise.
[^] # Re: Frogans
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
Tu m'étonnes, y'a marqué sur leur site que le seul client dispo n'est "pas prévu pour le grand public". La démarche me paraît beaucoup moins claire que celle de Gemini, qui lui a des clients qui fonctionnent et même des utilisateurs.
Et puis euh, vous avez vu la gueule des sites ?
(j'ai essayé de lancer Frogans Player en version Windows, il me sort "File containing fonts not found" et c'est tout. J’essaierai la version Linux quand il y aura un Flatpak.)
[^] # Re: Frogans
Posté par HL . Évalué à 2.
Le targz est fonctionnel (par contre je n'ai pas trouvé les sources).
# NEwS
Posté par karteum59 . Évalué à 10. Dernière modification le 25 novembre 2020 à 13:05.
Il y a bien longtemps (dans une galaxie lointaine, très lointaine), un système de fenétrage appelé NeWS (Network Extensible Window System) voyait le jour chez Sun Microsystems.
D'après ce que j'en ai compris, il reposait sur Display Postscript, aussi bien côté client que serveur, ce qui avait pour avantage
https://news.ycombinator.com/item?id=11477565
https://news.ycombinator.com/item?id=22455722 (discussion intéressante même si ça montre que tout le monde n'adhère pas au concept…)
https://wiki.c2.com/?NetworkExtensibleWindowSystem
# Ils se sont inspiré de Matrix pour les noms ?
Posté par Anonyme . Évalué à 2.
Encore des noms super faciles à chercher sur les moteurs de recherches. Geminispace, sérieux ?
[^] # Re: Ils se sont inspiré de Matrix pour les noms ?
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 25 novembre 2020 à 16:51.
Si je tape "geminispace" avec les guillemets dans un moteur de recherche réputé pour la qualité de ses résultats, je tombe bien sur des résultats en rapport avec le protocole Gemini (après un TikTok, un Insta et un Twitter qui portent le même nom, certes). Et oui, le nom est directement inspiré du programme de la NASA.
# Le maxitel ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Une approche complémentaire serait d'avoir:
Pour ce dernier, je propose de virer HTML et CSS :-)
On garderait:
Lorsque l'on se connecte sur https://monappli.com, le brouteur:
De quoi est composé le contexte? Cela dépends:
Le script app.js a de quoi interroger le contexte pour savoir quel rendu et quelles interactions il peut faire.
Ainsi on obtient un "maxitel" (simple comme un minitel mais avec presque tout côté client) facile à implémenter (un interpréteur et quelques API simples, mais pas des normes gigantesques et imbitables comme HTML+CSS).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Je pourrais vous parler de Solid pendant longtemps :)
Posté par AlPog . Évalué à 5.
Salut !
Certe si on va sur les supports de communication officielle de Solid on peut être un peu perdu. Le projet Solid à la base c'est un projet de standardisation d'API. Aprés c'est dans son implémentation et dans les enjeux sociétaux qu'il porte que le sujet devient passionnant.
J'ai écrit un article de vulgarisation sur le sujet :
FR : https://blog.orgtech.fr/un-avenir-solid/
EN : https://startinblox.com/blog/
Je serais ravie d'avoir des retours!
En France, il y a deux acteurs majeurs qui travaillent sur le sujet de l'interopérabilité via les spécifications Solid : L'Assemblée Virtuelle (asso) et Startin'blox (coop). J'ai un pied dans le deux, et je suis toujours ravie d'échanger :)
Un sujet qui m'a également passionné ces temps en terme de web plus efficient c'est le projet RINA (https://fr.wikipedia.org/wiki/Recursive_Internetwork_Architecture), je vais essayer de sortir bientôt une serie d'article pour vulgariser ce projet si intéréssant d'internet non ip!
[^] # Re: Je pourrais vous parler de Solid pendant longtemps :)
Posté par dzecniv . Évalué à 3.
Mais c'est qu'on dirait que les applications avec Solid existent !
J'attends tes prochains articles !
(je cite ton article)
La coopérative Startin’blox propose une solution open source pour créer des applications Web en assemblant des composants Solid, aussi simplement que l’on peut créer un site Web avec Wordpress.
Une première application basée sur le framework Startin’Blox, Hubl, illustre ses possibilités en matière d’interopérabilité entre organisations. Hubl propose aux collectifs de freelances des modules tels qu’une messagerie instantanée, un job board pour les offres de mission, un annuaire de profils, etc. Chaque collectif peut décider des modules mis en oeuvre et des données qu’il souhaite partager. Il est désormais possible d’interconnecter collectifs et indépendants au sein d’un écosystème, sans qu’une plateforme ne dicte ses règles aux participants ni n’utilise sa position d’intermédiaire incontournable pour extraire une rente économique !
https://hubl.world/fr/
L’Assemblée Virtuelle est un écosystème associatif d’acteurs développant de manière collaborative des communs (outils open source, méthodologies et projets) basés sur le Web sémantique et Solid, au service des acteurs de la transition.
https://www.virtual-assembly.org/
# Podcasts sur Solid
Posté par AlPog . Évalué à 2.
J'ai monté un podcast pour expliquer le projet solid et ses enjeux, le tout en moins de 15 minutes :)
https://startinblox.com/blog/index.php/fr/2020/11/30/podcast-de-la-residence-de-juin-2020/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.