Desmitificando IPFS: La Guía de un Desarrollador Web para la Distribución de Contenido

Bienvenidos a la desmitificación de IPFS, y gracias por unirse a JS Nation y esta charla. Así que la forma en que se estructurará esta charla es en tres partes. En la primera parte, vamos a hablar sobre la plataforma web. Y luego vamos a pasar a IPFS y dónde encaja eso con la web. Y finalmente, vamos a echar un vistazo a IPFS para desarrolladores de JS y cómo pueden usar IPFS en la práctica.

La web es asombrosa. La plataforma web empodera a miles de millones de personas, y tiene el alcance más amplio con más de 5 mil millones de usuarios en todos los continentes a través de navegadores o vistas web y aplicaciones móviles. También es la plataforma más ubicua que prácticamente funciona en todos los dispositivos que van desde su escritorio, smartphone, laptop, televisores, e incluso frigoríficos en estos días. Y finalmente, también es un ecosistema abierto donde cualquiera puede publicar contenido o construir sitios con un mínimo de control de acceso.

Pero la web tiene sus fallas. La descomposición de enlaces es un gran problema en la web, donde los enlaces ya no son funcionales. Así que hay investigaciones que muestran que uno de cada cinco artículos científicos tiene al menos un enlace roto dentro de unos pocos años después de su publicación. De hecho, otras investigaciones sugieren que entre el 30 y el 70% de los enlaces web se descomponen dentro de un par de años desde su publicación. También está el problema de la censura. Un gran ejemplo de esto es la censura de Wikipedia, de la cual hay muchos ejemplos en países como China, Turquía, India, Rusia y otros regímenes autoritarios. Y la naturaleza de la web es tal que es posible que estos actores estatales bloqueen grandes extensiones de Internet.

También está el problema de cómo la seguridad está anclada al origen, lo que significa que careces de prueba de manipulación. Y un gran ejemplo de esto es cuando accedes a tu aplicación web de banca en línea, ¿cómo sabes que no ha sido manipulada? La forma en que esto funciona en la web es utilizando la política de mismo origen, mediante la cual, esencialmente, tu navegador valida el certificado firmado por la autoridad de certificación que se te presenta en tu banca en línea. Así que, esencialmente, estás confiando en quién en lugar de en qué es lo que realmente estás obteniendo. Esto contrasta con cómo los administradores de paquetes implementan la prueba de manipulación utilizando hashes y firmas. Ahora, la política de mismo origen, por supuesto, delimita los límites de confianza y seguridad, y eso generalmente está ligado al protocolo y al nombre de dominio. Pero la idea clave aquí es que estás confiando en quién en lugar de en qué.

Y la única excepción a esto, por supuesto, es la integridad de subrecursos, que es una característica relativamente reciente que se introdujo para permitir la importación de paquetes de otros orígenes y tener un atributo de integridad que valida, esencialmente, el hash de ese script que podrías estar importando. Y esto ha sido una gran introducción. Por supuesto, la raíz de muchos de estos problemas está en el hecho de que la web está dirigida por ubicación. La dirección por ubicación es fundamental para la web y cómo funciona Internet. La idea central aquí es que cada dispositivo de red tiene una IP, y DNS se utiliza para mapear nombres amigables para humanos a IPs. Ahora, esto funciona extremadamente bien porque la red hace posible encontrar múltiples caminos entre cualquier par de IPs en Internet. Pero esto también es la causa de muchos de estos problemas porque, esencialmente, para un nombre de dominio, típicamente tienes una única fuente, y como mencionamos antes, las IPs y DNS pueden ser fácilmente bloqueadas por actores estatales. Ahora, si una copia de datos o un sitio web desaparece, no hay forma de saber fundamentalmente dónde podrían estar otras copias. Además, no es posible para ti verificar la integridad del contenido que estás obteniendo, como en este tipo de visualización o diagrama que tenemos aquí.

