Creación de Blog Distribuido Con Hugo - Parte 2

En este artículo vamos a realizar el proceso de publicación del blog en el servicio IPFS. Una vez publicado, mostraremos la forma de acceder al blog, a través de identificadores únicos, usando el servicio InterPlanetary Name System (IPNS) o a través de DNS

Publicación del blog

Es relativamente sencillo efectuar la publicacion del contenido web en nuestro nodo IPFS. El framework de IPFS incorpora una completa CLI que podemos consultar aquí. El comando que utilizaremos será ipfs add

$ ipfs add -r public     #añadimos a IPFS la carpeta public, que contiene el blog generado de forma estática en Hugo
added QmUu7kPx7M8N6DpvBJMkku5zMf5w4ahYFSQm1pHWjcF6uA public/404.html
added QmTUXZ477ZGRSDAnABCVXJYnyfSQnp5uok8cFvv9wgL85E public/categories/index.html
added QmabXM5d823SKAvvki2YR6of7ASDyrkUvETmQbn6mErWrU public/categories/index.xml
added QmYUaCPwvJWiueRXFSTTv8vdedWWzRhRdn8RMw35e7k67u public/css/bootstrap.min.css
added QmaWXif2wuZ1M131J5cKJM4tq99pz527uDV2oWHCm6xxgi public/css/codeblock.css
added QmTpcLZFRhXSZ4c3M4bBWWUrmRKGXv3gfF3JwZVnhx7eZm public/css/default-skin.png
added QmYyBaGKGoGNMsfLMqgj5ozG2uFef966EC2XWuo6z34wZQ public/css/fonts/KaTeX_AMS-Regular.ttf
added QmUt9LMyPMUwGFczbcHCqeyPrjxZuUBzvBpF1xYfh1bLxc public/css/fonts/KaTeX_AMS-Regular.woff
added QmRCi5pSpw9PVoVPyouzBpZFvgmB3nLiL7h8QRPBk3ZcTy public/css/fonts/KaTeX_AMS-Regular.woff2
added Qmark1UdGmpQqRN8haJgHSyFywWDs7ctAwnvNUhC2WsQpY public/css/fonts/KaTeX_Caligraphic-Bold.ttf
added QmYUqV2QeNCt63n8VTRMgdWxtatu7aMJUFqrBK2CYiUtRm public/css/fonts/KaTeX_Caligraphic-Bold.woff
added QmWdSbvBHmUKc6ivvvNPd3MjxWaUFRtQrZF3KQGbQ3pDrA public/css/fonts/KaTeX_Caligraphic-Bold.woff2
.....
added QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj public
 10.47 MiB / 10.47 MiB [====================================================================================] 100.00%

Como se observa, se genera un identificador único para cada fichero del blog. El último identificador es el directorio public, que contiene todo el blog. En nuestro caso, el blog ocupa 10.47 Mb

Para los que no quieran gestionar la publicación por línea de comandos, se puede gestionar a través de la consola web de gestión de IPFS. Accedemos con un navegaor al host donde tenemos el nodo IPFS, en nuestro caso http://192.A.B.C:5001/webui , 192.A.B.C –> ip de red interna donde está el nodo

A través de la interficie Web, apartado Archivos podemos gestionar la subida de contenido (o borrado).

Consola web

En el margen superior derecho, podemos realizar la importación (Import) y seleccionar a través del explorador de ficheros, el documento o directorio a publicar.

En nuestro caso, como automatizaremos la publicación del blog mediante un script preferimos usar la CLI.

Si accedemos a nuestro Gateway de IPFS o a un Gateway público, podremos recuperar el blog a través del identificador QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj Usaremos el gateway de ips.io Podríamos utilizar cualquier gateway de los disponibles, añadimos al host /ipfs/identificador y recuperaremos el blog.

Mejorando la persistencia

Hay un aspecto más que debemos considerar, para hacer persistente el blog en IPFS. Podemos leer en detalle como gestiona la persistencia de datos IPFS y para hacer permanente un contendio debemos usar el pinning. Si el blog tiene alta frecuencia de actualización quizá no será necesario usar el pin de datos. En nuestro caso, hemos querido ddejar persistente el contenido, pero en el proceso de republicación deberemos permitir que la versión anterior del blog, pueda ser ‘limpiada de IPFS.

EL CLI de IPFS incorpora un conjunto de comandos para hacer pin sobre un contenido. Igualmente, la consola de gestión web también lo permite.

El comando ipfs add ya hace el pin de datos en nuestro propio nodo, pero a veces es conveniente asegurar que nuestro contenido estará disponible siempre en la red IPFS.Para asegurar que los datos son retenidos, podemos usar servicios públicos de pinning. Está será útil por ejemplo, para evitar que no esté disponible el contenido, si nuestro nodo local no está disponible (se va la luz…) o queremos simplemente tener backup de nuestros datos en otro nodo. Algunos de los proveedores de pinnig disponibles son:

