Publicación en permaweb y extensiones de protocolo

Descentralización del frontend que acompaña a tus smart contracts.

Los assets estáticos se direccionan por TX ID y se sirven mediante gateways de Arweave - cambiar la UI significa publicar una nueva transacción, no editar un archivo del servidor.

• Direccionamiento por contenido: Cada archivo se mapea a un TX ID - referencias inmutables en lugar de un origen único que puedes reemplazar sin avisar.
• Routing con manifest: Las operaciones de Manifest en la API producen mapas ruta → TX (application/x.arweave-manifest+json) para que imports relativos y SPAs resuelvan por gateway.
• Sin host central: Muchos gateways pueden servir los mismos TX IDs; no hay un proveedor cuyo panel pueda despublicar la copia de la cadena.
• Coste de subida único: El almacenamiento se paga por subida a la red, no una suscripción recurrente para el bundle estático en sí.

¿Puedo actualizar mi dApp después del despliegue?

Sí - usa Arweave Manifests para crear una nueva versión del despliegue. Tu nombre ArNS siempre resuelve al manifest más reciente. Las versiones anteriores siguen accesibles de forma permanente por sus TX IDs como referencia histórica.

¿Cómo manejo datos dinámicos en una app permaweb estática?

Los assets estáticos (HTML, CSS, JS) viven en Arweave. Los datos dinámicos suelen venir de llamadas API a tu backend; las lecturas desde la red más amplia de Arweave usan gateways y exploradores públicos. Las arquitecturas híbridas con un backend tradicional para escrituras son comunes.

¿Cuál es la garantía de uptime para contenido alojado en Arweave?

Arweave no tiene un SLA en el sentido tradicional - es un protocolo descentralizado. Evercore enruta solicitudes a través de varios gateways para maximizar disponibilidad, pero el uptime de los gateways lo mantienen entidades separadas dentro del ecosistema Arweave.