IPFS
InterPlanetary File System (IPFS) es un conjunto modular de protocolos para organizar y transferir datos que conforman un file system descentralizado, siguiendo los principios del content addressing y peer-to_peer networking.
En esta sección no se va a entrar en detalle de cómo funciona IPFS, sino más bien en cómo podemos utilizar su ecosistema para la implementación y despliegue de las aplicaciones que venimos a analizar, aplicaciones comunitarias, distribuidas y descentralizadas, y en cómo estas se beneficiarían al usar IPFS.
La web que tenemos hoy en día funciona y lo hace muy bien. Para la gran mayoría de aplicaciones y sitios web, utilizar los servicios y protocolos actuales es lo más conveniente y sencillo. Sin embargo, en esta ocasión, nos enfocamos en un tipo específico de aplicaciones, aquellas que son comunitarias. Estas tienen otras necesidades y prioridades que la web actual no siempre es capaz de satisfacer de manera óptima.
El ecosistema de IPFS ofrece una alternativa a cómo se usa la web actual y a los protocolos tradicionales de transferencia y enrutamiento de datos, como es el caso de HTTP. Estos protocolos, basados en el direccionamiento por ubicación (location-based addressing), presentan problemas que van en contra de la naturaleza de las aplicaciones comunitarias, distribuidas y descentralizadas que buscamos analizar aquí.
El punto más importante, y el que mejor se alinea con la filosofía de estas aplicaciones comunitarias, es que IPFS es un protocolo descentralizado por naturaleza. La red de IPFS es abierta, distribuida y participatoria. No existe una entidad única que controle o sea dueña de IPFS; es un proyecto mantenido por la comunidad, donde cualquiera puede ser parte de su red.
Esta descentralización permite que no sea obligatorio depender de un servicio de terceros para el despliegue de aplicaciones, el cual puede tener un costo que no siempre es accesible. Potencialmente, las mismas personas que usan estas aplicaciones pueden donar parte del cómputo de su dispositivo para colaborar en mantenerlas activas, logrando así un despliegue distribuido y colaborativo. IPFS facilita esto a través del pin de archivos, donde un nodo puede optar por mantener permanentemente un archivo y compartirlo cuando sea necesario.
Por otro lado, gracias al content addressing, donde los datos se obtienen a través de su contenido y no por su ubicación, cada archivo tiene un Content identifier (CID) único, ofreciendo una dirección permanente accesible desde múltiples localizaciones. Esto permite que las aplicaciones sean más resistentes a interrupciones de servicio y, más importante para este tipo de aplicaciones, sean más resistentes a la censura. A diferencia de location-based addressing, como es el caso de HTTP, donde la solicitud está atada directamente a la dirección IP de un servidor físico y donde es mucho más fácil bloquearlo.
Sin embargo, no todo son ventajas. Generalmente, los sistemas distribuidos descentralizados son inherentemente ineficientes en su velocidad. La eficiencia es lo que se compromete a cambio de sus beneficios. Por esto y otras razones que veremos más adelante, IPFS no es la solución para todos los problemas, pero puede ser muy útil para las aplicaciones que puedan aprovecharse de sus beneficios y no se vean muy perjudicas por sus desventajas.
A continuación, exploraremos con mayor detalle las ventajas y desventajas de IPFS a través de ejemplos específicos de implementación, proporcionando además más detalles sobre su funcionamiento en estos casos.
Para analizar la viabilidad de IPFS como ecosistema para la implementación y despliegue de aplicaciones comunitarias, distribuídas y descentralizadas, se van a probar 3 distintos casos de uso, un sitio web estático, una enciclopedia colaborativa y una aplicación de comunicación en tiempo real. Estos casos de uso fueron seleccionados para ilustrar la versatilidad de IPFS en diferentes tipos de aplicaciones descentralizadas.
Si bien un sitio web estático no es algo comunitario de por si, principalmente ya que carece de una interacción que pueda haber con los usuarios, nos es útil para introducir los conceptos que IPFS provee.
Los sitios web estáticos son uno de los principales casos de uso de IPFS. Estos se complementan muy bien con el content addressing, al no ser perceptibles a cambios por parte del usuario, su Content identifier (CID) se mantiene y no requiere cambiar hasta que la página actualice su contenido.
Cualquiera puede publicar su sitio web en la red de IPFS a través de un nodo local de manera gratiuta y en tan solo unos minutos. IPFS provee un simple tutorial en su página de cómo realizarlo. Es por eso que acá no vamos a hacer énfasis en cómo hacerlo, sino en que implicaciones tiene y que alternativas existen para publicar en IPFS.
Al subir un archivo, puede ser un simple HTML por ejemplo, este se transforma en una representación de contenido direccionable mediante un Content identifier. Desde ese momento cualquierla de la red que quisiese podría obtenerlo buscandolo por su CID.
Sin embargo hasta este momento no se asegura la persistencia del archivo y puede que deje de ser accesible luego de un tiempo. Algo muy importante de IPFS es que los nodos tratan a la data que guardan como una cache, significando que no hay ninguna garantía que la data va a seguir almacenandose. Es por esto que existe el pinning que mencionamos anteriormente, "pinear" un archivo le dice al nodo que trate a esa data como esencial y que no la descarte. Entonces si "pineamos" el archivo HTML que subimos ya va a estar disponible siempre? No exactamente, ya que todavía depende de que nuestro nodo esté activo o que otros nodos que hayan accedido al archivo aún lo tengan en su cache para que otros puedan accederlo, y mejor aún sería que otros nodos "pineen" el archivo para aumentar aún más su disponibilidad.
Es por esto que si se desea que los datos queden disponibles sin necesidad que el nodo local esté activo existen opciones como los pinning services o collaborative clusters, que actuan pinneando los archivos en múltiples nodos, aumentando no solo su disponibilidad sino también su distribución, la cual va a lograr que sea mucho más rápido el acceso a los archivos.
La manera más fácil de asegurarse que los datos estén disponibles y se persistan es usar un servicio de pinning. Estos servicios corren muchos nodos que pinnean tus archivos, de esta manera ya no sería necesario contar con un nodo local que tenga los tenga.
Mirandolo desde el punto de vista de las aplicaciones comunitarias, estos servicios no van muy de la mano con su filosofía. Por un lado porque estos servicios no son gratis, ya que se están usando los nodos que ellos proveen, lo cual cuesta cómputo y espacio en disco. Y por otro lado, hasta más importante, que se pasa a depender de estos servicios, en escencia se está centralizando. Si por alguna razón el servicio dejara de "pinnear" los archivos, estos pueden perderse por completo y esto rompe completamente con la naturaleza de estas aplicaciones.
Entonces si no podemos usar servicios de pinning porque no se cuenta con dinero o no se quiere centralizar, que se puede utilizar ya que igualmente va a ser necesario que hayan nodos que "pinneen" los datos.
La alternativa son los cluster colaborativos. Estos son grupos de nodos de IPFS que actuan colaborativamente para "pinear" el contenido que se agregue al cluster, por uno o múltiples peers. Esto es muy poderoso, ya que podemos lograr que la propia gente elija colaborar con su nodo local para el "pinneo" de la aplicación. Logrando así, que potencialmente la propia gente que utiliza la aplicación sea la que la mantenga colaborativamente, perfecto para la filosofía de estas aplicaciones.
El problema de esta alternativa es que es muy poco utilizada, por lo tanto no existe actualmente una forma fácil de creación, seguimiento y descubrimiento de estos clusters. IPFS cuenta con una página con algunos clusters de los cuales se puede colaborar, el problema es que estos clusters obligan a los nodos a "pinear" la totalidad de sus archivos, haciendolo poco conveniente. Hablaremos más en detalle de esto en Lineas de trabajo futuras.
Al buscar un determinado archivo en IPFS lo que hace es buscarlo a través de su CID, el cual como dijimos es único. Esto funciona muy bien para cosas que no suelen cambiar, sin embargo en muchos casos, como este, no es así. Que una página sea estática no quiere decir que no pueda cambiar, el problema es que el content addressing en IPFS es por su naturaleza inmutable. Cambiar un archivo haría que su CID cambie, y por lo tanto también su address para encontrarlo. Sería impráctico compartir un nuevo CID cada vez que se actualice una página. Es por eso que con la ayuda de mutable pointers podemos compartir el address del puntero una única vez y actualizarlo, al nuevo CID, cada vez que se haga un cambio.
El InterPlanetary Name System (IPNS) es un sistema para crear estos punteros mutables a CIDs conocidos como names o IPNS names. Estos IPNS names pueden considerarse como enlaces que pueden actualizarse con el tiempo, conservando al mismo tiempo la verificabilidad del content addressing.
Un IPNS name es un hash de una public key. Está asociado a un IPNS record que contiene la ruta (/ipfs/CID) a la que se vincula, entre otra información. El titular de la clave privada puede firmar y publicar nuevos registros en cualquier momento.
IPNS cuenta con dos principales enfoques, donde su diferencia se encuentra en si se valora más la consistencia, o sea garantizar que los usuarios resuelvan el último registro IPNS publicado para el name a riesgo de no poder resolverlo potencialmente. O disponibilidad, o sea resolver un registro IPNS válido, a costa de resolver potencialmente un registro desactualizado.
Independientemente del enfoque de IPNS utilizadado, se va a localizar el registro IPNS a través de la Distributed Hash Table (DHT), en la cual todos los nodos de IPFS guardan, de forma colaborativa, su contenido. Por lo tanto, el DHT actúa básicamente como un "directorio" descentralizado donde la clave pública es un identificador que se puede buscar y que ayuda a localizar el registro IPNS que apunta al contenido deseado, entre otras funciones.
Para entender mejor cómo IPNS funciona se puede encontrar detallado en los docs de IPFS.
En terminos de las aplicaciones que venimos a analizar y especificamente para sitios web estaticos, IPNS es una muy buena forma de tener mutabilidad dentro de IPFS. El problema que tiene es que los names son hashes, no son nombres legibles para humanos y esto es un problema, especialmente para un sitio web. A continuación analizamos 2 alternativas para solucionar este problema.
(explicar como se puede utilizar con un cluster colaborativo a traves de pub sub)
IPNS no es la única forma de crear mutable pointers en IPFS. DNSLink utiliza registros DNS TXT para asignar un nombre DNS (un dominio por ejemplo) a una dirección IPFS o a un nombre IPNS. Como uno puede editar sus registros DNS, puede usarlos para que siempre apunten a la última versión de un objeto en IPFS.
DNSLink actualmente es mucho más rápido que IPNS, utiliza nombres legibles por humanos y también puede apuntar a nombres IPNS. Por qué entonces no es la opción adecuada? Lo que sucede es que tiene un problema muy fundamental y es que se está usando DNS, el cual tiene claras deficiencias con la filosofía de estas aplicaciones.
La más importante es que aunque DNS tenga claras ventajas, como que es un sistema distribuído y escalable, es también un sistema algo centralizado. Las autoridades centrales gestionan las raíces del DNS (ICANN, etc.). Y en base a esto sucede que DNS es fácil de censurar, a nivel de registrador como también de los ISP.
Entonces necesitamos una manera de tener nombres legibles pero sin utilizar DNS por los claros problemas que se presentan. Es aca donde entra ENS, Ethereum Name Service es el protocolo de nombres descentralizado que se basa en la Ethereum blockchain. Funciona de manera similar a DNS, en el sentido de que los nombres ENS resuelven a nombres legibles para humanos. Como esto se hace en la blockchain de Ethereum, es seguro, descentralizado y transparente.
Lo que se puede hacer entonces es configurar un registro ENS para que se resuelva en la dirección IPNS, resolviendo el problema que IPNS tiene, proporcionando nombres legibles para humanos que son más fáciles de compartir y acceder.
Cuando se quiera actualizar el contenido no es necesario modificar el registro ENS en sí, ya que siempre se va a apuntar al mismo name de IPNS.
Cabe aclarar que adquirir un dominio ENS tiene un costo, es un costo el cual no suele ser muy elevado y que vale pena por lo beneficios que mencionamos, especialmente para sitios web estáticos y también cualquier aplicación comunitaria. Pero si no es posible acceder a este servicio, se puede utilizar IPNS sin nombres legibles si así se desea.
En base a este analisis podemos concluir que la mejor forma de lograr el hosteo de una página web estática en IPFS es a través del uso de un cluster colaborativo compuesto por nodos confiables y nodos colaboradores, una dirección IPNS a la que actualizar con cada cambio y un nombre ENS para traducir de un nombre legible a la dirección IPNS.
Este enfoque tiene, sin embargo, desventajas o cosas a encontrar como mejorar, dentro de las que se encuentran:
- El más importante es la necesidad de tener al menos un nodo, pero preferentemente múltiples nodos, trusted. Estos nodos van a ser los encargados de administrar el cluster y actualizar el IPNS, esto sucede ya que no se puede liberar para que cualquiera pueda actualizar estos parametros.
- Volver a descargar todo el pin al haber una actualización. Por cada cambio que sea haga en el directorio de la página, se va a pinear un nuevo directorio al cluster, significando que todos los colaboradores van a tener que descargar todo el directorio nuevamente. posiblemente solucionable con (IPFS files API)
- TTL de IPNS, el TTL es un parámetro que indica cuanto "vive" una actualización de ipns antes de tener que volver a buscarla al DHT, para hacer uso de la cache de IPNS. El problema que tiene esto es que si se pone un valor muy elevado, un gateway no va a ir a buscar la actualización hasta que se cumpla el periodo y por lo tanto no mostraría la actualización. Por otro lado si se pone un valor muy chico, siempre va a ir a buscarlo, generando latencia ya que no utilizaría el cache, pero mostraría siempre la última versión que encuentre.
- Compartir claves privadas. Cómo la actualización de IPNS está firmada con una clave privada, todos los nodos trusted deberían tener la misma clave para todos poder potencialmente actualizar el registro IPNS, para evitar tener un único nodo con esa responabilidad, eliminando un punto de falla único.
- Necesidad de republicar el nombre IPNS cada cierto tiempo, KUBO actualiza el nombre cada hora para asegurarse que siga estando en la DHT, pero si se cae el node que publicó último puede que no se actualice mas, esto se tiene que tener en cuenta
- Apertura de puertos, IPFS cluster utiliza el puerto 9096 para la comunicación entre nodos, el cual se tiene que abrir, se podría usar hole punching.
- Automatización de levantar nodos trusted, los nodos trusted usan un config para iniciarse correctamente, actualmente se necesita configurar manualmente estos settings, por ejemplo el nombre del peer, el secret del cluster (para saber a que cluster pertenece) y la más importante la lista de trusted peers. Idealmente lo que se tendría que hacer es que no haya que configurar nada a mano, que el config pueda acualizarse "solo" por cada nodo trusted nuevo que se agregue al cluster.
- Automatización de actualización de IPNS, los nodos trusted son los encargados de actualizar el IPNS, en un determinado momento solo 1 nodo debería enviar esta actualización. Lo que se podría hacer es que haya un servicio de detección de actualización que esté mirando un repositorio y al detectar un cambio envie la actualización IPNS, si se cae el nodo lider que otro trusted tome su lugar para encargarse de la actualizción.
En base al análisis realizado, se detectaron diversas lienas de trabajo futuras para el ecosistema de IPFS, las cuales mejorarían su compatibilidad para el desarollo y despliegue de, especialmente, aplicaciones comunitarias.
Como mencionamos previamente, los clusters colaborativos son una alternativa para lograr la persistencia y disponibilidad de archivos, a través del "pinneo" de nodos colaborativos. La cual va muy de la mano con la filosofía de las aplicaciones comunitarias, ya que potencialmente la propia gente que utiliza la aplicación sea la que la mantenga colaborativamente. El problema es que actualmente casi no se utiliza esta alternativa, lo cual lleva a que por ejemplo, no haya una manera fácil de utilizarla, sin embargo esto tiene sus razones.
Para entender mejor por qué no se utiliza mucho esta forma de "pineo" y cuales son sus limitaciones, primero hay que entender que es lo que se utiliza. IPFS cuenta con una aplicación distribuida llamada IPFS Cluster, esta funciona a la par de los nodos de IPFS y permite mantener un conjunto global de "pines", alocando inteligentemente los items a sus nodos.
Gracias a esta aplicación es posible la creación de clusters colaborativos. Los clusters colaborativos permiten que peers individuales, que no son de confianza, se unan a un clúster IPFS como "seguidores" (sin permiso para modificar o editar el conjunto de pines).
Para crear este cluster es necesario primero contar con algunos nodos confiables, aquellos que van a tener permitido modificar qué archivos son los que pertenecen al conjunto de "pines". Y es esta nuestra primera limitación, ya que no se puede permitir que cualquier nodo pueda modificar este conjunto, entonces es necesario contar con nodos propios que tengan ese rol.
Otra cosa muy importante que se puede configurar sobre el cluster es el replication factor, este ajuste permite indicar a cuantos nodos se va a replicar cada archivo. Esto es muy importante porque permite que no sea obligatorio replicar la totalidad de los archivos en todos los nodos.
Sin embargo existe una limitación muy importante, IPFS Cluster no verifica si los seguidores realmente están "pineando" o no el contenido, ni cuánto espacio tienen ni otras métricas. Confía en todo lo que dicen. Eso significa que un seguidor malintencionado siempre puede fingir que tiene suficiente espacio, que se le asignen pines o fragmentos, pero al final no "pinea" nada. Un grupo formado por voluntarios aleatorios y que no son de confianza no puede usar, por ejemplo, factor de replicación de tres, porque esos 3 miembros podrían simplemente estar fingiendo "pinear" cosas. Es por eso que el escenario que mejor funciona es dejando que todos "pineen" todo y esperar que algunos de los peers no sean maliciosos.
Justamente de esa manera es como funcionan los clusters públicos actualmente, visibles en la página de IPFS, donde hay algunos que piden gigabytes, y hasta algunos terabytes de información, para poder colaborar. Esto es algo totalmente inviable para que la gente pueda colaborar hasta un cierto almacenamiento, limitando mucho la posibilidad de ditribución de colaboradores.
Habiendo hablado ya de las limitaciones más técnicas que se prensentan al usar cluster colaborativos, hay otro tipo de limitación que es el la falta de facilidad a lo hora de deployar, seguir y descubrir aplicaciones colaborativas que usen IPFS cluster.
En primer lugar hablemos del deployado, actualmente si se quiere deployar la aplicación en un cluster colaborativo la única forma que existe es hacerlo de forma manual y crear un servicio que se ocupe de actualizar el conjunto de "pines" cuando sea necesario actualizarse. Si bien es factible, no es algo cómodo para todos y limita a decidirse ir por este camino. Lo ideal sería, que exista un servicio, parecido al ofrecido en los servicios de pinning, como es el caso de Fleek, donde al actualizar el repositorio ya se deployen los cambios. Facilitando asi su deployado en el cluster colaborativo. Se podría pensar como un servicio que corra sobre los nodos trusted donde, cuando un nodo lider detecte que se hizo un cambio, se "buildee" la página web por ejemplo, y se despliegue en el cluster comunitario.
Parecido a lo anterior, alguien que quiera colaborar necesita ejecutar comandos manualmente que para mucha gente no sabe lo que está haceindo, lo cual también termina desincentivando y genernado que menos gente decida por colaborar.
Por último no existe una manera fácil de presentar y descubrir nuevos o existentes proyectos comunitarios que la gente pueda optar por colaborar. Actualmente el único lugar donde prensentan proyectos públicos para colaborar es la página de IPFS, que ademas se ser bastante simple, depende de ellos si agregan un nuevo proyecto para presentar en esa página. Donde lo ideal sería que puedan publicarse nuevos proyectos junto a una descripción y que la gente pueda conocerlos y optar por colaborar de una manera mucho más sencilla.
Con esto concluimos que se presenta la oportunidad para una linea de trabajo futura focalizada en la mejora para clusters colaborativos.
En primer lugar una mejora técnica donde se mofique o se contruya por encima de IPFS cluster, que permita principalmente que en un clúster comunitario se asegure el "pineo" de información sin necesidad de tener que obligar a todos los colaboradores a "pinear" la totalidad de los archivos.
En segundo lugar, la creación de una plataforma o aplicación, que permita la facilitación del deployado, seguimiento y descubrimiento de aplicaciones colaborativas.
Actualmente los colaboradores tienen que replicar toda la información de la aplicación que desean colaborar. Esto es un problema ya que no escalaría bien cuanto más crece. Se tiene que encontrar la forma de que idealemente, no sea necesario que todos tengan todo. Teniendo en cuenta el problema de bizantinos similar a lo explicado anteriormente con ipfs cluster, donde no podemos estar seguros si alguien está o no verdaderamente replicando algo.