Podríamos realizar un pequeño script para relaizar la publicación del blog en los servicios de pinning, pero utilizaremos un proyecto que hace precisamente esto:IPFS Deploy

$# yarn global add ipfs-deploy # instalamos ipfs-deploy
$# ipfs-deploy -p infura   # en el mismo path tenemos la carpta public con el site 
ℹ 🤔  No path argument specified. Looking for common ones…
✔ 📂  Found local public directory. Deploying that.
✔ 🚚  Directory public weighs 10.5 MiB.
✔ 📌  Added and pinned to Infura with hash:
ℹ 🔗  QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj
✖ ⚠️  Could not copy URL to clipboard.

QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj
✔ 🏄  Opened URL on web browser (call with -O to disable):
ℹ 🔗  https://ipfs.infura.io/ipfs/QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj/


#Configuramos las variables de entorno para publicar en pinata
IPFS_DEPLOY_PINATA__API_KEY=<api key>
IPFS_DEPLOY_PINATA__SECRET_API_KEY=<secret api key>
#api-key i secret api key lo obtenemos del servicio Pinata, con el usuario con el que nos hemos dado de alta.


$# ipfs-deploy -p pinata
ℹ 🤔  No path argument specified. Looking for common ones…
✔ 📂  Found local public directory. Deploying that.
✔ 🚚  Directory public weighs 10.5 MiB.
✔ 📌  Added and pinned to Pinata with hash:
ℹ 🔗  QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj
✖ ⚠️  Could not copy URL to clipboard.

 
QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj
✔ 🏄  Opened URL on web browser (call with -O to disable):
ℹ 🔗  https://gateway.pinata.cloud/ipfs/QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj/

De esta forma tenemos nuestro blog en:

Nuestro nodo local
Infura
Pinata

Otra manera de mejorar la disponibilidad sería utilizando el clustering en IPFS, pero esto será objeto de otra entrada más adelante

Ahora que tenemos el blog publicado surgen varios problemas:

¿Cómo acordarnos de la url si tenemos que acceder con un identificador único?. El contenido es accesible, pero es muy difícil acordarse de la url de acceso a través de identificador único
¿Qué pasa si cambiamos el contenido del blog? La respuesta es que si cambiamos contenido, cambia el identificador único con el que lo referenciamos.

Por lo tanto, debemos implementar un mecanismo de acceso al blog por nombre y no por identificador.

Gestión del nombre del site

IPNS

Nuestro blog se ha desplegado usando un identificador IPFS, inmutable. La inmutabilidad del contenido en IPFS nos otorga la deduplicación de datos (el mismo contenido de diferentes pares producirá la misma dirección hash) y la verificación de contenido, para que podamos estar seguros de que el contenido no ha sido modificado si su hash coincide con lo que se esperaba. Esto tiene ventajas, como el hecho de que si nos comprometen el blog añadiendo código malicioso, el identificador que se genera será diferente. Pero también tiene desventajas. Pocas veces publicamos sites de continido inmutable y , como es nuestro caso, actualizamos a menudo los contenidos web que publicamos. ¿Qué pasa cuando cambiamos el contenido? Obviamente, el identificador único cambia y es muy dificil distribuir de nuevo esta información y hacer accesible el blog al nuevo contenido. Para resolver este problema el framework IPFS proporciona un servicio, el IPNS, el Interplanetary Name System

Un nombre en IPNS el el hash de una clave pública. Nos permite asociar contenido inmutable (ipfs) y luego actualizar el puntero de ipns para que, aunque el contenido cambie, la forma de acceder a él no lo haga. De esta forma, se puede actualizar el sitio web sin tener que hacer que todo el mundo que accede a él cambien el CID.

Entonces, ¿qué es exactamente IPNS? Básicamente, un espacio de nombres global basado en Infraestructura de clave pública (o PKI) que nos permite construir cadenas de confianza (para que pueda seguir una clave pública a su par de ruta), dándonos encriptación y autenticación, y todavía es compatible con otros servicios de nombres . Entonces, por ejemplo, incluso podemos asignar cosas como entradas DNS, etc. a direcciones IPNS.

En nuestro caso:

$ipfs name publish /ipfs/QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj
Published to k51qzi5uqu5dif2dlnspq780yooykc6i2buuoip654yi1rh9yx42kvgnkxpnpf: /ipfs/QmW7Smqoc9GwCcq1W9j6SvT13iuyhUZmMnrUDWgEzCsTAj

