[hm] Muerte a telegram

[Gio]

On Friday, 20 October 2017 02:20:30 CEST guifipedro wrote:
> 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.

Claro mientra cuando hai una autoridad centralizada como el caudillo, o el 
papa y su inquisicion no te queda nada mas que confiar, porque a los 
adeversarial los queman en una oguera o los torturan en una prision 
 
Por favor deja de citar este articulo de basura scientifica si quieres que sea 
un debate productivo, de todos sus argumentaciones infundadas trasmite una 
ignorancia al respecto del tema para flipar...


> 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.

No se entiende lo que quieres decir de todas formas que novedad es esto 
respeclo al viejuno email?
Me parece mucho hype por muy poca novedad...


> > 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

Pues eso es un nodo igual que los demas, no es un server que almacene datos o 
otras cosas de l en s usurari en s el Relay en el nombre solo es una cogna, ya que 
si te miras el repositorio solo hai unas cuantas llaves en que confio y un 
script que usa la API de retroshare por actualizar las llaves

Lo aporto a mis amig en s porque como con mi ordenador muchas veces estoy con 
conexiones de mierda mis amig en s me ayudan a saco a comunicarme pues quiero ser 
reciproco con ell en s y por eso tengo ese nodo encendido 24/7 en una maquina sin 
pantalla y con una conexion mas decente pero a diferencia de la matrix si JRI 
se cae no pasa nada la pegna no pierde ningun dato, sigue podiendo hablarse 
etc etc igual que cuando apago mi ordenador, y ademas no hay que confiar en 
ningun arquitecto/caudillo/sysadmin ya que la confianza que mis amigas le dan a 
JRI es la misma que me dan a mi porque somos amigæs.

Para mi es muy importante poder vivir sin el peso de algun dia tener que 
anunciar al estilo Carlos "Usuariæs... El servidor ha muerto. El sysadmin de 
exceptcion que antes ROOT y las botnet asumio la inmensa responsabilidad del 
mas exigente y sacrificado servicio a l en s usuariæs le han petado su maquina 
trascendental. Es natural..." o al inversa estar del lado de las usuariæs 
haciendoles misas a ROOT esperando en su clemencia y en un milagro que le 
devuelva ~sus~ datos...

https://www.youtube.com/watch?v=y17veW8PUgI


> >>> Mientras que retroshare permite un mix, matrix no.

No hai mix en retroshare todos somos nodos de la misma materia y de cada cual 
según sus capacidades, a cada cual según sus necesidades


> 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.

Un trozo de sesgada basura scientifica que simplemente por tener el nombre 
scientifico delante no significa que sea verdadero, neutral bien echo...

A lo cual estas dando difusion en una email donde lo aportas como un supuesto 
argumento valido...


> 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.

Pintar una opinion como si fuera la verdad, apoyandote en palabra como 
"sceintifico", con argumentos incorrector, no es informar es disinformar a los 
creedores de la religion del nuevo milenio es decir aquellos que igorando como 
funciona lo que se le llama scincia hoy en dia con que le digan que "lo dice 
un scientifico" se creen que eso es verdaderamente objectivo, es decir la 
verdadera ley de la natura


> 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.

Eso pasa tambien en al mayoria de trozos de guifinet, donde por delegar a una 
elite de tecnocratas la gestion de la red y confiar que ellos lo haran mejor 
que nosotras se ha acabado creando poderes de facto que tiene todo el interes 
en que montar red bien sea una cosa dificil (y que ademas se lo crea todo mas 
gente posible) porque es el fundamento de su poder, rechazando en cambio todos 
aquellos desarrollos tecnopoliticos que apuntan a que guifi.net sea de verdad 
la red de la gente y no de un pugnao de tecnocratas que ademas fomentan y 
financian software propietario (no libre) y violadores de la GPL como merdotik, 
y volviendo al tema generando la situacion de "collective vendor lock-in" que 
afecta hoy en dia la gran mayoria de tramos de guifi.net y que de facto impide 
el despliegue de IPv6 nativo en la misma

Solo este ejemplo deberia de ser suficiente para que dejes de creerte el 
elitismo tecnocratico que defendias un par de correo anteriores


> 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.

Error.

Aunque es verdad que retroshare anda mejor con ip publica como qualquier cosa, 
esto no es un requierimiento necesario (mientra lo es junto a mas cosas por 
correr un server matrix) retroshare tiene implementados mechanismos de NAT 
trasversal que le permiten funcionar tambien en situaciones desagradables como 
la en que esta internet y tambien muchos tramos de guifinet hoy en dia, ademas 
de poder correr como hidden service en TOR y en ese caso las IPs los NAT y 
toda la pesca ni las usa ni las ve...


> 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])

TURN STUN y amiguitos como los usa WebRTC no son user based infrastructure, 
porque dependen en servidores que læ usuariæ no controla


> 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 quien tiene la password de root?
Que pasa si a unæ de aquellæs que tiene la password de root se le va la holla 
como ha pasado muchas veces en los ultimos 20 anos?


> Generalizando el
> peligro de bitcoin: la descentralización excesiva no se puede
> controlar ni bajo el consenso del colectivo afectado.

Error.

El colectivo afectado no puede controlar por causa de la centralizacion del 
mining no por la excesiva decentralizacion, de echo el problema reside 
esactamente en la gerarchia implicita en el funcionamiento del mining de 
bitcoin en al condicion de re-centralizacion en que se encuentra hoy en dia, 
esta re-centralizacion crea como minimo una clase que son los mineros con 
mucho hashing power y mucho interes y poder en la red, y otra clase que son 
læs usuariæs que auqnue tengan mucho por decir no tienen poder, si hai 
consenso entre los mineros que es el colectivo que controla la red se puede 
incluso reescribir la verdad.

A cambio si el mining fuera distribuido esa relacion de poder no existiria y 
el consenso seria tomado a partir de la opinion de todo el colectivo, y si no 
hay consenso se procederia a uno o mas hard forks que es simbolico de lo que 
ha pasado por miles de anos en las humanidades.

Esto es necesario tambien por otra centralizacion implicita al modelo de 
Bitcoin, en el cual se asume que exista una verdad unica y por ende central en 
toda la red llevada por el libro contable sacro blockchain.

Otra vez si vamos un poco mas alla de la obfuscacion de la capa de polvo 
superficial de los problemas nos encontramos centralizacion, poder, gerarquia y 
las usuales desagradabilidades con que llevan anos peleandose esæs que llevan 
banderas con mucho negro...