No hay forma de que verifiques que realmente estás obteniendo la imagen correcta del sitio web de NASA. Esto nos lleva a la segunda parte de esta charla, IPFS. Así que intentemos desmitificar IPFS. IPFS es un conjunto de protocolos para direccionar y compartir datos en la web. Tiene implementaciones populares en TypeScript y Go, y está diseñado para funcionar de manera nativa en la web. Eso significa que está diseñado para funcionar en navegadores. Ahora, ¿qué queremos decir con compartir? Compartir típicamente significa dos cosas, publicar y recuperar. Hay dos ideas centrales detrás de IPFS que son clave para entender IPFS. La primera es el direccionamiento de contenido, y la segunda es la red peer-to-peer, y vamos a echar un vistazo a ambas. Pero vale la pena señalar que IPFS fusiona muchas ideas de Git, la herramienta de gestión de código fuente, y BitTorrent, el intercambio de archivos peer-to-peer. Así que el direccionamiento de contenido, que contrasta con el direccionamiento por ubicación, es esta idea de que derivar la dirección del contenido a partir del contenido mismo, utilizando hashes criptográficos, en lugar de a partir de la ubicación donde está almacenado, como es común con Ahrefs y enlaces en la web.

Las funciones hash son funciones que toman datos de longitud arbitraria y producen una huella digital de longitud fija de esos datos. Ahora, la dirección de contenido no es una idea nueva. De hecho, es muy prevalente en un sistema conocido como Git, que he mencionado anteriormente, donde cada hash de commit es un hash del árbol de archivos completo del repositorio en el momento del commit. PNPM también utiliza un almacén dirigido por contenido para deduplicar dependencias y hacer que la gestión de paquetes sea más rápida en el ecosistema de JavaScript.

Ahora, la forma en que IPFS implementa la dirección de contenido es utilizando identificadores de contenido, comúnmente conocidos como SIDs. Un SID es esencialmente un hash que contiene algunos metadatos adicionales, como el códec, la función hash y la longitud de ese hash. Esta es una propiedad que, por supuesto, permite que sea actualizable y autodescriptiva. Ahora, el esquema URI típico que se utiliza es IPFS dos puntos barra barra y luego un SID. Y, por supuesto, un SID puede ser representado en forma binaria o en forma de cadena. Y el ejemplo que tenemos aquí con la URI de IPFS es, de hecho, una representación en cadena.

El beneficio clave que la dirección de contenido te brinda es que te permite tener múltiples proveedores para un conjunto de datos. Así que un proveedor es esencialmente solo un nodo de IPFS que es accesible y está sirviendo datos que están dirigidos por ese SID. Por supuesto, aún necesitas obtener desde una ubicación, así que la dirección de contenido puede ser pensada como algo que se superpone a una ubicación. Internet dirigido, que aún utiliza IPs y puertos. Así que no hay magia aquí, aún necesitas obtener desde una ubicación. Y aquí es donde entra en juego el DHT de Cademlia. Así que la forma en que pasas de un SID a una IP real de un nodo que tiene los datos para ese SID, es utilizando este DHT de Cademlia. Lo cual es bastante complejo de entender, pero no vamos a entrar en todos los detalles de eso ahora.

Pero la idea clave es que el DHT esencialmente te permite ir de un SID a un proveedor o múltiples proveedores. Como tenemos en el diagrama aquí, tenemos un JPEG que tiene tres proveedores. Entonces, ¿cómo codificas datos en IPFS? Porque no puedes simplemente, por ejemplo, hashear un directorio. UnixFS es el formato que se utiliza en IPFS para codificar archivos y directorios. Y la idea con UnixFS es que todo es esencialmente un bloque que está dirigido por un SID. Y los archivos grandes se dividen en fragmentos más pequeños, que luego comprenden una estructura de datos más grande que se conoce como un Merkle DAG.

