Il y a un truc qui me perturbe avec le #fediverse tel qu'il fonctionne actuellement, c'est que tu est obligé de multiplier les comptes sur plein de services. Tu veux du micro blog, fait un compte sur mastodon (ou équivalent), pour les vidéo trouve un serveur peertube, les photo il te faux un compte pixelfeed, les livres ? Un compte chez bookwyrm.
Ça serait plus cohérent si tu avais ton serveur identité et que tous ces services se connecterai à se compte pour poster et suivre.
Et d'ailleurs quand tu vois les spec #activitypub tivityPub, t'as l'impression que ça a été conçu comme ça.
@julien Je crois que le principe de base c'était vraiment de décentraliser à fond et avoir des serveurs perso où tu pourrais avoir tous les services que tu veux. Mais il y a des solutions qui arrivent, genre Pixelfed a un PoC de SSO, si ça marche ça permettrait de se connecter par exemple avec ton compte Firefish sur une instance Pixelfed
@julien Ou bien peut-être qu'ils n'ont pas prévu qu'il y aurait plein de types de réseaux sociaux qui se créent comme ça, et qu'ils pensaient juste que les gens choisiraient le réseau qui leur convient le mieux, genre entre Twitter et Facebook bah je ne poste que sur Twitter mais je veux voir le contenu de Facebook.
@Varpie je pense qu'il y a deux choses. Déjà c'est plus simple d'implémenter ça de façon classique, avec l'App et le serveur qui sont uniques. Genre si t'as déjà ton app tu peux juste rajouter une couche d'activity pub par dessus. Et pour les besoin de ton app c'est probablement plus naturel d'avoir ta propre base de données. Deuxièmement il y a des vrai manquement côté spec d'activityPub. Genre il définissent un protocole client-serveur (c'est ce dont je parlais quand je disais ",c'est prévue pour") sauf que les spec ne disent pas comment géré l'authentification par exemple, ou comment agir sur le profil, ect... C'est clairement c'est pas suffisant pour implémenter une app entière. Beaucoup de service se retrouve à copier l'API de mastodon.
@julien Je crois que c'est volontaire parce que l'objectif n'était que de normaliser l'intéraction entre les serveurs, pas de limiter les clients. Il y a d'autres normes faites spécifiquement pour l'authentification client-serveur par exemple qui devraient être utilisées dans ce cas.
@julien En fait, en relisant la norme, je me rends compte que quasiment personne ne prend en compte la partie client-serveur, juste la partie fédération serveur-serveur. Genre, les clients sont censés poster du contenu ActivityStreams, mais si je regarde Firefish, l'endpoint /api/notes/create (qui n'est pas lié à un outbox d'un utilisateur spécifique, première "faute") envoie un JSON simple, plus léger mais qui ne correspond pas du tout à la norme.
