CÓMO META quiere destruir el FEDIVERSO ["ADOPTA, EXTIENDE, EXTINGUE"]
General Discussion
1
Posts
1
Posters
7
Views
-
Threads, la nueva red social de Meta, será compatible con el Fediverso. ¿Es esto una buena noticia? La historia parece indicar que no, ya que es probable que la multinacional esté desplegando una estrategia llamada "Adopta, Extiende, Extingue"..
Las grandes compañías tech, las que están incluídas en las siglas
GAFAM, esto es, Google, Apple, Facebook, Amazon y Microsoft, son
conocidas por sus supuestas (o a veces no tan supuestas) prácticas
monopolísticas. Solo a modo de ejemplo, una rápida búsqueda en
internet nos proporciona casos como:
- El departamento de justicia contra google.
- La FTC contra Facebook.
- Y otros casos similares de los estados de Tejas, Colorado y Utah contra google.No obstante, Meta (ose podría enfrentar hoy en día a un
competidor que no puede ser comprado: el Fediverso. En el vídeo
anterior os introduje un poco a este mundo del fediverso. El fediverso es
un grupo descentralizado de servidores que usan el protocolo
ActivityPub para comunicarse entre ellos. ActivityPub es un protocolo
de red abierto para crear redes sociales descentralizadas.
Básicamente, este protocolo proporciona una API cliente-servidor para
crear, actualizar y eliminar contenidos, así como una API federada de
servidor a servidor para enviar notificaciones y contenidos. El
resultado es que con este protocolo se han creado redes sociales
federadas y descentralizadas, como Mastodon (que sería como un
Twitter), PeerTube (que sería como un Youtube), Lemmy (que sería como
un Reddit), y otras. De los enormes beneficios que aportan estas redes
descentralizadas, federadas, y FOSS, ya hablé en mi vídeo anterior. La
idea de este vídeo es ver los mecanismos que tienen las grandes
tecnológicas para acabar
con esta competencia, que no pueden comprar como ha hecho en otras
ocasiones, ya que no es propiedad de
nadie, sino el resultado de la comunicación espontánea entre muchos
servidores.🕒 Marcas temporales:
00:00 Introducción
00:26 El Fediverso como amenaza
02:48 "Adopta, Extiende, Extingue"
04:32 Google vs XMPP
12:27 El origen de la estrategia
14:44 Meta vs Fediverso
15:50 La prueba
16:16 Conclusión: ¿qué podemos hacer?🔵 Algunos enlaces relevantes:
🔗 Artículo en que me he basado: https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html
🔗 Casos judiciales GAFAM: https://www.economicliberties.us/tech-lawsuit-timelines/
🔗 Threads: https://www.xataka.com/basics/threads-instagram-que-como-funciona-que-promete-esta-red-social
🔗 Fediverso: https://fediverse.party/🔴 VÍDEOS QUE YOUTUBE NO TE RECOMIENDA
https://youtu.be/EQy9g-U0VYM
Youtube Video🟢 CONTRIBUYE A LA DIFUSIÓN DEL SOFTWARE LIBRE:
🦇 Donando BAT si usas Brave Browser
🪙 Bitcoin (BTC): bc1qtmpr2k40kquq6scchv9dre65lahjr2gxrpdp69
🌩️ Bitcoin lightning (BTC): https://getalby.com/p/linuxchad
🕵️ Monero (XMR):
86LXrzSe7wfLAsWVftebH3UNozb6Pf5K8KKooBRo47BYhge4HmzEeaBHa3twGe3hmjG5UPUm6DrFhi2tZVPnaxm752vhZ9f
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@benjohn it's not a peer to peer protocol. It's federated - meaning you can pick a provider - like email or the Fediverse.
-
@daniel I was just checking out the Wikipedia page, thanks for the pointer. … does it work well peer to peer? Identifies seem to be tied to a domain?
-
@daniel@gultsch.social absolutely, the same naive expectations happen often when people think forums are easy to build :smile:
@pixelschubsi@troet.cafe is definitely on to something about re-using an existing XMPP server in order to avoid the heavy lift. The less the maintenance burden for me, the better as far as I'm concerned.
-
@julian @pixelschubsi I understand the instinct of wanting to reuse the parts you already have. Protocol parsing, identities, profiles etc. However those will very quickly become extremely minor building blocks in the complexity of instant messaging.
It's very easy to underestimate the scope and feature creep of IM. I've seen this happening in other places where people initially think that IM is just passing some messages around. And then users demand more features and then you reinvent XMPP.
-
@julian @daniel so in practice it would probably be the other way round: that heavy lifting you're rightfully afraid of has already been done and even the large tail of the remaining 20% (that in reality need 80% of the effort) are largely done.
If we were to agree to go the XMPP route, we could have fully-featuered deployment-ready implementations of instant messaging on top of AP identities in weeks to months. If it's something entirely new on top of AP, it's going to take years.
-
@julian @daniel I'm looking at it from a different perspective. IMO the Mastodon server (as an example) doesn't need to implement XMPP itself (it could, but it doesn't need to). Just like it doesn't implement HTTP itself.
It could instead rely on existing implementations. Take an existing XMPP server, reverse proxy its websocket endpoint, use the existing Mastodon auth to sign in, and embed an existing XMPP web client in the web frontend.
-
@silverpill @pixelschubsi @tris you can have a single account (or as I phrased it 'identity and login credentials') across different protocols.
For example your Google account works across multiple protocols. And even in the federated world we have several cases where email address == xmpp address.
So to repeat myself: using the same identity is good. Doesn't mean you are locked into ActivityPub if you want to build instant messaging.
-
To preface — I'm in agreement that ActivityPub probably isn't the best protocol to use for instant messaging. There's a lot of FUD still being spread about XMPP and I am outside of most of those discussions. NodeBB only supports AP at current.
That said, there's interest in pursuing AP as a delivery protocol for instant messaging because integrating a separate protocol is a heavy lift for everybody involved. It's a heavy lift if you already support AP, and it's a heavy lift when you support no federating protocols at all. Imagine a site looking to federate... now they have to use AP+XMPP? AP+Delta? etc...
Setting aside all the existing reasons why AP isn't ideal, I will say this... It clears the baseline expectations:
Messages can get sent via AP :heavy_check_mark: Messages can be privately addressed via existing AP addressing mechanisms :heavy_check_mark:That's it. The rest is icing. Really important icing, but for 99% of conversations, icing.