Esta es la misma estructura de datos que utiliza Git. Y el beneficio de un Merkle DAG es que puedes tener un único SID que representa todo un árbol de archivos. Y en este ejemplo, es un ejemplo muy mínimo de un directorio de construcción de un sitio web estático. Y puedes ver que tiene un archivo index.html y algunos activos estáticos y un style.css. La razón por la que uso esto como un ejemplo es porque enfatiza cómo UnixFS y, en general, IPFS son ideales para publicar sitios web y aplicaciones estáticas. Donde esencialmente solo tomas tu salida de construcción y la codificas con UnixFS, obteniendo así un único SID que representa todo el sitio web.

Ahora, el segundo principio clave detrás de IPFS que es importante para entender IPFS es la red peer-to-peer. Y la idea clave detrás de la red peer-to-peer es que cada cliente también es un servidor. Ahora hay una pequeña estrella allí porque los navegadores web resultan ser muy malos servidores. Estás muy limitado en términos de lo que puedes hacer en un navegador. Así que a veces es útil pensar en IPFS como una red en la que tienes algunos nodos que solo están haciendo recuperación porque no pueden hacer el trabajo de servir. Ahora, la red peer-to-peer en principio complementa la dirección de contenido porque, como mencioné, puedes tener múltiples proveedores. Y si tienes múltiples proveedores para un SID, quieres poder conectarte a ellos directamente.

También eliminas esta idea de servidores canónicos o de confianza que tienen un certificado que ha sido otorgado por una autoridad de certificación que ha autenticado su identidad como lo tenemos en la web tradicional. En su lugar, tomamos el enfoque de verificar y tratar a todos con un nivel mínimo de confianza. Ahora, la red peer-to-peer es difícil. Es difícil porque la red es difícil y tienes NATs y tienes firewalls y también tienes transportes limitados en los navegadores que mencioné al principio. Así que gran parte de esto es manejado por una biblioteca que se deriva de IPFS llamada Lip2P.

Y maneja gran parte de la magia de la travesía NAT y de superar firewalls y, por supuesto, implementa este Cademlia DHT, la tabla hash distribuida, donde almacenamos la información de quién tiene qué. Entonces, ¿qué beneficios obtenemos de IPFS y estas ideas de dirección de contenido y red peer-to-peer? Bueno, el primero es que obtenemos resistencia a la censura y resiliencia porque podemos tener múltiples proveedores. Prevenimos el link rot porque estos SIDs representan los datos. Ahora, esto no te garantiza que realmente tengas proveedores para los datos.

Así que no te garantiza la persistencia de los datos. Pero asegura que los enlaces realmente representan los datos para que siempre puedas recuperarlos y luego esos enlaces son fijos, por lo que no se rompen. También obtienes protección contra manipulaciones porque estás esencialmente verificando cada pieza de contenido que recuperas. Y debido a que todo es inmutable, porque está hasheado, es altamente cacheable, lo que te permite hacer cosas como sitios web estáticos de primera local, que vamos a ver en un momento. Y, por supuesto, obtienes deduplicación a través de conjuntos de datos. Esta también es la misma característica que está en Git.

Así que Git utiliza estos Merkle DAGs que esencialmente deduplican datos que son persistentes a través de commits. El enlace DNS es otra tecnología que es bastante importante para IPFS porque los SIDs no son muy amigables para los humanos. Son largos y no son muy memorables. Lo que el enlace DNS te permite hacer es introducir mutabilidad en IPFS y te permite vincular nombres DNS, dominios, a SIDs. Y haces eso utilizando un simple registro TXT en el guion bajo DNS link punto el dominio. Y almacenas en ese registro una ruta al SID que tienes.

