Hello !
Tout d’abord, bravo pour votre super idée, que je trouve très pertinente dans ce contexte.
Petit retour sur votre format (et désolé si je répète une proposition déjà donnée, je n’ai pas lu l’intégralité du fil).
Ça pourrait être une page sur chatons.org. Ça semble faisable avec une page html unique, entièrement statique, avec possibilité d’importer un json existant et de le modifier, puis de l’exporter. (je suppose qu’il faudrait faire ça en Javascript…)
Ensuite n’importe qui pourrait autohéberger la page html sur leur propre serveur si besoin.
D’où l’idée d’avoir un générateur qui nous évite d’avoir à maintenir un document à la main. Avis perso, mais supporter des formats différents dans ce cas d’usage risque de compliquer la tâche plus qu’autre chose… Parce que le crawler va devoir envoyer plusieurs requêtes sur chaque CHATONS (ex.: s’il ne trouve pas 42l.fr/services.json, il devra chercher 42l.fr/services.yaml).
Ça serait comme avoir un robots.txt, robots.md et un robots.odt qui donnent tous la même information. Dans ce cas d’usage, il me semble important d’avoir un même format standard, interopérable et normé.
En parlant de standards, vous n’avez pas défini de règle quant au chemin du fichier en question sur chaque plateforme CHATONS. Il me semble pertinent de faire usage du dossier well-known dans ce cas. Exemple : framasoft.org/.well-known/services.json. L’idéal serait de faire en sorte que tout le monde utilise le même chemin, ça faciliterait les choses 
En parlant d’interopérabilité, le fichier s’oriente plutôt vers les CHATONS (et c’est génial !) mais ce standard pourrait s’appliquer au-delà du collectif : pour d’autres collectifs également, et même pour tout hébergeur de service sur Internet. C’est peut-être voir trop grand et/ou trop demander, mais ça serait génial si vous moduliez 2-3 champs de votre format de façon à ce qu’il ne s’applique pas seulement aux CHATONS
En parlant de norme, les champs sont en anglais et les valeurs sont en français. Quitte à voir grand, vous pourriez concevoir votre format pour qu’il puisse être utilisé à l’international ! (mais surtout, choisissez entre anglais et français, pas les deux en même temps )
Champs potentiellement manquants
Champs généraux
- Il pourrait être pertinent d’ajouter un champ « version » (int) pour que derrière, le parseur traite différemment les champs en fonction de la version (si vous ajoutez des champs, etc.)
- Un champ « logo » facultatif (qui soit un lien vers une image distante) serait plutôt sympathique, mais cela impliquerait que le crawler télécharge l’image en local pour éviter une requête de tierce partie côté client. À méditer ? Par ailleurs, vous avez également (à priori) le logo de chaque structure sur chatons.org.
Champs par service
- pouvoir spécifier une date de fin de service si le service est temporaire. C’est utile pour les services qui sont seulement mis à disposition en temps de confinement, ou lorsqu’un CHATONS souhaite fermer ses services petit à petit (Framasoft par exemple
) - Comme pour entraide.chatons.org, pouvoir spécifier une pondération entre 1 et 10, valeur 5 par défaut, pour un usage avec un round-robin en frontend. De façon à ce que si on sent que notre service commence à être surchargé, qu’on puisse mettre une pondération de 1 pour diminuer la fréquence de suggestion du service dans le frontend.
- Pour le champ
price, je ne suis pas certain de ce que nous devons mettre. Dans le json que vous avez rédigé pour nous, vous avez mis « gratuit » pour nos services à accès restreint (réservé à nos adhérent·e·s). Mais l’adhésion à notre association est payante. Les services en question devraient-ils donc être marqués comme payants également ? - Deux champs
softwareetsource_codepourraient être intéressants dans ce contexte (je crois que c’est un peu comme ça que fonctionne pour entraide.chatons.org). - Un champ
descriptionpour le service n’est jamais de trop - Le champ
degradabilityn’est pas très modulaire et ne s’applique qu’à certains services. Peut-être remplacer sa valeur par un int correspondant au nombre de jours ? Sinon, peut-être le mettre dans un champ plus génériquemetadata(objet) qui listerait tous les champs spécifiant des paramètres propres au logiciel / service hébergé (ex: stockage autorisé pour une instance PeerTube, liste des applications Nextcloud proposées, liste des noms de domaines proposés par un service mail…). Le frontend n’aurait plus qu’à piocher dedans.
Catégorisation des services
Vous souhaitez catégoriser les services par type, ce qui semble tout à fait adapté dans ce contexte. Mais c’est très compliqué de standardiser tout ça. Les catégories actuelles sur le site CHATONS ne sont pas assez précises, notamment si le but derrière c’est de faire du round-robin sur des instances de logiciels très catégorisés. Quelques exemples, pouvez-vous catégoriser et différencier :
- Une instance Invidious ? Nitter ?
- Un résolveur DNS ? DoT ? DoH ?
- Un client de messagerie instantanée (Riot/Matrix) d’un serveur de messagerie instantanée (Synapse/Matrix) ?
La question, c’est de savoir jusqu’où granulariser la catégorisation des services tout en gardant un format assez lisible, bien qu’il vaut mieux partir du principe que le fichier sera créé avec le générateur, mais éventuellement remplissable à la main par des personnes qui savent ce qu’elles font.
Enfin, il faut qu’il soit facile d’ajouter / proposer de nouvelles catégories sans casser les catégories existantes.
Bon voilà, je le redis, mais j’aime beaucoup votre idée. Votre outil répond à un réel besoin au sein du collectif. Angie et Lise vous seront certainement reconnaissantes pour ne plus avoir à contacter chaque CHATONS afin de recenser toutes les instances de chaque logiciel sur entraide.chatons.org
Continuez comme ça, vous faites du super taff
~ Neil
).
)
à murmurations)