3 puntos por GN⁺ 22 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Hardcore IndieWeb es una forma de conservar el original del contenido y los HTML y recursos web publicables en tus propios dispositivos, sin delegar tu identidad ni el control del contenido a un proveedor de servicios.
  • Si sigues el proceso de publicación al estilo de los años 90 —previsualizar el HTML en el navegador y luego subirlo al host— puedes operar un sitio sin CMS, SSG, frameworks, CLI ni suscripciones mensuales.
  • Solo necesitas un editor de texto, una herramienta SFTP y un host web; en NearlyFreeSpeech.net puedes operar un sitio estático por US$0.01 al día y cargar saldo desde US$0.25.
  • Puedes gestionar directamente como archivos la landing page, las publicaciones individuales, el archivo y el feed Atom, cambiar la estructura y el diseño en cada página y transferir solo los archivos modificados.
  • Aunque el host desaparezca, puedes subir el sitio terminado a otro lugar tal cual; pero mientras más herramientas agregues, más dependencias sumas, por lo que mantener el original local y la versión publicada es una condición para conservar la independencia.

La independencia que exige Hardcore IndieWeb

  • IndieWeb es un enfoque práctico para poseer directamente la identidad y el contenido en la web y librarse del control externo de las empresas.
  • Los servicios de blog por suscripción también pueden ayudar a participar en IndieWeb, pero si el contenido existe principalmente en bases de datos y servidores ajenos, no es completamente independiente.
    • Aunque se pueda exportar en un formato abierto, mientras se usa el servicio no se controla por completo el contenido.
    • Es un enfoque adecuado para quienes quieren independencia y control totales sobre su contenido, más que para quienes están conformes con los servicios existentes.
  • Hardcore IndieWeb aplica a los principios existentes de IndieWeb criterios concretos de control y portabilidad.
    • Si el contenido no está principalmente en tu propio disco duro, es difícil decir que lo controlas por completo.
    • Si no tienes en el disco duro una copia del HTML publicado y de los recursos web, el sitio no está en un estado completamente portable.
  • Si un servicio cierra y ya no permite exportar datos, aunque nominalmente tengas la propiedad del contenido, no podrás acceder a él ni trasladarlo.
  • Si quieres dejar un servicio por las acciones de sus operadores, quizá tengas que encontrar otro servicio que soporte el formato exportado, o convertir el contenido y cambiar herramientas y procedimientos.
  • Si tienes localmente el original del contenido y la versión publicada terminada, puedes mantener control y portabilidad incluso en esas situaciones.

Proceso de publicación web al estilo de los años 90

  • Hardcore IndieWeb sigue el método simple de publicación de los primeros tiempos de la web.
    1. Escribir el contenido en el disco duro
    2. Previsualizarlo en un navegador web
    3. Cuando esté listo, subirlo al host web y repetir cuando sea necesario
  • Además de un dominio, lo único necesario es un editor de texto, una herramienta de transferencia de archivos y un host web.
  • No se necesita un entorno de programación ni IDE, frameworks, shell, herramientas CLI ni suscripciones mensuales.
  • Hace falta saber HTML, pero se puede aprender con recursos como HTML for People, y es posible empezar con unas pocas etiquetas y copiar y pegar.
  • SaaS, CMS, SSG, lenguajes de marcado y sistemas de plantillas complejos son opcionales; la forma simple de publicar archivos directamente todavía funciona.

Herramientas y hosting necesarios

  • Puedes usar cualquier editor de texto siempre que pueda guardar archivos en el disco.
  • Para transferir archivos necesitas una herramienta que soporte SSH o SFTP.
    • FileZilla es una opción compatible con varios sistemas operativos.
  • Se recomienda NearlyFreeSpeech.net como host para sitios estáticos, y puede operarse por US$0.01 al día.
    • Adam Newbold usa este servicio desde 2008.
    • Puedes cargar saldo en la cuenta desde US$0.25 y agregar un sitio static, non-production.
    • En la pestaña Sites, al seleccionar el nombre del sitio, puedes ver la información de inicio de sesión para transferir archivos.
    • Se ofrece un subdominio gratuito, y puedes agregar un dominio propio en la pestaña Domains.
  • NearlyFreeSpeech no es obligatorio; también puedes elegir otro host web que ofrezca hosting básico de archivos estáticos.