Ahora podríamos acceder a nuestro contenido a través de IPNS:

Desde cualquier gateway IPFS se puede recuperar el contenido, puesto que el identificador IPNS no cambiará /ipns/k51qzi5uqu5dif2dlnspq780yooykc6i2buuoip654yi1rh9yx42kvgnkxpnpf/

¿Y a través de DNS?

Si bien hemos conseguido publicar el blog y hacerlo accesible mediante un identificador basado en IPNS, lo habitual es acceder a los diferentes sitios web por nombre de host. Existe una solución para acceder a nuestro contenido por nombre. Se trata del servicio DNSLink. Disponemos del dominio gonzalezmas.es y lo usaremos para crar el acceso a nuestro blog por nombre DNS.

DNSLink utiliza los registros TXT DNS para mapear un nombre de domino (como gonzalezmas.es) a una dirección IPFS o IPNS. Como podemos editar registros TXT DNS, podemos usarlos para actualizar y apuntar a la última versión de IPFS, cuando cambiemos contenido del blog. Una dirección DNSLink se parece a una IPNS, pero usa el nombre de dominio en lugar del hash de la clave pública del nodo IPFS.

En nuestro caso hemos creado el host ‘ricardo.gonzalezmas.es’ Modificamos el CNAME para que apunte a gateway.ipfs.io

dig ricardo.gonzalezmas.es

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> ricardo.gonzalezmas.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9968
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 4000
;; QUESTION SECTION:
;ricardo.gonzalezmas.es.		IN	A

;; ANSWER SECTION:
ricardo.gonzalezmas.es.	5	IN	CNAME	gateway.ipfs.io.
gateway.ipfs.io.	5	IN	A	209.94.90.1

Por otra parte, creamos el registro TXT _dnslink.ricardo que apunte a ‘dnslink=/ipns/k51qzi5uqu5dif2dlnspq780yooykc6i2buuoip654yi1rh9yx42kvgnkxpnpf/’

dig ricardo.gonzalezmas.es
dig +noall +answer TXT _dnslink.ricardo.gonzalezmas.es
_dnslink.ricardo.gonzalezmas.es. 5 IN	TXT	"dnslink=/ipns/k51qzi5uqu5dif2dlnspq780yooykc6i2buuoip654yi1rh9yx42kvgnkxpnpf"

Hemos decidido, a pesar de que el rendimiento es peor, mantener el DNS no actualizado, publicando directamente el apuntador IPNS. Si nuestro servidor DNS permitiese actualización via API, podríamos programar el update del registro TXT cada vez que generasemos un nuevo CID IPFS.

Podemos probar el acceso a través de un gateway IPFS o directamente al subdominio creado:

Vale, pero el DNS es un servicio centralizado… Dominios Descentralizados con ENS

The Ethereum Name System, ENS, es un servicio DNS distribuido, basado en la bloackchain Ethereum, como backend. Ethereum Name Service (ENS), nace como un gran sistema descentralizado que funciona sobre Ethereum y su función es la misma de un DNS. Básicamente, nos sirve de una gran libreta o contenedor de cualquier información. Una información que es almacenada en la blockchain Ethereum y que podemos referenciar y buscar de forma libre y sin censura.

Sin entrar en los detalles de la creación del dominio, hemos registrado el dominio ‘gonzalezmas.eth'’. ENS, nos permite especificar como registro de contenido un CID IPFS o IPNS. Con ello, vinculamos nuestro nombre de dominio distribuido, con el contenido distribuido en IPFS. Existen navegadores como Brave o Opera que resuelven de forma nativa dominios ENS. Para hacer accesible el dominio con todos los navegadores, daremos publicidad al blog a través de https://gonzalezmas.eth.link/

En posteriores entradas explicaremos más sobre el servicio ENS.

Resumen

Publicado el contenido del blog en el nodo IPFS propio
‘Pinning’ del contenido en gateways públicos como Infura o Pinata
Creado apuntador IPNS para facilitar el acceso
DNSLink para vincular contenido con DNS estandar: http://ricardo.gonzalezmas.es
Publicación con dominio ENS distribuido: https://gonzalezmas.eth.link/

Pendiente:

Automatizar el proceso de publicación
Clusterizar servicio
~~Mejorar rendimiento IPNS~~ Hemos encontrado una solución para mejorar la resolución a través del servicio IPNS

Al iniciar el deamon de nuestro nodo IPFS debemos añadir la opción

--enable-namesys-pubsub

Este flag activa un nuevo mecanismo de resolución IPFS mucho más rápido que el convencional. En la versión 0.5.0 apareció como opción experimental pero ahora la solución es bastante más fiable con las versiones actuales. Para más detalle aquí

hugo blog ipfs