En bref :
- Pour une communauté :
[[email protected]](/c/france@lemmy.world) - Pour un utilisateur :
[@[email protected]](/u/Rokil@sh.itjust.works)
Comment écrire un lien
Pour rediriger vers une communauté
Il suffit d’écrire [ce qui s'affiche au lecteur](/c/nom_de_la_communauté@adresse.instance)
Par exemple [[email protected]](/c/france@lemmy.world) ce qui donne [email protected]
Pour un lecteur depuis son instance, ce lien va lui permettre d’aller consulter le contenu de cette communauté tout en restant dans son instance. Et donc de s’abonner de manière fluide.
Pour un utilisateur
Quasiment pareil :
[ce qui s'affiche au lecteur](/u/[email protected])
Par exemple [@[email protected]](/u/Rokil@sh.itjust.works), ce qui donne @[email protected].
L’autocomplétion et son inconvénient
Si je tape !france l’interface web de mon instance me propose de compléter en [[email protected]](https://lemmy.world/c/france).
C’est pratique pour moi en tant qu’auteur, mais quelqu’un qui clique sur le lien sera transporté vers l’instance qui héberge la communauté, et pas l’instance du lecteur. Ce qui fait qu’un lecteur devra manuellement copier/coller le nom de l’instance dans le moteur de recherche de son instance pour pouvoir s’abonner, ce qui n’est pas très pratique.
De même pour un utilisateur, si je tape , l’interface web me propose
[@Rokil@sh.itjust.works](https://sh.itjust.works/u/Rokil) qui redirige vers l’instance que j’utilise, qui n’est pas forcément l’instance qu’utilise un autre lecteur.
Vous trouverez un autre fil de discussion en anglais dans le lien qui sert de base à ce post.
(Merci à @Jakylla qui a inspiré ce post)
Je suis pas hyper favorable a ça: les urls de cette forme ne marchent que sur lemmy, donc cette pratique force les gens à utiliser lemmy. Ça ne marche pas avec kbin et encore moins avec les autres logiciels du fedivers. Alors que c’était justement tout l’intérêt.
En fait le problème c’est qu’il y a pas de norme qui a été défini pour ça, du coup on est juste emmerdés avec des liens vers d’autres sites à chaque fois qu’on veut accéder à une autre communauté (alors qu’elle est fédérée)
Si kbin ne supporte pas ces liens, c’est vrai que ça devient bien emmerdant, et il n’existe plus de solution pour corriger les liens, autre que d’apprendre à tout le monde à quand on voit un lien, d’aller sur son instance, et le coller dans la recherche pour le trouver avec le formalisme de notre instance (ce qui défie juste complètement le principe d’un lien)
J’imagine qu’au moins avec les liens formattés ainsi, ça ne vous fait pas une grande différence depuis kbin, car avant, vous aviez un lien type https://lemmy.world/c/france, qui redirige vers autre chose que kbin, dont il vous fallait quoi qu’il arrive le retoucher à la main ou le placer dans une recherche pour arriver sur votre vue kbin de cette communauté. Maintenant il faut juste savoir que quand tu vois [email protected], et bien c’est pareil (juste qu’il faut pas cliquer sur le lien car ça marchera pas; mais de toute manière, tu cliquais pas sur le lien avant non plus - en tout cas ça n’avait aucun interêt)
[EDIT] J’ai lu quelquepart que les liens kbin pour les communautés peuvent s’écrire de la même manière, mais avec un “/m/” à la place du “/c/”. Une technique serait donc d’aller sur le lien (et arriver sur un 404), et changer le “/c/” par un “/m/” dans la barre d’URL pour faire la magie. Possibilité d’en faire un userscript assez simplement (détection 404 + ‘/c/’ => redirection sur ‘/m/’), mais je vois pas comment mieux faire pour le moment :(
Ou alors on demande à Kbin de renommer leurs /m/ en /c/ :D
Depuis que j’ai vu que l’on avait une intercompatibilité avec d’autres outils du fediverse (mastodon typiquement) via https://news.cosocial.ca/post/2263, je ne suis fait la même réflexion.
Je pense que la bonne façon de faire devrait être d’avoir le lien complet dans le message, ce qui est le cas aujourd’hui, et d’avoir le client (web, natif…) qui puisse décider qu’un lien ressemble fort à un lien vers une communauté qui pourrait être affichée depuis l’instance locale (en faisant une requête HEAD pour en vérifier l’existence) et rediriger vers la communauté avec une URL relative dans ce cas de figure.
Là, on ne casse pas les liens depuis les lecteurs hors lemmy, on reste sur sa propre instance quand c’est possible, mais ça demande une collaboration du lecteur utilisé
Ça semble être une bonne approche