Cree su propio Twitter descentralizado, parte 3: Hello Mastodon
En Parte 1 de esta seriecreamos una arquitectura para un sistema de redes sociales distribuidas utilizando Visual Studio proyecto de código y los archivos JSON correspondientes. En Parte 2descubrimos cómo hacer reducciones para resolver problemas como tweets eliminados.
En la publicación anterior, vimos que nuestro sistema de proyectos distribuidos está centrado en el usuario, pero es muy ingobernable. Ahora, lo que tenemos que hacer en la parte 3 es cambiar un poco de control por más certeza. Eso significa ver Mastodon enfoque de redes sociales federadas.
En un modelo federado, los servidores se comunican entre sí para construir un gráfico social. De este modo servidor mastodonte es simplemente un servidor que se ajusta a los protocolos pertinentes y participa en la federación. Un usuario se conecta a un servidor y a su vez participa en esa federación. Estos servidores tienen sus razones para existir, pero por lo general es para expresar las preocupaciones de una comunidad en particular.
Podemos ver que el modelo de federación es un poco similar a nuestro modelo de proyecto, excepto que las tiendas de tweets se ubican con uno de los servidores de exploración de tweets. En cuanto al servidor, ahora hay tweets locales y tweets externos. Veamos cómo los servidores federados mejoran las debilidades de nuestro modelo totalmente “centrado en el usuario” de nuestros proyectos.
Personalidad
Nuestro proyecto no tenía ninguna forma útil de identificar nada de manera única (un twitter o un seguidor de tweet), pero era parte de un sistema “centrado en twitter”. Aunque la identidad no es tan absoluta como Twitter, los servidores federados tienen identidades. Aunque Mastodon afirma no tener una autoridad central, los servidores son únicos en la singularidad de sus dominios de Internet. Esto significa que Mastodon tiene una identidad de usuario porque el usuario está asociado con un servidor. puedo tener una direccion @eastmad@mastodon.social (No recuerdo qué es en realidad) y tiene la posibilidad de ser único y seguro. tenga en cuenta que un “Acuerdo de servidor Mastodon”, un intento inevitable de tener algún liderazgo central por encima del posible caos. La conclusión es que al dar algo de confianza al servidor, obtenemos algunas ventajas.
Estructura
En nuestro modelo, el acceso a los tweets de un tuitero estaba controlado por twitter para que las conversaciones pudieran desaparecer en cualquier momento. Con una federación, los servidores se comunican entre sí para crear el cronograma, por lo que el cronograma no es exactamente lo que quieren las personas. Los servidores Mastodon a menudo se asignan a comunidades del mundo real, p. Mastodonte.cat Para los hablantes de catalán, por lo tanto, los usuarios pueden tener una similitud preexistente. Aunque replicar el gráfico es algo costoso, como veremos más adelante, el servidor controla una fuente confiable de la verdad. Por lo tanto, a diferencia de nuestro proyecto, el modelo Mastodon no necesita considerar medidas de mitigación para mantener la estabilidad.
Contenido
En nuestro modelo de proyecto, vimos que debido a que el tuitero controlaba su contenido (y por lo tanto era la fuente de la verdad), no solo podías twittear cualquier cosa, sino que también podías editar cualquier cosa en cualquier momento. Con el modelo federado, el contenido es propiedad del servidor. Los servidores deciden independientemente cuáles son sus políticas. No es de extrañar, por ejemplo, que la mayoría se esfuerce por prohibir el discurso de odio.
La libertad de expresión sobrevive en la federación, pero es libertad balcanizado. Por lo tanto, puede unirse a un servidor que le permita expresar sus pensamientos profundamente impopulares, pero debido a que otros servidores no hablarán con su servidor, es posible que su charla desagradable solo esté disponible en una parte muy pequeña del gráfico social. Enfatiza la “burbuja social” o “espacio seguro” que puede verse como una ventaja o una desventaja en diferentes momentos.
Aquí viene Mastodonte
Si sigue el código del proyecto, estará listo para ver cómo el código un poco más completo detrás de Mastodon trata con el chat. ¿Cómo podemos modificar nuestro modelo para que funcione con la API de Mastodon?
Nuestro proyecto simplemente combinó los mensajes de una manera simplificada porque no tenía idea al respecto. ascendientes y descendientes. Antes de mostrar el tweet, simplemente realizó una verificación rápida en la lista ordenada si la identificación del último mensaje tenía la misma identificación que el campo de respuesta en el mensaje actual:
|
largo prevtweetid = –1; carbonizarse sepchar = ‘:’; para cada (hay del tuit en Tweets totales) { si (prevtweetid == del tuit.Pío.Responder) sepchar = ‘↳’; más sepchar = ‘-‘; Consola.Línea de escrituraps“.. {sepchar} {tweetfrom.tweet.Text} “); prevtweetid = del tuit.Pío.Tiempo; } |
Obviamente, una publicación puede ser una respuesta a cualquier publicación anterior.
Para una funcionalidad completa, necesitamos saber, para cada publicación, cuál es la publicación principal (puede ser solo una o ninguna) y cuántos hijos tiene (ninguna o muchas).
Una publicación en Mastodon se llama estado. Recuerde, cuando Twitter comenzó en 2006, a sus intrépidos pioneros se les preguntó: “¿A qué te dedicas?”. invitó a responder a su declaración, porque en ese momento no estaba destinada a ser utilizada para una conversación: era más un estado de diario.
Cada estado tiene una identificación. Como en nuestro proyecto, la identificación probablemente se base en una marca de tiempo de Unix. Y como en nuestro proyecto, tenemos in_reply_to_id que almacena la identificación del estado al que está respondiendo. Con la API, simplemente usa la identificación de estado para obtener el estado:
Podemos replicar esto fácilmente en nuestro proyecto, pero necesitamos un usuario. A diferencia de un sistema verdaderamente distribuido, en un sistema federado el tweet (o estado) es el centro, no el usuario.
La API de Mastodon llama a un chat Contexto. (¡Esto es lo que sucede cuando permite que los desarrolladores nombren las cosas!) Tomemos nuestra conversación de muestra actual con Alan, Beth y Cath y pensemos en ella en el modelo Mastodon:
El primer ID de estado del destinatario será 1668435369. La llamada a la API para unirse a la conversación sería:
|
/API/v1/estados/1668435369/Contexto |
Alan inició la conversación, por lo que el estado no tiene antepasado y solo un descendiente. Si llamamos a la API en un solo descendiente (1668435540), detectaríamos un solo descendiente (1668438963).
Las llamadas de contexto de Mastodon solo devuelven estas dos listas, identificadores de antepasados e identificadores de descendientes, pero después de algunas llamadas, toda nuestra conversación se “analizará”, y hará un trabajo de modelado de la conversación más completo que el que hizo nuestro proyecto.
Ya puede ver que si desea explorar una conversación compleja, se convertirá instantáneamente en un cirujano de árboles, caminando arriba y abajo de las ramas para contar todas las hojas. Finalmente, te acercas al tronco, encuentras todas las sucursales principales y al menos puedes estar seguro de que tienes una cobertura completa.
Como muestra este gráfico, sin importar dónde comience, necesitará suficientes llamadas a la API de contexto de Mastodon (alrededor de nueve) para modelar todo el árbol con solo 11 nodos:
Reino de Twitter vs. Federación
Finalmente, los dos demandantes”conversación pública“La corona de las redes sociales parece ser Twitter monolítico y Mastodon descentralizado. Espero haber demostrado que son bastante diferentes, con el reino de Twitter proporcionando un imperio completo en una caja, mientras que una federación puede crecer o reducirse según las comunidades del mundo real que quieran participar.
Como hemos visto recientemente, el Reino depende de un gobernante sabio y sufre sin él. Una federación fomenta sociedades saludables más que un solo individuo. Ambos puntos de vista son válidos, y creo que es mejor señalar las buenas características de ambos que querer que prevalezca solo uno.
