← Todas las entradas

11 min de lectura

Cómo usar CardanoWall sin la web

La web es una interfaz, no todo el producto. Puedes publicar y verificar registros Label 309 desde una CLI, los SDK, una API de gateway, una app de escritorio o tu propio servicio.

Puedes usar CardanoWall sin abrir nunca la web. Los mismos registros de prueba de existencia se pueden crear, publicar y verificar desde una herramienta de línea de comandos, un SDK en el código de tu aplicación, una API de gateway, una app de escritorio o un servicio que tú mismo ejecutes. La web es una de las caras de un estándar abierto —Label 309— y el estándar es lo que de verdad importa.

Esa distinción es lo esencial. La prueba de existencia muchas veces no es una acción humana puntual. Su sitio está dentro de un pipeline de compilación, una rutina de cumplimiento, un sistema de procedencia para IA, un flujo de trabajo de pruebas legales o un producto que construye otra persona. Ninguno de esos casos debería exigir que alguien haga clic por una única interfaz web.

¿Qué hace en realidad la web?

La web hace que la prueba de existencia sea accesible. Te da un compositor visual, una vista de la cuenta y el saldo, páginas de registro, gestión de identidades, un flujo de subida y publicación guiada. Para la mayoría de la gente, ese es el lugar adecuado para empezar.

Pero no debería ser la única forma de usar el estándar. Si una prueba solo funciona cuando una persona hace clic por una interfaz, no puede convertirse en infraestructura. Las empresas necesitan automatización. Quienes programan necesitan API y SDK. Los equipos de operaciones y seguridad necesitan flujos de trabajo repetibles y automatizables. Algunos usuarios quieren sus registros y archivos en su propia máquina. Algunos operadores quieren ejecutar ellos mismos todo el pipeline.

La web es la puerta de entrada. No es todo el edificio.

¿Cuáles son las otras formas de usarlo?

Hay varias, y todas convergen en el mismo artefacto: un registro Label 309 estándar anclado en Cardano que cualquiera puede verificar de forma independiente:

  • la app web de CardanoWall;
  • la herramienta de línea de comandos cardanowall, de código abierto;
  • los SDK oficiales (TypeScript, Python, Rust) para el código de aplicación;
  • una API de gateway Label 309, a la que se accede con un token por cuenta;
  • CardanoWall Desktop, el cliente local-first de código abierto;
  • un gateway que alojas tú mismo;
  • tu propio producto construido sobre un gateway.

La interfaz puede cambiar. El formato de la prueba no. Todo este código es de código abierto en github.com/cardanowall, con licencia Apache-2.0, y el texto de la especificación bajo CC-BY-4.0.

¿Cuándo debería usar la API de gateway?

Usa la API cuando publicar o leer pruebas tenga que formar parte de un sistema en lugar de ser un paso manual. Por ejemplo:

  • un producto SaaS crea una prueba para cada documento de cliente;
  • un pipeline de compilación publica pruebas de la versión tras cada compilación;
  • una plataforma de IA ancla lotes de resultados generados;
  • un sistema de cumplimiento publica una instantánea de control diaria;
  • un flujo de trabajo sella pruebas para destinatarios concretos;
  • un panel interno lee el estado de publicación y el saldo de la cuenta;
  • una integración de un socio envía registros sin tocar la interfaz de CardanoWall.

La vía de la API permite que tu software llame directamente a un gateway mientras tú conservas tu propia experiencia de usuario. La propia app web y el worker de CardanoWall acceden al gateway exactamente por estos mismos endpoints públicos: no hay puerta privada, así que todo lo que puede hacer el producto de referencia, lo puedes hacer tú también. Si quieres profundizar aquí, consulta construye sobre la API de CardanoWall.

¿Cómo funcionan los tokens y los alcances de la API?

Un gateway distingue dos tipos de credencial, y mantenerlas separadas es lo más importante que conviene hacer bien.

Los tokens de cuenta actúan en nombre de uno de tus usuarios. Tu backend acuña un token de corta duración para una cuenta concreta y la llamada se ejecuta con él: solicitar un presupuesto, subir contenido, publicar, leer el saldo de esa cuenta. Estos son los tokens —y las claves de API construidas sobre el mismo modelo— que deben ir en los scripts, los trabajos de CI y las integraciones. Son deliberadamente acotados. El conjunto actual de alcances es reducido y específico:

  • poe:create — solicitar presupuestos, subir contenido, publicar registros;
  • poe:read — leer registros y el estado de publicación;
  • inbox:read — leer el marcador cifrado de sincronización del Inbox;
  • account:read — leer el saldo de la cuenta.