Preparar un sitio existente y el HTML

  • Si un sitio o blog existente está en formato HTML, es fácil empezar de inmediato.
  • Si opera en otro formato, según el servicio puede exportarse o convertirse a HTML.
    • Para blogs grandes, conviene usar una herramienta de conversión.
    • Si es pequeño, puedes revisar las publicaciones y crear los archivos HTML directamente.
  • Quizá prefieras Markdown, pero HTML es el lenguaje de la web, y a veces es más sencillo trabajar con HTML puro que pelear con parsers de Markdown.
  • Si es difícil diseñar desde cero, puedes descargar y editar diseños y plantillas gratuitas como las de HTML5 UP.

Archivos que componen un blog

  • Un blog común se compone de landing page, publicaciones, página de archivo y feed, y se puede gestionar directamente sin un servicio de blog dedicado.
  • Landing page

    • Puedes colocar libremente publicaciones recientes completas o parciales, varias publicaciones o contenido que no sea una publicación.
    • Para mostrar publicaciones recientes, copia el contenido y agrega enlaces a las páginas independientes.
    • Para mantener las 5 publicaciones más recientes, pega la nueva arriba y elimina la más antigua de abajo.
    • Al no tener restricciones de CMS, SSG ni motores de plantillas, puedes cambiar la estructura y la presentación en cada página.
    • El archivo de la landing page debe llamarse index.html y estar en la raíz web.
    • La raíz web de NearlyFreeSpeech es /home/public.
  • Publicaciones del blog

    • Cada publicación se convierte en una página web; puedes crearla copiando el archivo de una publicación anterior y poniendo un nombre de archivo único y el contenido nuevo.
    • Como la estructura de archivos en el disco se refleja en la URL, organiza las carpetas según el esquema de direcciones que quieras.
    • Para usar la ruta /blog/, crea una carpeta blog en la raíz web.
    • Puedes usar nombres de archivo basados en slug, como the-best-lunch-i-ever-had.html.
    • Si pones un index.html dentro de una carpeta por publicación, puedes ocultar la extensión .html en la URL.
    • Si gestionas las publicaciones como archivos HTML independientes, no como Markdown ni entradas de base de datos, puedes dar a cada texto un estilo, apariencia, layout y personalidad diferentes.
    • La convención de que todas las publicaciones deben verse iguales proviene de herramientas modernas de publicación, y no tienes por qué seguirla en HTML hecho directamente.
  • Página de archivo

    • Crea una carpeta con un nombre como archive, coloca dentro un index.html y escribe la lista de publicaciones.
    • El orden y la organización son libres, e incluso puedes destacar tus publicaciones favoritas arriba de la página.

