[hm] Muerte a telegram

[fadelkon]

On 20 d’octubre de 2017 9:20:30 GMT+09:00, guifipedro <guifipedro en gmail.com> wrote:
>inly
>
>2017-10-20 1:10 GMT+02:00 fadelkon <fadelkon en posteo.net>:
>> Sin tener una opinión polarizada, creo que es significativo esto,
>quizá a lo que se refería pedro:
>
>bien, gracias, por decir "opinión polarizada"
>
>siento que se me está tratando como si fuese un radical de la solución
>(matrix). es muy sutil pero no me estoy sintiendo cómodo en este hilo
>

Siento la expresión. Quería expresar que sólo quería aportar o desarrolar puntos, no defender una u otra solución. Con tus argumentos, aunque escribes pros y contras, que se agradece, tú defiendes matrix. Con sus argumentos, gio defiende retroshare. En el sentido que cada uno piensa que es lo más adecuado ahora de usar.

>>>> Lo cual nos lleva, oh! a la creación de bridges (nat traversal) un
>>>> poquillo centralizados dentro de retroshare. Aunque como siempre
>todo
>>>> depende un poco de la comunidad y la actitud.
>>>
>>>NAT trasversal bridges centralizados??
>>>Me indicas donde lo has encontrado, me seria muy util ya que son anos
>>>que le
>>>doy vueltas al codigo de retroshare y no he encontrado esa parte
>>>centralizada
>>>a la cual apuntas...
>>>
>>
>> Puede que se refiera a los nodos de Just Relay? De algún modo es
>proveer nodos fijos al uso de los servidores.
>
>Exacto.
>
>No está en el código de retroshare, está en cómo funciona Internet hoy
>en día (lo trato de explicar más abajo)

Conozco los problemas de ipv4 y un poco cómo funciona retroshare. Y creo que justRelay no es un bridge de nat traversal. Sirve para poder distribuir mensajes asíncronos y para hacer túneles distantes que salten entre nodos de confianza. Si el jr es de confianza y está siempre disponible, facilita tales conexiones. Para hacer justicia, estos túneles también sirven como segunda opción cuando rs no es capaz de descubrir la ip del peer o establecer una conexión... estable. Pero rs por si solo sabe atravesar NATs.

>>>> Porque matrix es: "User-independent Infrastructure". Lo malo es su
>>>> centralización. Lo bueno es que "es difícil de montar", "lo monta
>>>peña
>>>> experta", lo cual tenemos como resultado: The advantages of
>>>> user-independent infrastructure include increased availability of
>the
>>>> service, a reduced attack surface, and immunity to user churn.
>>
>> No veo de ningún modo que la dificultad de montar sea una ventaja, en
>absoluto. Es muy diferente la experiencia del reto de montar algo en
>una, dos tardes, que la de mantener un servidor responsablemente. Me
>suena elitista y al final, contradictorio con una de las pegas que
>siempre destacas de guifi, la concentración de responsabilidad y poder
>en pocos hombros.
>
>Pues menos mal que no lo he escrito yo y que he usado un artículo
>científico publicado que hace un ANÁLISIS de las diferentes formas de
>descentralización, relaciones de poder, topologías que han aparecido
>en los últimos 15 años.
>
>Sí que, de acuerdo, lo he utilizado (manipulado?) yo (?).
>
>Con qué objetivo? Informar sobre las fortalezas y debilidades de un
>sistema y otro. No hay vencedor claro: pros y contras.
>

Aún así me permito el lujo de ser disidente. Instalar un servicio y mantenerlo son tareas muy diferentes. Una requiere habilidades y un tiempo finito, la otra también habilidades, pero además responsabilidad y constancia en el tiempo. Centrarnos sólo en las habilidades me parece equivocado.

> Y cuando
>queremos escapar del control del colectivo? retroshare, bitcoin, etc.

Bitcoin, faircoin, no permiten islas. La blockchain es una sola. Retroshare en cambio es un archipélago de islas de confianza. Rs funciona en una LAN sin internet


Por cierto... Muchas gracias por el tutorial, paradógicamente hace más fácil de instalar synapse jajaja. En serio, gracias por el curro :)

Creo que matrix vale la pena por ahora. Si salen más bridges estables y más clientes con e2e, o mejoran riot, será muy potente!

fdk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.