Esa es toda la superficie programática, y está acotada a propósito. Un widget de panel de solo lectura solo necesita account:read. Un trabajo de publicación necesita poe:create. Ninguno necesita el del otro. No hay, de manera intencionada, ningún alcance de descifrado en el servidor: sellar y abrir registros sellados son operaciones del lado del cliente, así que las claves privadas del destinatario nunca llegan a un gateway y ninguna clave de API podría autorizar nunca al servidor a leer contenido sellado por ti. Del mismo modo, un trabajo de CI nunca debería tener la semilla de identidad de un usuario, a menos que la firma local sea una parte deliberada de tu propio diseño, bajo tus propios controles: las semillas y las claves privadas permanecen en el cliente por diseño y no son algo que un gateway llegue a ver.

Las credenciales de operador son el segundo tipo, y no son claves de API. Autorizan el plano de control: aprovisionar cuentas, aplicar ajustes de saldo cuando tu facturación cobra dinero, fijar márgenes, acuñar los tokens de cuenta anteriores. Deben residir únicamente en un backend de confianza, nunca en un navegador, una app móvil ni un script. Un token de cuenta filtrado debería ser una molestia pasajera; una credencial de operador filtrada sería un incidente de verdad.

La regla práctica: entrega a los clientes el token acotado a nivel de cuenta que necesitan, y mantén la autoridad de operador detrás de tu propio backend.

¿Cuándo debería usar la CLI?

Usa la herramienta de línea de comandos cuando una prueba deba vivir dentro de un script. El binario cardanowall es agnóstico respecto al gateway y prioriza la semilla en crudo, lo que lo convierte en una opción natural para:

  • verificar un registro localmente, sin abrir ninguna web;
  • construir y comprobar pruebas de Merkle sobre muchos archivos;
  • firmar registros;
  • enviar registros desde la automatización;
  • sincronizar el Inbox y hacer descifrados de prueba desde la terminal.

La CLI importa sobre todo porque mantiene la prueba de existencia cerca de los sistemas que generan los artefactos. Un pipeline de compilación puede calcular el hash de sus salidas y publicar un registro como parte de la versión. Un trabajo de cumplimiento puede registrar un manifiesto diario. Un usuario local puede verificar un registro sin conexión. La web es estupenda para las personas; la CLI es estupenda para las operaciones repetibles. Para patrones y ejemplos, consulta usa la CLI en la automatización.

¿Cuándo debería usar un SDK?

Usa un SDK cuando Label 309 deba formar parte de tu aplicación. Los SDK de TypeScript, Python y Rust ayudan a construir registros, calcular el hash del contenido, verificar transacciones, firmar fuera del host, sellar y descifrar cargas, derivar una identidad a partir de una semilla y hablar con cualquier gateway.

El sentido de tener tres SDK no es la comodidad: es la interoperabilidad. Son gemelos byte a byte, validados contra los mismos vectores de prueba canónicos, de modo que un registro publicado o firmado por uno se verifica de forma idéntica con los demás. Así es como un estándar abierto sigue siendo un estándar abierto en lugar de fragmentarse en formatos «compatibles» mutuamente incompatibles. Vale la pena destacar una propiedad útil: el verificador autónomo solo necesita los metadatos de la transacción, opcionalmente los bytes del contenido y un explorador público de Cardano; ningún servidor emisor se interpone en la ruta de confianza.

¿Cuándo debería usar Desktop en lugar de la web?

Usa la app de escritorio cuando la propiedad local importe. CardanoWall Desktop es un cliente de código abierto, multiplataforma y offline-first, construido en Rust con Tauri sobre el SDK de Rust, y funciona como un cliente de correo: te da

  • bóvedas de identidad locales y cifradas;
  • acceso sin conexión a todo lo que ya esté sincronizado;
  • descubrimiento del Inbox sellado y texto cifrado en caché en tu propia máquina;
  • búsqueda local sobre el índice público de registros;
  • varias identidades y la elección de tu proveedor de gateway.

La web sigue siendo rápida y cómoda, mientras que la app de escritorio es el mejor hogar cuando quieres que tus registros, identidades y archivos en caché vivan localmente y sigan funcionando sin red. Para mucha gente la respuesta serán las dos. Hay más sobre el diseño en CardanoWall Desktop y pruebas sin conexión.

¿Cuándo debería alojar yo mismo un gateway?