Gestionar directamente un feed Atom

  • Un feed RSS no es un sistema especial, sino un archivo guardado en el disco, así que puedes editarlo directamente con un editor de texto.
  • Puedes copiar el feed de ejemplo de la [página de Atom en Wikipedia](https://en.wikipedia.org/wiki/Atom_(web_standard>) y empezar con un archivo feed.xml.
    • Atom es compatible con RSS y cuenta con soporte generalizado.
    • Cambia valores como example.com, <title> y <subtitle> por tu dominio e información.
    • Crea un <entry> por cada publicación que quieras incluir en el feed e introduce fecha, hora, título, resumen, etc.
    • En <id>, usa un UUID nuevo obtenido en UUID Generator.
  • Puedes pegar el feed terminado en el W3C Feed Validation Service para comprobar si se puede parsear.
    • Si se detectan errores, el servicio de validación indicará qué elementos corregir.

Publicación y actualizaciones

  • En la primera publicación, conéctate al servidor con un programa de transferencia de archivos y copia todo el sitio al host web.
  • Después, basta con transferir solo los archivos nuevos o modificados.
    • Los elementos que suelen actualizarse son la landing page, la nueva publicación, el feed y la página de archivo.
  • El proceso de publicación puede resolverse al nivel de arrastrar y soltar archivos locales al servidor remoto.

Portabilidad y límites de las herramientas adicionales

  • Como el sitio terminado está en tu computadora, aunque el host existente desaparezca puedes subirlo tal cual a otro host.
  • No tienes que gestionar vulnerabilidades graves de seguridad de software de blogging ni dependencias de SSG, y puedes controlar directamente todos los aspectos del contenido.
  • Solo mantener este procedimiento tal cual permite seguir operando un sitio web completamente independiente.
  • Puedes agregar herramientas y procedimientos para ayudar al flujo de trabajo, pero cada herramienta adicional crea una nueva dependencia.
  • Si el original del contenido está en tus propios dispositivos y tienes una copia completa del sitio publicable, cumples las condiciones de Hardcore IndieWeb.

Autonomía al trabajar directamente con HTML

  • El procedimiento central es escribir HTML directamente y subirlo al servidor web.
  • Las capas tecnológicas, procedimientos y expectativas añadidos durante los últimos 30 años hicieron más complejo el trabajo web y llevaron a ceder control e independencia a otras personas.
  • Aunque uses servicios IndieWeb, si le confías al operador del servicio la única copia de toda tu presencia web, no eres completamente independiente.
  • Hardcore IndieWeb no es un método para todo el mundo, pero es adecuado para quienes valoran quién conserva sus textos y dónde y en qué forma se publican.
  • El proceso de trabajar directamente con HTML y copiar archivos a tu propio espacio de host web ofrece una experiencia directa y autónoma que reconecta con el placer de la web inicial.

1 comentarios

 
Opiniones en Hacker News
  • He venido alojando sitios estáticos gratis en GitHub Pages y Cloudflare Pages, y estoy muy satisfecho. Aunque pagues por NearlyFreeSpeech, al final sigues dependiendo de un hosting de terceros, así que el autoalojamiento no parece aportar mucho valor más allá de la satisfacción técnica.
    Lo importante es gestionar directamente activos como HTML e imágenes como simples archivos en disco. Gracias a la integración con Git, también tienes respaldos externos, y si haces push a master desde VS Code, se publica en menos de 30 segundos, mucho más cómodo que el antiguo FTP/SFTP.

    • GitHub Pages y Cloudflare Pages tienen la ventaja de que es más probable que el sitio sobreviva a su operador. Si lo alojas tú mismo, salvo que tengas un plan de sucesión, algún día inevitablemente se interrumpirá por el vencimiento del dominio o la cancelación de la tarjeta; con los servicios gratuitos, en cambio, solo existe la posibilidad de que desaparezcan.
    • La diferencia entre pagar y convertirte en cliente, en lugar de ser el producto, es bastante grande.
    • Mi blog también funciona de la misma manera: https://gigatexal.blog
  • NearlyFreeSpeech también es un buen servicio, pero no es completamente independiente. Si quieres acercarte lo más posible a la independencia sin tener tu propia infraestructura de internet, puedes operar el sitio desde casa con port forwarding o como servicio oculto de Tor.
    Configurar el puerto en torrc no es difícil, pero los visitantes también necesitan Tor Browser, y es complicado explicar que el sitio está en la “dark web”. Es sorprendente que no se use más en el movimiento de la web independiente, considerando que puedes operarlo desde casa con hardware propio y ocultar también la IP del servidor. También se puede redirigir un dominio normal a una dirección .onion.
    Beaker Browser, que permitía crear y alojar sitios directamente desde el navegador, fue descontinuado, pero herramientas como un plugin para crear sitios para Tor podrían ayudar a su adopción.

    • Un servicio .onion se puede levantar fácilmente, es más seguro que la web normal y puede ejecutarse incluso en un teléfono.
      Nanogram: https://gitlab.com/here_forawhile/nanogram
      Spreadsheet Server: https://gitlab.com/here_forawhile/spreadsheet
      Library Server: https://gitlab.com/here_forawhile/libraryserver
      Torum: https://gitlab.com/here_forawhile/torum
    • Tor Browser admite Onion-Location y Alt-Svc para descubrir direcciones .onion en la internet normal. Onion-Location permite que un sitio HTTPS normal anuncie su servicio Onion, mientras que Alt-Svc lo descubre y cambia automáticamente sin acción adicional del usuario.
      En el futuro también podría haber conexiones Onion basadas en DNS o DNSSEC: https://onionservices.torproject.org/research/proposals/usab...
    • Lo perfecto es enemigo de lo bueno. En una realidad donde también dependemos de operadores de telecomunicaciones y fabricantes de equipos, NearlyFreeSpeech es un compromiso de bajo riesgo; no tiene historial de abusar de la confianza de los usuarios y su costo es prácticamente mínimo.
    • Tor no es un navegador, es un servicio. Tor Browser es solo un paquete conveniente que combina un navegador orientado a la privacidad con el servicio Tor, así que se puede operar un sitio Tor en un servidor headless sin navegador.
    • La razón por la que los servicios ocultos son raros es que les exigen demasiado esfuerzo a los visitantes. Hay una gran diferencia de accesibilidad entre decirles minombreapellido.com y pasarles una dirección .onion aleatoria de 56 caracteres, además de instalarles Tor Browser en el teléfono.
  • En esta tendencia, la mayor barrera es el nombre de dominio necesario para poseer el contenido; aunque sea barato, cuesta alrededor de 6 dólares al año. Los sitios estáticos se pueden alojar gratis en muchísimos lugares, y para una persona el nivel gratuito de un CDN es suficiente.
    Más importante que autoalojar el servidor es poseer un identificador único como el dominio; a dónde apunte ese dominio importa mucho menos.

    • La ingeniería de software ha sido impulsada por personas inteligentes que prueban cosas no por necesidad, sino por curiosidad. Al contratar, también valoraba la curiosidad y el empuje por encima de los títulos.
    • 6 dólares al año son aproximadamente 0.016 dólares al día; aunque sea más caro, sigue siendo barato.
    • En realidad, no sé en qué parte del texto se decía que había que alojar un servidor propio.
  • Da risa que subir tus propios archivos a un servidor web se trate como si fuera un concepto nuevo.

    • En una época en la que mucha gente ni siquiera sabe qué es un archivo, es importante mantener vivo ese espíritu.
    • Es triste que toda internet se haya convertido en un monstruo alojado y controlado por unas pocas megacorporaciones, hasta el punto de que hizo falta un nuevo concepto como IndieWeb. Alojar archivos no debería ser un privilegio, sino algo cercano a un derecho humano desde el principio.
      La tecnología para alojar por cuenta propia todavía existe, pero la mentalidad cambió a “solo cloud”.
    • Antes bastaba con poner archivos en la carpeta public_html y de inmediato tenías un sitio web personal. Eso no significa que tuvieras que seguir escribiendo HTML a mano para siempre, pero en esa época era una forma rápida y natural de participar en la web.
      Las cuentas Unix incluso ofrecían chat entre personas: podías usar finger para ver si un amigo estaba conectado y talk o ytalk para conversar; aunque tu amigo estuviera sentado en la terminal de al lado, se sentía como magia.
    • Esperen a que los niños conozcan el hardware
  • Si NearlyFreeSpeech, que cuesta 0.01 dólares al día, es “operación 100% independiente”, no parece haber gran diferencia con el hosting estático de Vercel, Netlify, GitHub o Cloudflare.
    El artículo no dice qué hacer cuando se necesita una base de datos, formularios de feedback, vistas previas para redes sociales u optimización para motores de búsqueda; quizá esa ausencia sea parte de las condiciones de la “web independiente”.

    • En NearlyFreeSpeech se pueden usar PHP y bases de datos.
    • Si no hay gran diferencia entre NFS y Vercel, los usuarios deberían estar divididos mitad y mitad; me pregunto por qué la mayoría elige Vercel.
    • NFS ofrece un entorno Linux completo con varios lenguajes de programación instalados, así que también soporta sitios web dinámicos, aunque cuesta más.
    • También hubo alguien que recibió una factura de Netlify de 100 mil dólares estando en el plan gratuito.
  • Necesitaba un dominio para el sitio web de un evento, y Infomaniak ofrecía también 10 MB de almacenamiento junto con el dominio. Por unos 5 euros al año se podía conseguir tanto el dominio como el sitio, así que no está mal.

  • Creé un plugin JavaScript para comentarios que guarda todos los datos dentro de un repositorio Git: https://github.com/est/req4cmt. Se puede usar si el servicio Git soporta HTTP, se ejecuta en Cloudflare Worker gratis, y las copias de seguridad y migraciones se resuelven con git clone y push.
    También hay un proyecto alternativo a Twitter basado en Git: https://github.com/est/gitweets
    La demo está en https://f.est.im/ y también soporta comentarios usando Git notes. Gracias a Cloudflare Workers y GitHub Pages, todo es completamente gratis.

  • sdf.org es útil para desarrolladores que quieren aprender directamente un sistema Unix. Ofrece cuentas shell gratuitas de NetBSD Unix, y recuerdo que con una pequeña donación única se podía acceder a espacio web y funciones adicionales.
    El nombre de login se convierte en el subdominio del espacio web, así que conviene elegirlo con cuidado.

  • Da gusto que un sitio que hace este tipo de afirmaciones no esté alojado en Cloudflare ni GitHub Pages.

    • GitHub Pages es hosting gratuito que ofrece dominio y SSL, no cobra costos y tiene buenas perspectivas a largo plazo. Si no quieres preocuparte por un sitio estático, los grandes proveedores como GitHub y Cloudflare parecen la mejor opción.
    • Suelo recomendar GitHub Pages, pero también escribí cómo hostear desde una Raspberry Pi en el dormitorio: https://joeldare.com/private-analytics-and-my-raspberry-pi-4...
    • Se agradece que Cloudflare siga manteniendo vivos los sitios pirata.
    • Vercel y Netlify también son así.
  • Prefiero aprender y poseer el proceso antes que una herramienta específica. Se trata de crear HTML desde un formato fácil de leer y escribir como Markdown usando herramientas como Pandoc, aprender a subir o sincronizar HTML, CSS y JavaScript con un servicio de hosting, poseer un dominio y aprender a conectar el DNS a GitHub Pages o Cloudflare Pages.
    Como no dependes de una herramienta, servicio, plataforma o empresa específica, puedes mover tus archivos de contenido a otro lugar cuando quieras. El proceso de convertir el Markdown original a HTML se puede automatizar con un generador de sitios estáticos.
    Saber HTML es útil y divertido, pero no tiene por qué ser un requisito indispensable para “operar un sitio de forma 100% independiente”. Puedes operarlo por 0 dólares al mes en GitHub y Cloudflare, y si el servicio cierra o pasa a ser de pago, lo mueves a otro lugar.

    • La idea central del artículo es que, si las publicaciones se dejan como archivos HTML individuales en lugar de Markdown o entradas de una base de datos, cada página puede tener su propio estilo, apariencia, disposición y personalidad. Es posible salir del molde uniforme de blog que crean las herramientas de publicación modernas y hacer que cada publicación sea distinta.
    • HTML es un formato adecuado para que las personas lo lean y escriban. Incluso antes de que aparecieran herramientas adecuadas, personas que ni siquiera estudiaban ciencias de la computación trabajaban directamente con HTML, JavaScript y CSS en editores de texto; para sitios simples no es difícil.
      Si quieres poseer el proceso y tener independencia total, debes poder entender y manejar directamente los lenguajes de la web. Los generadores de sitios estáticos como Nikola son convenientes, pero si no puedes entender o modificar directamente su salida, sigues dependiendo de una herramienta de terceros.