Jusque-là, tout le monde a toujours un peu l'impression que ceux d'en face ne standardisent pas. Pour un développeur non-XMPP, une XEP c'est pas un standard (en tous cas pas plus que la spécification de StatusNet).
Oui enfin XMPP ça passe par l'IETF, y'a des RFC, et le processus pour les XEPs est parfaitement décrit. La plupart des XEPs sont en expérimental ou deferred, et ça n'est pas standard dans ce cas. C'est pas tout à faire pareil qu'un bout de document (je ne sais pas ce qui est dispo pour status.net). Mais une documentation sur le protocole moi ça me suffit, même sans passer par les organismes, et ça déjà c'est très rare en dehors du monde XMPP.
Et si tu veux du microbloggage tout seul et sans boîte, il y avait le Friendika de l'époque qui correspondait assez. Bref, ça existait.
Friendica est toujours là, ainsi que redmatrix, le projet lié.
mais si je veux être un bon citoyen XMPP il faut que je me farcisse une XEP, que je la défende, maintienne, etc.
Non, ça c'est si tu veux contribuer au standard, et c'est un cas plutôt rare
Alors que si je veux contribuer à RedMatrix (pour en citer un que je connais), il me suffit d'aller discuter le bout de gras avec le développeur principal, de faire un pull request, et c'est parti : j'ai contribué et tout le monde en profite.
Ben c'est exactement pareil pour les projets XMPP. Il faut bien différencier standard et projets qui l'utilisent. Vient nous voir sur le salon de SàT par exemple (sat@chat.jabberfr.fr), on peut trouver des tas de choses à faire qui sont plus ou moins accessible, et dans beaucoup de domaines différents (dev web, plugin, chiffrement, transfert de fichier, outil en ligne de commande, etc). Surtout que notre archi est modulaire, donc on peut bosser sur des parties isolées.
Si tu veux un truc qui profite à plusieurs projets à la fois, contribue sur une bibliothèque ou sur un serveur.
À vouloir être un standard et/ou un écosystème avant d'être un produit, XMPP tend à n'être qu'une solution pour développeurs, pas pour utilisateurs. Or, les développeurs libres sont très souvent d'abord des utilisateurs.
XMPP est un standard et n'a jamais été autre chose. C'est les logiciels qui l'utilisent qui sont ce que voient (ou pas dans certains cas) l'utilisateur. Il y a des gens qui ne font que du standard, et d'autres que du logiciels (sans même forcément implémenter le standard, des fois il suffit d'utiliser une bibliothèque).
soit je contribue à SàT, soit je contribue à Movim, soit je contribue à Jitsi
Ce sont des façons de faire différentes, c'est comme pour Kde et Gnome ou Vim et Emacs. Mais tu peux toujours aider les différents projets en même temps, comme dit plus haut.
Et si je veux implémenter MES idées avec MA techno, la marche est considérable, sans garantie de pouvoir échanger plus avec l'écosystème que du chat texte et de la présence.
Comme pour toute techno, il y a un ticket d'entrée, mais je pense qu'apprendre à lire des XEPs et repérer celles qui t'intéressent c'est pas hors de portée du tout. Et après ça s'adapte très très facilement à un cas particulier.
Là encore, la sauce n'a pas pris et WebSocket+WebRTC rendent les atouts d'XMPP-on-the-Web non-déterminants.
on n'est pas du tout au même niveau. XMPP peut très bien utiliser WebSocket et WebRTC (Movim le fait d'ailleurs).
Tu vois où je veux en venir?
Pas vraiment pour être honnête.
Enfin bref, vient sur les salons, j'aurais pu t'expliquer très facilement comment contribuer sans se taper des tonnes de docs à lire. En plus quelqu'un entrant dans le projet peut nous aider à documenter en fonction des problèmes qu'il rencontre...
[^] # Re: Le Libre, c'est le choix, mais...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Pas seul dans la matrice. Évalué à 3.
Oui enfin XMPP ça passe par l'IETF, y'a des RFC, et le processus pour les XEPs est parfaitement décrit. La plupart des XEPs sont en expérimental ou deferred, et ça n'est pas standard dans ce cas. C'est pas tout à faire pareil qu'un bout de document (je ne sais pas ce qui est dispo pour status.net). Mais une documentation sur le protocole moi ça me suffit, même sans passer par les organismes, et ça déjà c'est très rare en dehors du monde XMPP.
Friendica est toujours là, ainsi que redmatrix, le projet lié.
Non, ça c'est si tu veux contribuer au standard, et c'est un cas plutôt rare
Ben c'est exactement pareil pour les projets XMPP. Il faut bien différencier standard et projets qui l'utilisent. Vient nous voir sur le salon de SàT par exemple (sat@chat.jabberfr.fr), on peut trouver des tas de choses à faire qui sont plus ou moins accessible, et dans beaucoup de domaines différents (dev web, plugin, chiffrement, transfert de fichier, outil en ligne de commande, etc). Surtout que notre archi est modulaire, donc on peut bosser sur des parties isolées.
Si tu veux un truc qui profite à plusieurs projets à la fois, contribue sur une bibliothèque ou sur un serveur.
XMPP est un standard et n'a jamais été autre chose. C'est les logiciels qui l'utilisent qui sont ce que voient (ou pas dans certains cas) l'utilisateur. Il y a des gens qui ne font que du standard, et d'autres que du logiciels (sans même forcément implémenter le standard, des fois il suffit d'utiliser une bibliothèque).
Ce sont des façons de faire différentes, c'est comme pour Kde et Gnome ou Vim et Emacs. Mais tu peux toujours aider les différents projets en même temps, comme dit plus haut.
Comme pour toute techno, il y a un ticket d'entrée, mais je pense qu'apprendre à lire des XEPs et repérer celles qui t'intéressent c'est pas hors de portée du tout. Et après ça s'adapte très très facilement à un cas particulier.
on n'est pas du tout au même niveau. XMPP peut très bien utiliser WebSocket et WebRTC (Movim le fait d'ailleurs).
Pas vraiment pour être honnête.
Enfin bref, vient sur les salons, j'aurais pu t'expliquer très facilement comment contribuer sans se taper des tonnes de docs à lire. En plus quelqu'un entrant dans le projet peut nous aider à documenter en fonction des problèmes qu'il rencontre...