[hm] Muerte a telegram

[guifipedro]

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

En fin, estaba precisamente tratando de hacer entender que cada
solución tiene unos pros y unos contras, especialmente entre:
user-independnet infrastructure, user-based infrastructure

Porque:

Decentralized systems are a subset of distributed systems where
multiple authorities control different components and no authority is
fully trusted by all. This implies that any component in a
decentralized system is potentially adversarial.

Para el caso de guifi.net, que venimos de usar rocketchat (que NO os
recomiendo), este servicio sí que era una única autoridad (con
promesas de descentralización con matrix, pero parece más
experimental, no lo probé). La solución de matrix pretende ser: aquí
un servidor que funciona, si no te gusta se monta así. Lo cual me
parece fantástico, porque a veces tenemos problemas de conexión entre
diferentes zonas que de esta forma no lo son tanto. Punto centralizado
(known problems): LDAP guifi.

> On 20 d’octubre de 2017 0:15:19 GMT+09:00, Gio <gio en diveni.re> wrote:
>>On Thursday, 19 October 2017 14:20:48 CEST guifipedro wrote:
>
>>>
>>> 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)

https://gitlab.com/g10h4ck/JustRelayIt

>>> Mientras que retroshare permite un mix, matrix no.
>>>
>>> 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.


Voy a explicar "NAT bridges" - Internet de hoy en día

Internet, a día de hoy funciona con una escasedad artificial de IPs.
Concretamente, a los poderes fácticos les interesa mantenerse en el
sistema IPv4, ya que la abundancia de la siguiente generación IPv6
rompe algunos esquemas.

La mayoría de protocolos y movidas locas se han pensado con que cada
host (equipo) tiene una IP. Pero entonces apareció entre otras cosas
el NAT, y entonces las IPs de rango público y rango privado; y una
gran chapuza para pasar cosas de lo que pasa fuera hacia adentro y
viceversa.

Entiendo que retroshare, como todo servicio/server con intenciones de
servir para sí y para otros, quiere IPs enteras. Pero esto no es
posible en el Internet que conocemos. Por eso entiendo que hace falta
algo como JustRelayIt.


Ahora: El problema con Retroshare o con cualquier servicio "User-based
infrastructure" no tiene que ver con su código, sino con cómo se
conectan el 99% de los usuarios a Internet. Una solución muy usada que
ha triunfado en un "user-based infrastructure" en el tráfico de media
(señalización sigue en servers a parte) es WebRTC; por qué? porque
tiene muchas medidas de nat traversal (principalmente: ICE, STUN,
TURN). A cambio, estas medidas de nat traversal de WebRTC hicieron
saltar en su día las alarmas [1] [2])


Montar menos servidores bajo la "User-independent infrastructure" en
el contexto de redes comunitarias u otros colectivos similares no es
elitista, quiere decir que se montan menos servidores pero controlados
colectivamente con el objetivo de autoprestación.

Y me voy un rato por las ramas: creo que es un caso similar a la forma
en que se vertebra la red de servidores faircoin. O los de monedas más
"centralizadas" (integralces?), pero que responden ante asamblea. Por
ejemplo bitcoin no responde ante ninguna asamblea. Generalizando el
peligro de bitcoin: la descentralización excesiva no se puede
controlar ni bajo el consenso del colectivo afectado. Y cuando
queremos escapar del control del colectivo? retroshare, bitcoin, etc.


[1] https://security.stackexchange.com/questions/97891/webrtc-privacy-issues

[2] http://www.unhappyghost.com/2015/02/webrtc-killing-tor-vpn-ip-masking-privacy.html