Add informations about heylo

content/docs/acides/contact.md

@@ -10,6 +10,8 @@ salons de discussion [Matrix](https://matrix.org).
 - **Salon principal** : `#acides:tedomum.net`
 - **Projet hepto** : `#hepto:tedomum.net`
 - **Projet hiboo** : `#hiboo:tedomum.net`
+- **Projet heylo** : `#heylo:tedomum.net`
+- **Projet hicso** : `#hicso:tedomum.net`
 
 L'ensemble des salons est accessible à tous. N'hésitez pas à rejoindre, vous
 présenter, et participer directement aux échanges.
\ No newline at end of file

content/docs/heylo/_index.md

+---
+title: heylo
+---
+
+## Contexte
+
+Les réseaux fédérés sont difficiles à rejoindre, c'est un fait : non seulement comme sur tout réseau à protocole ouvert, il faut choisir un client, mais en prime il faut trouver un serveur. L'idée n'est déjà pas triviale pour la plupart d'entre nous, mais plus que l'esprit, c'est la mise en application qui est factuellement complexe. Prenons `joinmastodon.org`, l'un des sites d'*onboarding* les plus complets : les détails sur le fonctionnement de mastodon sont là, mais il y a très peu d'information sur ce qu'est le fediverse, et sur le fait que d'autres logiciels existent, d'autres approches au microblogging ou aux réseaux sociaux décentralisés ; la liste est très restreinte sans qu'il soit aisé d'avoir des explications détaillées. A l'inverse, `instances.social` ou `the-federation.info` sont soit très limités en méta-données, soit clairement orientés statistiques techniques, et n'aident pas vraiment les novices à faire un choix.
+
+Prenons maintenant le cas de Matrix plutôt que du *fediverse* ou de Mastodon : le meilleur site d'*onboarding* est probablement `matrix.org`, qui est toutefois techniquement complexe. De nombreux articles de blog couvrent le sujet mais manquent de consolidation. Il reste des listes de serveurs (`publiclist.anchel.nl`, `hello-matrix.net` par exemple), qui se concentrent sur des données techniques et autres statistiques.
+
+Pourtant, **en tant que** novice, **je souhaite** lire un petit peu de documentation didactique, qui me pointe vers des instances en fonction de langues que je parle, de mes convictions, du type de contenu que j'apprécie. Je souhaite me faire une idée de l'écosystème de cette instance, qui la gère, selon quel modèle économique, ce qu'ils peuvent faire de mes données, si je pourrai les récupérer, ou me faire oublier. Je souhaite le faire aussi bien pour mon nouveau compte Matrix que pour du micro-blogging, ou de la publication de vidéos.
+
+**En tant que** gestionnaire d'instance, **je souhaite** déclarer ces informations sur mon instance, accessibles et affichables par un client, je souhaite maîtriser la diffusion des informations de mon instance sur des sites tiers, sans m'inscrire séparément sur chacun, sans devoir m'y connecter chaque fois que je mets à jour des informations.
+
+## Projet
+
+En une phrase, heylo est donc un projet visant à faciliter l'accueil de nouveaux-venus sur les réseaux sociaux fédérés, en axant les travaux sur :
+
+ - l'élaboration et la promotion d'un standard de publication d'informations détaillées sur une instance ;
+ - un site informatif comprenant guides et outils de choix pour rejoindre un réseau social fédéré et choisir une instance.
+
+La première critique que nous devrions recevoir : nous réinventons la roue. Une partie des fonctionnalités que nous visons existent déjà, soit dans *nodeinfo*, soit dans des sites de listes d'instances ou de documentation. Nous pourrions donc bien entendu contribuer à ces projets plutôt que de diviser encore les efforts en créant une nouvelle initiative.
+
+C'est possiblement ce que nous ferons. L'objet est de débuter de rien pour itérer rapidement sans penser aux contraintes de compatibilité, sans être retenus par un existant, en avançant à notre rythme en dehors de tout écosystème. Forts de cette aventure, nous pourrons absolument  contribuer les produits dans des projets existants, ou bien à l'inverse les codes et standards étant libres ils pourront être importés par qui le souhaite.
+
+Pour répondre aux *use cases* gestionnaire, il est préférable que les métadonnées soient hébergées directement sur l'instance. L'approche de *nodeinfo*, complétée par du *scrapping* semble donc la plus pertinente dans cette direction. Il est possible de faire évoluer *nodeinfo*, ou de proposer un schéma alternatif. L'approche retenue est le schéma alternatif, au minimum le temps d'itérer dessus, de tester des représentations, avant soit de combiner une évolution majeure de nodeinfo, soit de se présenter en alternative ou complément.
+
+Les « manifestes » ainsi publiés doivent exposer aussi bien des données techniques sur l'instance que des méta-données. Ils doivent être multi-lingues au minimum dans les langues supportées par l'instance. Ils doivent être simples à écrire, donc ne pas imposer de trop nombreux champs obligatoires en incitant pour autant à être le plus complets possible pour orienter les novices. Ils doivent offrir des champs contrôlant la diffusion de l'information sur des sites tiers.
+
+Pour répondre aux *use cases* novices, il est souhaitable de disposer d'un site Web localisé présentant les concepts de fédération, rassurant à la lecture. Le site devrait présenter une liste d'instances, filtrable sur des critères clairement affichés, accompagnés d'un assistant, proposant des critères suites à 2 ou 3 questions simples. Aucune instance ne devrait être mise en avant parmi celles répondant aux critères.
+
+L'ensemble des standards et codes sources doit être sous licence libre ou libre de droits.
+
+## Symbolique
+
+Le projet est nommé « heylo » : nous nous sommes tous déjà retrouvés sur un salon de discussion à ne pas savoir comment se présenter, à saluer par « hey » ou par « hello » ; ce sentiment n'est que l'ombre de ce que ressent un novice face à la diversité et parfois la complexité d'un réseau social fédéré.
+
+Le logo représente un lecteur conformément à la convention de nommage ACIDES.
+
+## Historique
+
+Le projet heylo est né en 2021 en constatant la difficulté à embarquer de nouveaux utilisateurs dans l'écosystème Matrix alors même que des migrations importantes depuis Whatsapp vers Signal s'opéraient.
\ No newline at end of file

content/docs/heylo/concepts.md

+---
+title: Principes du manifeste
+---
+
+Heylo est non seulement une plateforme de documentation et d'accueil sur les réseaux sociaux
+fédérés, mais c'est aussi un standard destiné à décrire les instances afin de faciliter le
+choix des utilisateurs, voire de les accompagner au quotidien dans leur usage de l'instance.
+
+# Principes
+
+Le format Heylo est un format de manifeste, publié par une instance. La définition du contenu
+du manifeste est à la discrétion de l'instance, dans les limites du format. Les données sont
+déclaratives.
+
+En publiant un manifeste au format Heylo, une instance accepte *de facto* qu'il soit récupéré
+automatiquement par des robots afin d'enrichir des plateformes comme Heylo. Le manifeste contient
+une directive de diffusion de cette information, que les plateformes doivent toutefois respecter
+afin de ne pas republier l'information d'un manifeste qui ne l'a pas explicitement accepté.
+
+La majorité des champs dans un manifeste est optionnel, de sorte que chaque instance peut choisir
+quel niveau de données elle publie. Chaque plateforme exploitant les manifestes est libre de
+représenter ou non l'intégralité des données, de sélectionner ou non les manifestes en fonction
+des champs remplis ou de leur valeur.
+
+Les plateformes exploitant les manifestes sont libres d'en corriger les champs par des valeurs
+obtenues factuellement, par exemple concernant les statistiques, à condition que la correction
+soit mentionnée explicitement et qu'elle ne diffusent pas plus d'information que l'instance a
+choisi d'en exposer. De même, ces plateformes sont libres de cesser de diffuser les informations
+d'une instance si elles constatent que ces informations sont erronnées ou trompeuses.
+
+Il n'existe pas de versions du standard : la seule syntaxe reconnue est celle définie à date dans
+cette documentation. Un manifeste qui ne respecte pas cette syntaxe n'est pas un manifeste valide.
+Les robots de Heylo pourront vous avertir lorsque votre manifeste n'est plus valide, et une
+communication sera organisée lorsque des changements importants sont apportés au standard.
+
+Lorsqu'une instance cesse de publier un manifeste ou que son manifeste publié est invalide, les
+plateformes sont invitées à en conserver une version pendant la durée précisée dans le manifeste,
+mais pas plus longtemps. Une durée plus longue permet une plus grande résilience et une plus grande
+souplesse en cas de défaut, mais un oubli plus lent en cas d'arrêt des services.

content/docs/heylo/manifest.md

+---
+title: Format de manifeste
+---
+
+Un manifeste est un objet structuré contenant des listes et des dictionnaires clé-valeur, encodé au format JSON. Toutes les chaînes sont
+encodées en UTF8.
+
+# Types spécifiques
+
+## Objet internationalisé
+
+Un objet internationalisé est un objet dont les clés sont les code langue au format [ISO 639-1](https://fr.wikipedia.org/wiki/Liste_des_codes_ISO_639-1) et les valeurs localisées (traduites) de l'objet. Tout objet internationalisé doit comporter une localisation dans chacune des langues supportées par l'instance (voir les champs à suivre).
+
+Exemple d'une chaîne internationalisée :
+
+```
+{
+    "en": "hello, world!"
+    "fr": "bonjour le monde !"
+}
+```
+
+Exemple d'une liste de chaînes internationalisée :
+
+```
+{
+    "en": ["good", "bad"],
+    "fr": ["bon", "mauvais"]
+}
+```
+
+## Références
+
+Les références sont :
+
+ - soit des URL entièrement qualifiées précisant le schéma ;
+ - soit des adresses locales à la fédération de l'instance décrite.
+
+Pour indiquer une adresse d'une autre fédération, il est impératif de préciser une URL complète.
+
+## Catégories de contenu
+
+Les catégories de contenu font référence à une liste de types de contenu et leurs définitions.
+
+**TODO** : une première version de cette liste est à proposer.
+
+# Structure du manifeste
+
+Le manifeste est un objet JSON, dont les clés et valeurs attendues sont détaillées ci-dessous.
+
+Chaque clé présentée est optionnelle mais les clés principales suivantes doivent être renseignées :
+
+ - `federation` ;
+ - `service` ;
+ - `instance` ;
+ - `name` ;
+ - `display` ;
+ - `languages` ;
+ - `updated`.
+
+## `federation`
+
+Fédération à laquelle l'instance est rattachée, sous forme d'une chaîne.
+
+Valeurs acceptées :
+- `matrix`, désignant la fédération Matrix ;
+- `activitypub`, désignant le Fédivers ActivityPub ;
+- `xmpp`, désignant la fédération Jabber / XMPP ;
+- `smtp`, désignant la fédération e-mail / SMTP ;
+- `diaspora`, désignant la fédération Diaspora.
+
+## `service`
+
+Type de service offert par l'instance au sein de la fédération.
+
+Valeurs acceptées pour une fédération `matrix` :
+- `chat`, désignant une instance de messagerie ;
+- `services`, désignant une instance de publication de services ou de bridges.
+
+Valeurs acceptées pour une fédération `activitypub` :
+- `microblog`, désignant une instance de micro-blogging (type Mastodon, Pleroma) ;
+- `video`, désignant une instance de publication de vidéos (type PeerTube) ;
+- `audio`, désignant une instance de publication d'audio (type Funkwhale) ;
+- `blog`, désignant une instance de publication d'articles (type Plume ou WriteFreely) ;
+- `picture`, désignant une instance de publication d'images (type Pixelfed) ;
+- `links`, désignant une instance de partage de liens (type Lemmy ou Prismo).
+
+Valeurs acceptées pour une fédération `xmpp` :
+- `chat`, désignant une instance de messagerie.
+
+Valeurs acceptées pour une fédération `smtp` :
+- `email`, désignant un serveur e-mail standard ;
+- `lists`, désignant un serveur de listes de diffusion.
+
+Valeurs acceptées pour une fédération `dispora` :
+- `microblg` désignant une instance Diaspora standard.
+
+## `instance`
+
+Nom technique de l'instance, tel qu'il est employé pour la découverte de l'instance au sein de la fédération.
+
+Ce nom doit impérativement être cohérent avec l'adresse de publication du manifeste, sans quoi le manifeste doit être ignoré.
+
+## `name`
+
+Nom affiché de l'instance ou de la plateforme à laquelle l'instance est rattachée.
+
+## `display`
+
+Niveau de diffusion des informations du manifeste.
+
+Valeurs acceptées :
+- `public`, indiquant que le contenu du manifeste peut être republié sans limitation ;
+- `unlisted`, indiquant que le contenu du manifeste peut être republié mais pas affiché ou promu dans une liste publique d'instances (il peut être recherché précisément toutefois) ;
+- `private`, indiquant que le contenu du manifeste ne doit pas être rediffusé, bien que ses informations puissent être agrégées dans des statistiques globales.
+
+## `languages`
+
+Liste des langues pour lesquelles l'instance assure une communication et un soutien utilisateur.
+
+Les langues sont codées au format [ISO 639-1](https://fr.wikipedia.org/wiki/Liste_des_codes_ISO_639-1).
+
+Exemple pour une instance supportant le français et l'anglais :
+
+```
+["fr", "en"]
+```
+
+## `updated`
+
+Instant de la dernière mise à jour du manifeste, en secondes depuis l'[heure UNIX](https://fr.wikipedia.org/wiki/Heure_Unix).
+
+Cet instant peut être employé pour ignorer des manifestes qui ne sont pas suffisamment tenus à jour.
+
+## `cache`
+
+Durée pendant laquelle ce manifeste ne doit pas être récupéré une nouvelle fois par un robot, en secondes.
+
+## `grace`
+
+Durée pendant laquelle un robot ayant déjà récupéré ce manifeste ignore des erreurs de récupération.
+
+Cette durée peut être employée pour ne pas supprimer d'une liste les manifestes indisponibles temporairement ou ne respectant pas le format. Une durée plus longue permet une plus grande tolérance aux évolutions du format mais impose un délai plus long d'oubli en cas de disparition de l'instance.
+
+## `description`
+
+Description textuelle de l'instance sous forme de chaîne internationalisée.
+
+Les retours charriot ne sont pas nécessairement conservés. Le formattage n'est pas supporté.
+
+## `logo`
+
+URL d'un logo pour l'instance.
+
+L'URL doit être une adresse HTTPS publique vers une image au format `image/png`, `image/jpg`, `image/gif` ou `image/svg`.
+
+## `tags`
+
+Etiquettes libres applicables à l'instance, sous forme de liste internationalisée de chaînes. Les listes ne sont pas nécessairement de même longueur.
+
+Exemple :
+
+```
+{
+    "en": ["freedom", "privacy"],
+    "fr": ["liberté", "vie privée", "fraternité"]
+}
+```
+
+## `rules`
+
+Règles applicables à l'instance.
+
+Champ composé au format objet, dont les champs sont tous optionnels :
+- `laws`, indiquant les codes ISO 3166 Alpha 2 des pays dont les lois sont applicables à l'instance ;
+- `tagged`, indiquant les catégories de contenu devant être marquées explicitement sur l'instance ;
+- `forbidden`, indiquant les catégories de contenu interdites sur l'instance (outre les lois applicables si mentionnées) ;
+- `other`, chaîne internationalisée indiquant d'éventuelles autres règles.
+
+Exemple :
+
+```
+{
+    "laws": ["fr"],
+    "tagged": ["nudity", "violence"],
+    "forbidden": ["disrespect", "spam"],
+    "other": {
+        "en": "Please keep calm.",
+        "fr": "Merci de garder votre calme."
+    }
+}
+```
+
+## `technical`
+
+Informations techniques sur la gestion de l'instance.
+
+Champ composé au format objet, dont les champs sont tous optionnels :
+- `technologies`, indiquant les technologies employées par l'instance sous forme de liste de chaînes libres ;
+- `software`, indiquant le logiciel spécifique de l'instance sous forme de chaîne libre ;
+- `version`, indiquant la version du logiciel de l'instance sous forme de chaîne libre ;
+- `tls`, indiquant si l'instance support TLS sous forme de booléen ;
+- `fde`, indiquant si les données au repos de l'instance sont chiffrées (*full disk encryption*) sous forme de booléen ;
+- `foss`, indiquant si l'instance est gérée exclusivement à partir de logiciels libres sous forme de booléen ;
+- `lifetime`, indiquant l'instant jusqu'auquel l'instance est assurée de fonctionner, en nombre de secondes depuis epoch UNIX ;
+- `updates`, indiquant le délai moyen d'application des mises à jour sur l'instance, en secondes ;
+- `rpo`, indiquant le délai moyen entre deux sauvegardes ou la durée moyenne de perte de données en cas de panne, en secondes ;
+- `rto` indiquant le délai moyen de rétablissement de service en cas de panne, en secondes ;
+- `sla`, indiquant l'indisponibilité totale moyenne mensuelle du service, en secondes.
+
+Les durées indiquées sont exprimées sous forme d'entiers en secondes mais peuvent être interprétées avec une précision inférieure lors de l'affichage, par exemple les délais de mise à jour peuvent être affichés en jours tandis que les délais de rétablissement de service en minutes.
+
+## `accounts`
+
+Information sur la gestion des comptes par l'instance.
+
+Champ composé au format objet, dont les champs sont tous optionnels :
+- `registration` précisant le mode d'enregistrement ;
+- `conditions` listant les conditions applicables à l'enregistrement, une liste vide indiquant une inscription sans condition ;
+- `deletion` précisant les possibilités de suppression de compte ;
+- `migration` précisant les possibilités de migration de l'instance.
+
+Valeurs acceptées pour le champ `registration` :
+- `internal`, indiquant un enregistrement dans l'interface de l'instance ;
+- `support`, indiquant un enregistrement sur demande ;
+- `external`, indiquant un enregistrement par un système externe (par ex. SSO) ;
+- `closed`, indiquant qu'il n'y a pas d'enregistrement possible.
+
+Valeurs acceptées pour le champ `conditions` :
+- `major`, réservé aux personnes majeures ;
+- `opinion`, réservé aux personnes partageant les opinions de l'instance ;
+- `location`, réservé aux personnes résidant dans les lieux précisés ;
+- `human`, réservé aux humains (pas de robot) ;
+- `member`, réservé aux membres (d'une association, d'une entreprise, etc.)
+
+Valeurs acceptées pour le champ `deletion` :
+- `none`, indiquant l'impossibilité de supprimer son compte ;
+- `suspend`, indiquant la possibilité de verrouiller son compte ;
+- `delete`, indiquant la possibilité de supprimer son compte ;
+- `purge`, indiquant la possibilité de supprimer son compte et les données associées.
+
+Valeurs acceptées pour le champ `migration` :
+- `none`, indiquant l'impossibilité de migrer son compte ;
+- `export`, indiquant la possibilité d'exporter les données de son compte ;
+- `migrate`, indiquant la possibilité de migrer intégralement son compte.
+
+## `stats`
+
+Statistiques concernant l'instance.
+
+Champ composé au format objet, dont les champs sont tous des entiers, optionnels :
+- `rooms`, indiquant le nombre de salons de discussion si applicable ;
+- `users`, indiquant le nombre d'utilisateurs réels ;
+- `services`, indiquant le nombre d'utilisateurs robots ou bridgés ;
+- `messages`, indiquant le nombre de messages ;
+- `tags`, indiquant le nombre de tags si applicable ;
+- `groups`, indiquant le nombre de groupes d'utilisateurs si applicable ;
+- `links`, indiquant le nombre de liens vers d'autres instances.
+
+Les valeurs fournies peuvent être approximatives.
+
+## `actors`
+
+Acteurs intervenant sur l'instance.
+
+Champ composé au format objet, dont les clés sont les noms des acteurs et les valeurs des objets comportant les champs obligatoires :
+- `type`, indiquant le type d'acteur ;
+- `ref`, fournissant des références sous forme d'une liste ;
+- `location`, pays où réside l'acteur, au format [ISO 639-1](https://fr.wikipedia.org/wiki/Liste_des_codes_ISO_639-1).
+
+Valeurs acceptées pour le champ `type` :
+- `person`, désignant une personne physique ;
+- `nonprofit`, désignant une structure non-étatique ne recherchant pas le profit ;
+- `company`, désignant une entreprise privée ;
+- `state`, désignant un acteur étatique.
+
+## `roles`
+
+Rôle des acteurs au sein de l'instance.
+
+Champ composé au format objet, dont les valeurs sont des listes d'acteurs désignés par leur nom et les clés sont les rôles, tous optionnels, parmi les suivants :
+- `owner`, désignant un propriétaire légale de l'instance ;
+- `moderator`, désignant un modérateur de l'instance ;
+- `admin`, désignant un administrateur technique de l'instance ;
+- `host`, désignant un hébergeur de l'instance
+
+## `relationships`
+
+Autres instances avec laquelle cette instance est en relation.
+
+Liste de relations, chacune étant un objet comportant les champs obligatoires :
+- `type`, indiquant le type de relation ;
+- `federation`, indiquant la fédération à laquelle l'instance appartient ;
+- `instance`, indiquant le nom de l'instance dans la fédération ;
+- `ref`, liste de références concernant l'instance.
+
+Valeurs acceptées pour le champ `type` :
+- `owned` : indiquant que les propriétaires de l'instance sont identiques ;
+- `friend` : indiquant que l'instance est recommandée ;
+- `partener` : indiquant que l'instance est partenaire.
+
+## `extra`
+
+Fonctionnalités additionnelles de l'instance.
+
+Liste de fonctionnalités, chacune étant un objet comportant les champs obligatoires :
+- `type`, indiquant le type de fonctionnalité ;
+- `name`, indiquant le nom de la fonctionnalité sous forme de chaîne ;
+- `description`, décrivant la fonctionnalité sous forme de chaîne internationnalisée ;
+- `ref`, liste de références concernant la fonctionnalité.
+
+Valeurs acceptées pour le champ `type` :
+- `bridge`, désignant une passerelle avec une autre messagerie.

content/docs/heylo/resources.md

+---
+title: Ressources complémentaires
+---
+
+Quelques projets similaires proposent du contenu ou des espaces pour accueillir des nouveaux, généralement sur un réseau social fédéré en particulier :
+
+ - https://framagit.org/tykayn/joinfediverse (https://app.presentator.io/#/d7JjW3Hz/)
+ - #bienvenue:matrix.org, salon d'accueil francophone sur Matrix
+
+Plusieurs sites proches également diffusent soit des données techniques soit quelques métadonnées, sur inscription de l'instance par un tiers. Certains de ces sites récupèrent une part des informations (statistiques) par l'API des instances ; et une part (scan SSL, etc.) par des scripts dynamiques en plus de la déclaration statique.
+
+ - https://joinjabber.org/
+ - https://joinmastodon.org/
+ - https://joinpeertube.org/
+
+De nombreux articles et pages offrent du contenu ponctuel sur ce qu'est la fédération ou comment rejoindre une fédération particulière :
+
+ - [Page de documentation](https://tedomum.net/documentation/fediverse/) TeDomum sur ce qu'est la fédération ;
+ - [Retour d'expériene suite au Fédérathon](https://framablog.org/2018/08/21/retour-sur-le-federathon-le-hackathon-de-la-federation/) mené en 2018 (avec Framasoft) pour réfléchir à la fédération, à la décentralisation, avec notamment un atelier sur le nommage des « instances », concept que nous estimons difficile à comprendre pour le commun des mortels.
+
+Des tentatives précédentes de standard pour publier ce type d'information :
+
+ - [nodeinfo](https://github.com/jhass/nodeinfo) contient principalement des données techniques (statistiques) et évolue très peu ;
+ - [wellfed](https://github.com/kaiyou/wellfed) contient de nombreuses métadonnées mais n'a pas évolué depuis le premier jet en 2018.