Aloja el gateway tú mismo cuando quieras operar el pipeline de publicación por tu cuenta: por cumplimiento, estructura de costes, volumen, política de manejo de datos, control de la infraestructura o estrategia de producto.

Un gateway autoalojado sigue publicando registros Label 309 estándar; la diferencia es que tú ejecutas el servicio que presupuesta, sube, envía, confirma, indexa y contabiliza la publicación. El gateway es un único binario de Rust de código abierto más Postgres, con su propio constructor de transacciones de Cardano que construye, envía, confirma, gestiona las reorganizaciones de la cadena y reembolsa automáticamente ante un fallo permanente.

Alojarlo tú mismo no es «gratis». Sigues pagando los costes subyacentes de Cardano y Arweave, y asumes la responsabilidad operativa de ejecutarlo. Lo que eliminas es cualquier dependencia de un gateway de CardanoWall alojado para publicar. Consulta ejecuta tu propio gateway y ¿qué es un gateway Label 309?.

¿Puedo construir mi propio producto sobre un gateway?

Sí, y esa separación es exactamente la razón por la que el gateway es una capa propia, distinta de la app web. Puedes construir un producto de notarización, un portal de pruebas, un archivo de cumplimiento, una herramienta de publicación, un servicio de procedencia para IA o un panel interno sobre un gateway Label 309.

El gateway es dueño del plano base: cadena, almacenamiento, precios, el índice compartido de registros en la cadena, los saldos y el estado de publicación. Tu producto es dueño del plano de proveedor: usuarios, facturación, interfaz, flujos de trabajo, notificaciones, soporte y cualquier significado específico de tu producto que pongas encima de los registros. Eso permite que muchos más productos compartan un mismo estándar de prueba sin que cada equipo tenga que convertirse en operador de transacciones y almacenamiento de Cardano. El recorrido está en construye sobre un gateway Label 309.

¿Puedo verificar sin CardanoWall en absoluto?

Ese es el objetivo, y es la razón más sólida por la que existe todo lo demás. La verificación no debe depender de la web de CardanoWall. Cualquiera debería poder leer los metadatos de la transacción, reconstruir el registro Label 309, validar su estructura, comprobar las firmas que haya en el registro, recalcular el hash del contenido y —con la clave correcta— descifrar un registro sellado localmente.

Una prueba que solo puede verificar una web es una prueba débil. Unos SDK abiertos, una CLI abierta y una especificación abierta son lo que hace que una prueba Label 309 sea verificable por cualquiera, incluidos terceros que nunca tocan CardanoWall. Si quieres hacerlo tú mismo, empieza por verifica un registro Label 309.

¿Y los precios?

Cambiar de interfaz no elimina el coste subyacente. Tanto si publicas desde la web, la app de escritorio, la CLI, la API o tu propio producto, alguien sigue pagando comisiones reales de transacción de Cardano más el almacenamiento que se use para archivos o texto cifrado. Un gateway alojado añade un margen encima para cubrir operaciones, financiación, infraestructura y soporte, así que el precio es el traslado del coste más ese margen.

Si usas el gateway alojado de CardanoWall, usas su modelo de saldo prepago y de precios. Si te lo alojas tú mismo, operas y financias tu propio gateway directamente. En cualquier caso, el estándar hace que el registro sea portable; no hace que las blockchains ni el almacenamiento sean gratis. El razonamiento está detallado en por qué publicar tiene un precio.

Un límite importante

Una prueba Label 309 demuestra que unos bytes concretos existían antes de una hora pública concreta y que no han cambiado desde entonces. No demuestra quién fue el autor del contenido, quién lo posee, si es verdadero ni si alguien tiene derechos sobre él. Un registro sellado mantiene su texto plano legible solo para los titulares de la clave previstos, pero no puede garantizar el anonimato ni puede impedir que un destinatario filtre el texto plano una vez que lo ha descifrado. Ten presente ese límite con independencia de la interfaz desde la que publiques.

La versión corta

CardanoWall no es solo una web. La web es la interfaz humana más sencilla; el gateway es la capa de publicación; la CLI y los SDK son las superficies para quienes programan; la app de escritorio es el cliente local y offline-first; el autoalojamiento es la vía del operador. Todos producen lo mismo: un registro Label 309 estándar que se puede verificar fuera de la interfaz que lo creó.

Elige la interfaz que encaje con el trabajo. Usa la web para las personas, la CLI para los scripts, los SDK para los productos, la API para los sistemas y un gateway autoalojado cuando lo que necesites sea la independencia del proveedor o el control operativo.

Para seguir leyendo

developersapigatewayself-hosting