Traducción del original IPFS Principles, publicado el 28 de marzo de 2023, por Sutty. Disponible en: https://specs.ipfs.tech/architecture/principles/
1. Direccionamiento
Les primeres diseñadores de la web la concibieron como un espacio universal en el cual identificadores únicos llevan a recursos informáticos. A medida que creció la web, fijaron en su arquitectura que todos los recursos debían tener un identificador y una “direccionabilidad” definida, queriendo decir que “solo una URI es suficiente para que un agente lleve a cabo un tipo de interacción en particular”.(webarch)
Este diseño fue un éxito total. A pesar de sus fallas, la web junta una enorme variedad de software, servicios y recursos bajo esta direccionabilidad universal.
Desafortunadamente, la direccionabilidad HTTP está basada en una jerarquía de autoridades que ubica a los recursos bajo control de un host (hospedaje) y los hosts bajo control de un sistema DNS (en el Apéndice se discuten más problemas derivados de este modelo). Como se indica en RFC3986:
Muchos esquemas URI incluyen un elemento jerárquico para definir una autoridad de nombramiento, para que la gobernanza del namespace (espacio de nombres) definido por el resto de la URI sea delegada a esa autoridad (que puede, a su vez, delegarla).
Los CID en IPFS ofrecen una mejora respecto de los URLs HTTP al mantener una direccionabilidad universal, a la vez que eliminan los vectores de ataque inherentes a una autoridad jerárquica. La direccionabilidad por contenido genera identificadores a partir del contenido de un recurso informático, de forma tal que cualquiera puede tanto regenerar el identificador como verificar que apunta al recurso correcto. Esto elimina la necesidad de que exista una autoridad por fuera del recurso mismo que certifique su contenido. Convierte a los CID en el componente de direccionabilidad autocertificante universal de la web.
Direccionar a datos usando CIDs es la principal característica definitoria de IPFS. Y la segunda característica, agnosticismo de transporte, puede ser soportada gracias a esta verificabilidad que los CID ofrecen. A lo largo de una amplia variedad de implementaciones, arquitecturas y servicios, IPFS es el espacio de los recursos con los que se puede interactuar mediante transportes arbitrarios usando una CID. Como una vez dijo Juan Benet, “¡eso es todo!”
A su vez, cualquier sistema que exponga interacciones con recursos basados en CIDs es una implementación de IPFS. Hay muchos contextos en los cuales los CID pueden ser utilizados para direccionar y la delegación de enrutamiento de contenido (http-routing-v1) puede soportar una gran cantidad de opciones de interacción al resolver CIDs.
2. Robustez
La Ley de Postel (o Principio de robustez) encapsula una sabiduría común respecto del diseño de protocolos de red. A través de los años se ha formulado de maneras varias, pero la versión canónica de [RFC1958] (“Principios arquitectónicos de Internet”) es:
Sé estricte al enviar y tolerante al recibir.
Este principio es elegante y expresa un comportamiento de las implementaciones de protocolos que resulta intuitivamente agradable. Sin embargo, a través de los años, la experiencia de diseñadores de protocolos web y de Internet ha sido que este principio puede tener efectos detrimentales para a la interoperabilidad. Como se plantea en la obra reciente de la Junta de Arquitectura de Internet respecto del mantenimiento de protocolos robustos, las implementaciones que aceptan en silencio input (entrada) con errores puede llevar a una acumulación de defectos en cuanto a interoperabilidad después de un tiempo, llevando a que todo el ecosistema protocolar se degrade.
Hay dos puntos de equilibrio para los ecosistemas protocolares: cuando las implementaciones en uso son rigurosas, las nuevas implementaciones necesariamente deben serlo también, lo que lleva a un ecosistema riguroso; por el contrario, cuando las implementaciones en uso son tolerantes, las nuevas estarán fuertemente incentivadas a tolerar el incumplimiento para poder interoperar. La tolerancia es altamente deseable a la hora de la extensibilidad y adaptabilidad a nuevos entornos, pero la rigurosidad es altamente deseable a la hora de prevenir que un ecosistema protocolar se degrade en una colección compleja de casos especiales con escasa o dificultosa interoperabilidad (lo que IETF denomina “intolerancia virtuosa”).
IPFS encara esta problemática con una nueva iteración del principio de robustez:
Rigurosidad respecto a los resultados, tolerancia respecto a los métodos.
Los CID obligan a resultados rigurosos porque la conversión de dirección a contenido es verificada; no hay espacio para resultados que se desvíen de la intención expresada en una dirección. A esta rigurosidad se la complementa con un diseño que, de manera proactiva, espera cambios gracias a un formato autodescriptivo (los CID son una implementación multiformato y soportan una lista indefinida de hashes, códecs, etc.). Que el destino final sea obligatoriamente riguroso significa que todo lo demás, destacando aquí el transporte, puede ser tolerante. Ser tolerante respecto a los métodos asegura adaptabilidad respecto al funcionamiento del protocolo, especialmente en cuanto a la adaptación a entornos específicos y a cómo aplicar inteligencia a los puntos finales de maneras novedosas; mientras que ser estrictx con los resultados garantiza que el resultado será correcto e interoperable.
Nótese que este enfoque también cubre al principio end-to-end (punta a punta). El principio end-to-end declara que las propiedades de confiabilidad de un protocolo tienen que ser soportadas en sus puntos finales y no en nodos intermedios. Por ejemplo, la mejor manera de garantizar la confidencialidad o autenticidad de un mensaje es cifrándolo o firmándolo desde un extremo y decifrándolo o verificándolo desde el otro, en lugar de pedirles a los nodos intermedios que implementen protecciones locales. El abordaje de de IPFS de la robustez, mediante los CID, se alinea bien con tal principio.
3. Requisitos para implementación IPFS
Una implementación IPFS:
DEBE ESTRICTAMENTE soportar direccionabilidad utilizando CIDs.
DEBE ESTRICTAMENTE exponer las operaciones que se realizan sobre los recursos (ej. recuperación, suministro, indexación) utilizando CIDs. Las operaciones que una implementación puede soportar no están contenidas en una lista cerrada, pero este requisito debe cubrir cualquier interacción que la implementación exponga a otras implementaciones IPFS.
DEBE ESTRICTAMENTE verificar que los CIDs que resuelve correspondan con los recursos a los cuales dirigen, al menos cuando tiene acceso a los bytes del recurso. Las implementaciones PUEDEN tener flexibilidad en cuanto a este requisito siempre y cuando sea en un entorno controlado en el cual es posible saber con certeza que la verificación ha ocurrido en otra parte confiable del sistema.
DEBIERA nombrar todos los recursos importantes a los que expone utilizando CIDs. Determinar cuáles recursos son importantes depende del juicio de cada quien, pero cualquier cosa a la cual otro agente pueda legítimamente querer acceso entra dentro del grupo y es mejor errar en favor de la inclusión.
DEBIERA exponer las unidades lógicas de datos que estructuran un recurso (eg. un documento CBOR, un archivo o directorio, una rama de un índice de búsqueda en forma Árbol-B) utilizando CIDs.
DEBIERA soportar verificabilidad incremental, sobre todo para poder procesar contenido de tamaños arbitrarios.
PUEDE depender de una capa de transporte. La capa de transporte no puede dictaminar ni restringir la manera en la cual los CID mapean al contenido.
4. Ejemplos de casos límites
Estos principios IPFS son amplios. Esto sucede por diseño ya que, al igual que HTTP, IPFS soporta una lista indefinida de casos de uso y es adaptable a una amplia gama de condiciones operativas. Considerar casos límites puede ayudar a desarrollar una intuición respecto de los límites que trazan estos principios.
4.1 Otros sistemas de direccionamiento de contenido
4.2 La verificación importa
Los requisitos previamente mencionados declaran que una implementación puede saltearse una verificación cuando “sea posible saber con certeza que la verificación ha ocurrido en otra parte confiable del sistema”. Esto es un requisito estricto en el cual les implementadores toman con seriedad la falta de confianza, una indicación de que está bien no usar ciclos de procesamiento constantemente verificando hashes en una configuración interna la cual une tiene razones para creer que es confiable. Esto no es un permiso para confiar en una fuente arbitraria de datos solo porque te caen bien.
Una pieza de código JS que busca datos de un gateway (puerta de enlace) IPFS-HTTP sin verificarlos no es una implementación IPFS.
Una gateway IPFS-HTTP que verifica los datos que trae de otras implementaciones IPFS antes de servirlas es una implementación IPFS.
Esa pieza de código JS del primer ítem puede volverse una implementación IPFS si busca de una [gateway sin confianza] y verifica lo que obtiene.
5. Direccionabilidad autocertificante
La autoridad es el control sobre un dominio de competencia dado. La autoridad de nombramiento es el control sobre qué nombre se les da a los recursos.
La direccionabilidad es la propiedad de un sistema de nombramiento tal que sus nombres son suficientes para que un agente interactúe con los recursos siendo nombrados.
La verificabilidad es la propiedad de un sistema de nombramiento tal que un agente puede certificar que el mapeo entre un nombre que usa y el recurso con el que está interactuando es correcto sin recurrir a ninguna autoridad más que a sí mismo y al recurso.
La direccionabilidad autocertificante es la propiedad de un sistema de nombramiento tal que es tanto direccionable y verificable: cualquier nombre es suficiente para interactuar con un recurso, y el mapeo a ese recurso puede ser certificado sin recurrir a una autoridad adicional. La direccionabilidad autocertificante es un componente clave de una web autocertificante y apoya a la resistencia a la captura, lo cual puede ayudar a mitigar la centralización.
Los CID soportan la direccionabilidad autocertificante. Con los CID, la autoridad para nombrar a un recurso reside solamente con ese recurso y deriva directamente de la propiedad intrínseca de ese recurso: su contenido. Esto libera a las interacciones con recursos nombrados por un CID de la relación de poder implícita en la arquitectura cliente-servidor. Los CID son el modelo de confiabilidad de IPFS.
Una implementación puede recuperar un CID sin verificar que el recurso se corresponde con él, pero eso haría perder la autoridad de nombramiento del recurso (del inglés resource’s naming authority). Una implementación semejante sería comparable con un cliente HTTP buscando registros DNS del resolver (“resolvedor”) de una persona cualquiera: no puede garantizar que el direccionamiento sea autoritario (del inglés authoritative). Les implementadores serán libres de tomar una decisión informada en cuanto a en qué lugar de su sistema soportan la verificación, pero deben asegurar que la relación entre CID y recurso sea verificada siempre que tengan acceso tanto al recurso y al CID que le apunte.
6. Apéndice: notas históricas
Tendemos a no pensar en la direccionabilidad porque es tan fundamental que nos cuesta entender un sistema sin ella, pero precisamente por eso es importante que lo entendamos bien. Existen numerosas pruebas históricas de que TimBL y otros consideraron que las URL eran posiblemente el invento más fundamental de la Web, y los primeros grupos que trabajaron en la arquitectura de la Web discutieron y debatieron las propiedades de las URL en profundidad. Los problemas de centralización a los que nos enfrentamos hoy se remontan a esas decisiones.
La naturaleza jerárquica de las direcciones HTTP era intencionada, como TimBL escribió claramente en Web Architecture from 50,000 feet:
El espacio HTTP consta de dos partes, una jerárquicamente delegada, para la que se utiliza el Sistema de Nombres de Dominio; y la segunda, una cadena opaca cuyo significado define localmente la autoridad propietaria del nombre de dominio.
El modelo que los primeros diseñadores de la Web tenían en mente era un modelo federado en el que la autoridad se delega y las direcciones se poseen en función de esa delegación de autoridad. Esto queda especialmente claro en el pasaje de la Arquitectura de la World Wide Web, Volumen Uno, dedicado a la propiedad de las URI:
La propiedad de un URI es una relación entre un URI y una entidad social, como una persona, organización o especificación. La propiedad del URI otorga a la entidad social correspondiente ciertos derechos, entre ellos:
to pass on ownership of some or all owned URIs to another owner—delegation; and
to associate a resource with an owned URI—URI allocation.
Por convención social, la propiedad de los URI se delega del registro de esquemas URI de la IANA, que es a su vez una entidad social, a las especificaciones de esquemas URI registradas por la IANA.(…)
El enfoque adoptado para el esquema URI “http”, por ejemplo, sigue la pauta según la cual la comunidad de Internet delega autoridad, a través del registro de esquemas URI de IANA y el DNS, sobre un conjunto de URIs con un prefijo común a un propietario concreto. Una consecuencia de este enfoque es la gran dependencia de la Web del registro central DNS.(…)
Los propietarios de URI son responsables de evitar la asignación de URI equivalentes a múltiples recursos. Así pues, si una especificación de esquema URI prevé la delegación de URI individuales o conjuntos organizados de URI, debe esforzarse por garantizar que la propiedad reside en última instancia en manos de una única entidad social. Permitir múltiples propietarios aumenta la probabilidad de colisiones de URI.
Los propietarios de URI pueden organizar o desplegar infraestructura [sic] para garantizar que las representaciones de los recursos asociados estén disponibles y, cuando corresponde, la interacción con el recurso sea posible a través del intercambio de representaciones. Existen expectativas sociales para una gestión responsable de las representaciones (§3.5) por parte de los propietarios de URI. Las implicaciones sociales adicionales de la propiedad de URI no se discuten aquí.
Esta noción de propiedad de direcciones o nombres está omnipresente en los documentos de arquitectura. Este pasaje de una entrevista a TimBL (Philosophical Engineering and Ownerhip of URIs) es explícito:
Alexandre Monnin: En cuanto a los nombres y las URI, una URI no es precisamente un concepto filosófico, es un artefacto (artifiact[sic]). Por tanto, se puede ser propietario de un URI, pero no de un nombre filosófico. La diferencia radica totalmente en este aspecto.
Tim Berners-Lee: Para una definición de nombre filosófico, no puedes poseerlo. Puede que en tu mundo, en tu filosofía, no se trate con nombres que se posean, pero en el mundo del que hablamos, los nombres se poseen.
Esta expectativa de delegated naming authority (autoridad delegadora de nombres) era tan fuerte entre los primeros arquitectos de la Web que el desarrollo de convenciones de nomenclatura en el espacio HTTP (por ejemplo, robots.txt, favicon.ico, todas las rutas .well-known) se describe como “expropiación” en la Arquitectura de la Web y la publicación del Grupo de Arquitectura Técnica (TAG) del W3C en el asunto afirmó que “rompe la Web”.
Los modelos federados sólo tienen una débil capture-resistance (“resistencia a la captura” literal) porque las entidades federadas siempre pueden ceder poder (precisamente porque tienen la propiedad (ownership) pero carecen de medios establecidos para apoyar la organización colectiva. En consecuencia, cualquier desequilibrio de poder será difícil de superar. Un buen ejemplo es la búsqueda: como publicante (publisher) (le propietarie de la delegated authority o autoridad delegada sobre el dominio) una persona puede ceder los derechos para indexar su contenido, pero no puede opinar sobre lo que se hace con el contenido indexado (la exclusión individual no es una opción). Esto estaba bien cuando se podían intercambiar contenidos por enlaces, pero una vez que se consolidó el poder de las búsquedas, las condiciones de intercambio se deterioraron sin que hubiera un recurso inmediato.
7. Agradecimientos
Muchas gracias a las siguientes personas, listadas alfabéticamente, cuya retroalimentación fue un instrumento para producir este documento: Adin Schmahmann, biglep, Dietrich Ayala, Juan Benet, lidel, Molly Mackinlay, and mosh.
A. Referencias
[http-routing-v1]
Delegated Routing V1 HTTP API. Gus Eggert; Masih H. Derkani; Henrique Dias; Marcin Rataj. 2023-08-31. URL: https://specs.ipfs.tech/routing/http-routing-v1/
[rfc1958]
Architectural Principles of the Internet. B. Carpenter, Ed… IETF. June 1996. Informational. URL: https://www.rfc-editor.org/rfc/rfc1958
[rfc2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[rfc3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[trustless-gateway]
Trustless Gateway Specification. Marcin Rataj; Henrique Dias. 2023-06-20. URL: https://specs.ipfs.tech/http-gateways/trustless-gateway/
[webarch]
Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. REC. URL: https://www.w3.org/TR/webarch/