Esto nos lleva a la tercera y última parte de esta charla, IPFS para desarrolladores JS. Por supuesto, después de todo, esta es JS Nation, una conferencia de JavaScript. Así que hablemos sobre las tres operaciones clave que tienes en IPFS cuando interactúas con el sistema. La primera es direccionar datos por SID. Así que tomas datos de entrada y los codificas de tal manera que se dirijan por un SID. Bajo el capó, por supuesto, está Merkle-izado en esta estructura de datos Merkle DAG. Pero, por supuesto, gran parte de eso es manejado por las bibliotecas y SDKs que tiene IPFS. La segunda operación es proporcionar o también conocida como fijar, donde ejecutas un nodo que se anuncia a sí mismo como un proveedor para el SID o múltiples SIDs. Y sirve esos datos a través de la red. Es por analogía similar a ejecutar un servidor HTTP, pero obviamente un poco más involucrado porque tienes que anunciar activamente los datos a este DHT.

La tercera operación es la recuperación. Y la recuperación por SID, donde obtienes datos utilizando el SID como dirección. Y esto puede suceder utilizando dos protocolos principales. El primero es bit swap, que es un protocolo de intercambio de bloques, que ocurre a través de estas conexiones libPTP. O, como veremos en más detalle en un momento, HTTP desde gateways. Ahora, he insinuado esto anteriormente en la charla. IPFS en la web es bastante difícil. La plataforma web es asombrosa, pero está fuertemente restringida, lo que significa que si estás ejecutando una aplicación en un navegador, estás limitado en términos de la cantidad de conexiones que puedes abrir. Y generalmente cuando quieres conectarte a un servidor, si estás ejecutando en un contexto seguro, necesitas que el servidor tenga un certificado TLS. Y para tener un certificado TLS, típicamente necesitas un dominio. Y finalmente, estás limitado con el transporte, así que no puedes simplemente abrir conexiones TCP o UDP arbitrarias. Estás restringido a HTTP, transporte web, sockets web y web RTC. Así que esto nos lleva a los gateways HTTP de IPFS y cómo llegaron a ser. Los gateways HTTP de IPFS son una API HTTP para recuperar datos de nodos IPFS.

Y probablemente el ejemplo más común de esto es IPFS.io, que es un CDN de bien público, esencialmente, que proporcionamos. Y solo puedes pasarle una ruta IPFS con el SID, y abstraerá todas las complejidades de peer-to-peer e IPFS en un navegador, y esencialmente hará la recuperación por ti y simplemente te lo devolverá. Ahora, esto resultó ser un gran éxito para el ecosistema IPFS en los últimos 10 años desde que se concibió IPFS, pero resulta que esto fue una espada de doble filo. Era muy conveniente, y a los desarrolladores les encantaba esto, pero convirtió a IPFS.io y gateways similares en un punto de centralización, eliminando y socavando muchos de los principios fundamentales de IPFS.

Tener múltiples proveedores y una red abierta y descentralizada. Esta es la razón por la que una de las grandes iniciativas en las que estamos trabajando actualmente es eliminar la necesidad de estos gateways centralizados, y la forma en que estamos abordando esto es convirtiendo esencialmente cada nodo IPFS en un gateway IPFS que también tiene un certificado TLS para que pueda ser alcanzado directamente desde un navegador web. Y hay varias formas en que estamos haciendo esto, de las cuales no entraré en gran detalle, pero siéntete libre de contactarnos o leer algunas de nuestras publicaciones en el blog que abordan más detalles sobre los transportes web y cómo abordamos este problema. Pero la idea clave es que, mientras hablamos, se está volviendo cada vez más posible hacer una recuperación directa de los proveedores sin pasar por un gateway centralizado.

Ahora quiero presentarte a Helia. Mucho de esto fue un largo preámbulo para llegar a la esencia de esta charla, que es Helia. Helia es una implementación modular y ligera de TypeScript de IPFS, y está destinada a Node.js y la web, por lo que utiliza todas las APIs web estándar. Puedes echar un vistazo en GitHub, y aquí solo tenemos un ejemplo donde te muestro cómo puedes tomar texto y esencialmente codificarlo como un archivo con UnixFS. Obtienes el SID para eso, y lo proporcionas a la red, y luego puedes usar ese SID para recuperarlo directamente desde este nodo Helia que se está ejecutando en Node.js.