Con Ocean Protocol, puede usar servicios de almacenamiento centralizado como S3, Azure Storage o su propio almacenamiento local para almacenar y recuperar sus archivos de activos a través de los controladores de Osmosis en Brizo.
Pero almacenar archivos de activos en un servicio centralizado plantea múltiples problemas:
una entidad controla los datos, una entidad es legalmente responsable de todos los datos almacenados crea un solo punto de falla si el servicio se desconecta, los archivos de activos no se pueden consumir, abriendo las posibilidades de censura por parte de la entidad que ejecuta el servicio, o el servicio en sí si los archivos se mueven a otra ubicación dentro del mismo servicio, las URL existentes se rompen
Inicialmente creado para almacenar y mover conjuntos de datos científicos de manera eficiente, el Sistema de archivos interpalanetario (IPFS) resuelve todos esos problemas con el objetivo de transformar la web ampliamente centralizada en una red distribuida de igual a igual.
Los archivos se distribuyen entre múltiples nodos, eliminando el punto único de falla, problemas legales y de censura. Al usar el direccionamiento de archivos basado en el contenido en lugar de en la ubicación, las URL no se romperán si se mueven los archivos.
Así que definimos OEP-15 para hacer que el protocolo ipfs: // sea un ciudadano de primera clase en la pila del Protocolo Ocean, lo que le permite almacenar archivos de activos en IPFS y usar sus URL IPFS nativas durante el proceso de publicación.
En resumen, todos los componentes de la pila de Ocean Protocol ahora admiten la publicación y el consumo de archivos de activos almacenados en IPFS, lo que incluye soporte para URL IPFS nativas, haciendo referencia a archivos con sus identificadores de contenido (CID).
Todos los archivos almacenados en IPFS son públicos de forma predeterminada, por lo que tenía mucho sentido usar esto primero en nuestro Mercado de los Comunes. Pasamos por varios prototipos para terminar con nuestra configuración final.
Durante el flujo de publicación, encontrará una sección extendida de Archivos para agregar un archivo desde una URL existente y para agregar un archivo local de su dispositivo a IPFS.
Agregue un activo IPFS existente en commons.oceanprotocol.com/publish
El campo URL existente ahora es compatible con ipfs: // además de http (s): // por lo que si tiene un activo existente en IPFS, puede agregarlo aquí y todo funciona como antes. Con la excepción de que los archivos de activos se registrarán con esta URL IPFS nativa.
La nueva zona de colocación de IPFS proporciona una manera conveniente de agregar y registrar archivos de activos no publicados.
Agregar a IPFS desde un archivo local en commons.oceanprotocol.com/publish
Esa zona de colocación le permite agregar un archivo desde su máquina local y agregarlo a IPFS durante el flujo de publicación de activos en un instante:
El flujo de adición de IPFS completo
Los detalles tecnológicos
Primero, al abrir el área de la zona de colocación, se hará ping al nodo y puerta de enlace IPFS para verificar la conectividad. Dejar caer o seleccionar un archivo de su dispositivo en esa área hace un montón de cosas en segundo plano:
Agregará ese archivo a un nodo IPFS con js-ipfs-http-client y fijará el archivo para que permanezca en nuestro nodo durante la recolección de basura. Empaquetamos el cliente HTTP en nuestro propio React Hook personalizado. El archivo se envolverá en un directorio para preservar el nombre del archivo original, por lo que terminaremos con una URL como
ipfs: //QmX5LRpEVocfks9FNDnRoK2imf2fy9mPpP4wfgaDVXWfYD/video.mp4.El CID devuelto se utiliza para hacer ping a ese archivo a través de una puerta de enlace IPFS para que esté disponible en todo el mundo. del archivo. La URL de IPFS nativa se pasa a la lista de archivos de activos, y aparecerá en la lista de archivos. En la publicación final de activos, la URL de IPFS nativa se almacena encriptada en el Objeto Descriptor DID de activos (DDO) como se define en OEP-8.
Todos estos pasos son necesarios debido a cómo se distribuyen los archivos en IPFS entre sus nodos. Al agregar un archivo a un nodo (tenga en cuenta que no se llama "carga") solo está disponible en ese nodo. Solicitar ese archivo desde otro nodo comenzará el proceso de distribución del archivo desde el nodo IPFS inicial, haciéndolo disponible globalmente.
También el flujo de consumo requirió algunos cambios. Cada vez que se solicita la descarga de un archivo de activos almacenado en IPFS, en Brizo suceden múltiples cosas relacionadas con IPFS con su nuevo y brillante controlador osmosis-ipfs:
Las URL de los archivos se descifran al cumplir con éxito todas las condiciones. La ipfs: // url nativa se asigna a su https: // URL de la puerta de enlace. El archivo se descarga desde esa URL de la puerta de enlace. En caso de que se use una URL de archivo directo en lugar de ser una carpeta -wrapped (por ejemplo, ipfs: // QmPQNaNxHkasNiJBFZht2k3zCEBkvEu1aE5VNGZ8QiT8Nj), el final de archivo adecuado se agregará automáticamente al final del proceso de descarga, en función del tipo MIME detectado.
Al desarrollar esta función, se hizo evidente que necesitamos ejecutar nuestro propio nodo y puerta de enlace IPFS para tener un mejor control sobre toda la experiencia. Y donar un nodo en lugar de quitar el ancho de banda de la puerta de enlace principal de IPFS (gateway.ipfs.io) se sintió como lo correcto para hacer feliz a Juan.
Entonces creamos ipfs.oceanprotocol.com, gestionado por nosotros (es decir, legalmente hablando, BigchainDB GmbH).
Portada para ipfs.oceanprotocol.com
Está configurado para ser una puerta de enlace pública y proporcionar cierto acceso a su nodo HTTP API para todos. Esto significa que puede usarlo para abordar cualquier contenido en la red IPFS, como:
Al mismo tiempo, toda la funcionalidad API de nodo requerida por Commons está abierta al mundo, por lo que cualquiera puede usar esos puntos finales para agregar archivos a IPFS:
/ api / v0 / add / api / v0 / version / api / v0 / id
Para empezar, este es un nodo único simple, pero planeamos actualizar gradualmente ipfs.oceanprotocol.com a un Cluster IPFS completo de múltiples nodos para una mejor disponibilidad de datos.
Además de actualizar a un clúster IPFS, hay muchas formas en que el proceso se mejorará con el tiempo. Por el momento, la zona de colocación en Commons solo admite la carga de un solo archivo, por lo que una mejora rápida sería permitir la caída de múltiples archivos a la vez. Del mismo modo, la zona de colocación que usa js-ipfs-http-client viene con algunos errores al intentar cargar archivos más grandes.
Para hacer que el proceso de agregar archivos al nodo IPFS sea menos dependiente del navegador del cliente, se podría mover a una tarea en segundo plano en el Servidor Commons. Esto también debería dar más control y comentarios sobre el proceso de distribución de un archivo desde el nodo inicial a otros nodos.
Y, por último, se puede seguir trabajando para almacenar archivos cifrados en IPFS e implementar una forma de descifrarlos en una red Ocean Protocol.
