- IndieWeb es una comunidad y una alternativa centrada en las personas frente a la web corporativa, que preserva contenido, identidad y conversaciones en un dominio personal mientras se conecta con redes sociales cuando hace falta
- Basado en un dominio propio, combina estándares pequeños como microformats2,
rel="me", Webmention, IndieAuth y Micropub para hacer que el HTML sea legible por máquinas y para permitir autenticación, publicación y conversación entre sitios - Desaparecieron 23 millones de páginas de GeoCities y más de 50 millones de canciones de MySpace; además, una investigación de Pew Research de 2024 mostró que el 38% de las páginas web que existían en 2013 ya no eran accesibles 10 años después
- POSSE publica primero el original en tu propio sitio y luego lo distribuye a plataformas externas, mientras que Backfeed devuelve al original los likes, respuestas y republicaciones externas mediante Webmention para conservar toda la conversación en el dominio personal
- En un sitio real se aplicaron Webmention, h-entry, h-card y
rel="me", pero se dejaron fuera Micropub, IndieAuth y WebSub porque no encajaban con un flujo de trabajo existente basado en Git y Markdown ni con un retraso de publicación de 24 horas; más que adoptar todas las especificaciones, conviene aplicar gradualmente primero la tecnología que realmente necesitas
La web que busca IndieWeb
- IndieWeb se define como “una alternativa centrada en las personas frente a la web corporativa”, y se parece más a una base ideológica que acoge múltiples enfoques y proyectos que a un software o framework específico
- En 2010, Aaron Parecki y Tantek Çelik asistieron al Federated Social Web Summit en Portland y concluyeron que hacía falta un enfoque centrado en los creadores más que en los protocolos
- En 2011 se celebró el primer IndieWebCamp en Portland, y desde entonces se organiza cada año en distintas partes del mundo
- En el Homebrew Website Club, los participantes se reúnen para mejorar sus sitios web personales
- Los tres pilares de IndieWeb son los siguientes
- Propiedad del contenido: el contenido publicado en la web debe pertenecer a quien lo publica, no a una empresa
- Mejor conectividad: debe ser posible distribuir una publicación en múltiples plataformas y traer de vuelta a tu sitio las respuestas y los likes externos
- Control: debes poder publicar y leer en el formato que quieras, y mantener URLs permanentes
- No prohíbe el uso de redes sociales, pero sí se opone a los ecosistemas cerrados que encierran el contenido y la interacción
Los silos y la desaparición del contenido web
- Un silo es, por lo general, un sitio web centralizado operado por una empresa con fines de lucro que reclama derechos sobre el contenido aportado por los usuarios o restringe su acceso
- Para participar, necesitas una cuenta específica del servicio
- Solo puedes interactuar con cuentas del mismo servicio
- También pueden existir términos de uso restrictivos, exigencias de licencia sobre el contenido, bloqueo del indexado en buscadores y barreras para importar o exportar
- Cuando un silo cierra, el contenido del usuario puede desaparecer con él
- GeoCities desapareció el 26 de octubre de 2009 cuando Yahoo lo cerró, llevándose 23 millones de páginas
- MySpace perdió en 2019, durante una migración de servidores, más de 50 millones de canciones subidas por 14 millones de artistas en sus primeros 12 años
- Google+ cerró en abril de 2019
- Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter y Cohost también están en la lista de servicios cerrados
- Incluso si un silo no cierra, el contenido web puede desaparecer
- Según una investigación de Pew Research de 2024, el 38% de las páginas web que existían en 2013 ya no eran accesibles 10 años después
- El principio de respuesta no es dejar de usar redes sociales, sino mantener la copia canónica del contenido en un dominio bajo tu control
Los 11 principios de la comunidad
- Los 11 principios no son un orden de prioridad ni una obligación de cumplimiento total
- Propiedad de los datos: mantener contenido, metadatos e identidad en tu propio dominio y conservar el acceso a largo plazo
- Usar y publicar datos visibles: priorizar a las personas y después a las máquinas; si los datos pueden ir en HTML, no crear una API aparte
- Construir lo que necesitas para ti: crear herramientas para ti mismo, no para usuarios hipotéticos cuya existencia ni siquiera está clara
- Usarlo tú mismo: usar a diario lo que construyes y comprobar si realmente vale la pena depender de ello
- Documentar: registrar procesos, ideas y código en tu propio sitio para ayudar a otras personas y a tu yo futuro
- Hacerlo open source: no es obligatorio, pero ayuda a que otras personas se sumen antes a la web independiente
- UX antes que protocolos: definir primero la experiencia de usuario y usar solo los protocolos más simples y pequeños que la respalden
- Modularidad: crear componentes pequeños y débilmente acoplados para no depender de un dispositivo, lenguaje o plataforma concretos
- Permanencia a largo plazo: construir tecnologías web que no obliguen a descartar trabajo previo cada pocos años por el simple hecho de evolucionar
- Pluralidad: fomentar deliberadamente múltiples enfoques para construir una comunidad más resiliente que una cultura tecnológica única
- Diversión: conservar una expresión personal extraña e interesante, como en la web de los años 90
La estructura técnica que empieza con un dominio personal
- Usar un dominio propio como identidad principal en línea es la base de toda la configuración
- Aunque cambies de hosting o CMS, si conservas el dominio puedes mantener enlaces, lectores y posicionamiento en buscadores
- También es la condición mínima que la comunidad reconoce como participación en IndieWeb
- En vez de una sola plataforma, IndieWeb usa pequeñas especificaciones combinables, y el índice oficial de especificaciones está organizado según el historial de implementación y el grado de adopción
microformats2: usar HTML como API
- microformats2 hace que el contenido sea legible por máquinas agregando clases CSS al HTML existente, sin archivos ni APIs aparte
h-*: objeto raízp-*: texto planou-*: URLdt-*: fechae-*: HTML incrustado
- h-card representa identidad personal, como nombre, URL y foto, y permite que las aplicaciones muestren el perfil junto a una publicación y reconozcan al usuario
- A diferencia de Gravatar, basado en email, funciona a partir del dominio
- h-entry es el componente central del contenido de IndieWeb y marca el título, autor, fecha de publicación y cuerpo de una entrada
- h-feed agrupa varias h-entry y convierte la propia página HTML de listado en un feed al que se puede suscribir uno
- Al usar microformats para leer y Micropub para escribir, se forma una estructura en la que “el sitio web es la API”
rel="me" y la verificación de identidad distribuida
rel="me"declara que el destino del enlace representa a la misma persona que la página actual- Si un sitio web y un perfil externo se enlazan mutuamente con
rel="me", es posible una verificación mutua de identidad sin una autoridad central- Mastodon usa esta estructura para mostrar una marca de verificación verde en el dominio
- También lo soportan Threads, PixelFed, GitHub, Keybase y Wikipedia
- RelMeAuth delega la prueba de identidad a proveedores OAuth como GitHub enlazados desde la página principal, permitiendo iniciar sesión en servicios con una URL personal
- Es la base de servicios como IndieLogin
Webmention: conversaciones entre sitios web
- Webmention es una Recomendación del W3C desde el 12 de enero de 2017 y, como sucesor de Pingback, transmite comentarios, likes, respuestas y republicaciones entre sitios sin depender de una plataforma
- El proceso de envío es el siguiente
- La publicación emisora incluye un enlace al artículo de destino
- El servidor emisor busca el endpoint receptor en el encabezado HTTP
Linkdel artículo de destino o en el HTML<link rel="webmention"> - Envía una petición POST que solo contiene
source, la URL emisora, ytarget, la URL de destino - El servidor receptor descarga
sourcey verifica que realmente contenga el enlace atarget - Analiza la h-entry de
sourcepara distinguir si es respuesta, like o republicación, y muestra con h-card el nombre y la foto del autor
- Cada sitio se convierte en un nodo y los enlaces entre sitios forman un grafo social, aunque siguen existiendo problemas de spam y moderación
- Vouch permite que el receptor reciba como tercer parámetro un sitio avalador que ya conoce y que enlaza al dominio emisor, trasladando al emisor el costo del filtrado
- Salmention hace que, cuando una respuesta recibe otra respuesta, la publicación original envíe de nuevo Webmentions de actualización a los participantes para propagar el hilo de conversación
- Para sitios estáticos sin backend, webmention.io puede recibir Webmentions en su lugar y ofrecer una API de consulta
- Puede usarse con generadores de sitios estáticos como Hugo, Jekyll y Eleventy
Inicio de sesión y publicación basados en dominio
- IndieAuth usa una URL personal como identidad de inicio de sesión en lugar de una cuenta de Google o Facebook
- Está basado en OAuth 2.0 y usa URLs para identificar tanto al usuario como a la aplicación
- El DNS sustituye el registro previo del cliente, y PKCE es obligatorio para evitar el robo de tokens de acceso
- El servicio encuentra el servidor de autorización en
rel="indieauth-metadata"de la página del usuario y, tras completar la autenticación, confirma el control sobre esa URL - Como métodos de autenticación pueden usarse contraseña, email, RelMeAuth, etc.
- Micropub es una Recomendación del W3C desde mayo de 2017 y separa el software del sitio de la interfaz de publicación
- Los clientes web, iOS y Android pueden crear, editar y borrar publicaciones del dominio personal
- En lugar de MetaWeblog y AtomPub, que compartían contraseñas, usa tokens OAuth obtenidos mediante IndieAuth
- No crea un vocabulario aparte, sino que serializa y envía propiedades de h-entry como
h=entryycontent
Feeds en tiempo real y lectores desacoplados
- WebSub, antes llamado PubSubHubbub, es una Recomendación del W3C desde enero de 2018
- En vez de que el suscriptor consulte periódicamente al servidor, el publicador notifica al hub sobre una nueva entrada y el hub la entrega de inmediato al suscriptor mediante webhooks
- Reduce la carga del servidor y elimina el retraso de actualización; servicios como Feedly y NewsBlur lo soportan
- Microsub es la especificación más reciente, aún en borrador, y divide las aplicaciones de lectura social en dos capas
- El servidor se encarga de la gestión de suscripciones, recolección y análisis de feeds, y normalización de datos
- El cliente solo muestra la interfaz de lectura, por lo que puede competir en UX y la información de suscripción puede moverse entre clientes
- Si se combinan la publicación de respuestas con Micropub y las notificaciones de Webmention, se completa la estructura de un lector social de IndieWeb
POSSE, PESOS y Backfeed
- POSSE es la estrategia recomendada de publicar primero en tu sitio y luego distribuir afuera
- La copia externa incluye un enlace al original, así que el lector puede seguir leyendo en su plataforma habitual mientras el autor conserva la versión canónica
- Aunque la plataforma cierre o bloquee la cuenta, el original sigue existiendo
- Tantek Çelik acuñó el término en 2012, y lo usan personas como Cory Doctorow y Molly White
- Al efecto por el cual los sitios de spam que copian una publicación también terminan copiando el enlace al original se le llama “aikido de internet”
- PESOS es el enfoque inverso: publicar primero en un silo y luego copiarlo a tu sitio para archivarlo
- Permite usar aplicaciones de silo más pulidas y seguir publicando aunque tu sitio personal se caiga
- Pero desde el inicio quedas sujeto a los términos del silo, la copia en tu sitio no es la versión canónica y además heredas limitaciones como conteos de caracteres o enlaces
t.co
- Backfeed devuelve al original, mediante Webmention, los likes, respuestas y republicaciones de las copias externas
- Bridgy observa copias en Mastodon, GitHub, Flickr, Reddit y Bluesky, y envía un Webmention por cada interacción
- Como resultado, toda la conversación generada en plataformas externas puede conservarse en el dominio personal
Relación con el Fediverse y RSS
- Webmention, Micropub, WebSub y ActivityPub surgieron del W3C Social Web Working Group, pero siguen filosofías distintas
- El Fediverse federa servidores y representa la identidad como
@user@instance, así que si no administras tu propia instancia, dependes del operador de otra- Operar una instancia implica el alto costo de moderación y mantenimiento llamado admintax
- IndieWeb federa sitios web y usa el dominio personal como identidad, tratando la federación como uno más entre varios canales de distribución
- Bridgy Fed convierte entre h-card, h-entry y Webmention por un lado, y ActivityPub y el AT Protocol de Bluesky por el otro
- Un dominio personal se convierte en una cuenta del Fediverse con forma
@example.com@example.com - Esa cuenta puede buscarse y seguirse desde Mastodon, y las respuestas vuelven a la publicación original mediante Backfeed
- Un dominio personal se convierte en una cuenta del Fediverse con forma
- IndieWeb considera que RSS y Atom obligan a mantener una copia XML separada del HTML, lo que crea costo de mantenimiento y posibles inconsistencias
- Algunos archivos Atom son hasta 4.5 veces más grandes que el HTML del mismo contenido
- Además, la experiencia de abrir directamente un enlace de feed no es buena para las personas
- La alternativa, h-feed, usa el propio HTML como feed, pero muy pocos lectores lo soportan
- Por eso se recomienda ofrecer h-feed en el entorno IndieWeb y también RSS o Atom para lectores generales
Orden para empezar
- Getting Started recomienda este orden
- Conseguir un dominio: usarlo como identidad principal en línea y elegir protección de privacidad WHOIS solo si confías por completo en el proveedor
- Configurar el hosting: si eres principiante, usar servicios administrados como GitHub Pages, Netlify o Neocities; si tienes experiencia, hospedar por tu cuenta
- Crear una página: puedes usar un generador de sitios estáticos, HTML escrito a mano o un CMS; no hay una tecnología oficial
- Aplicar POSSE: distribuir a otras plataformas incluyendo el enlace al original
- Agregar microformats: poner
rel="me"en la página principal y h-entry en las publicaciones - Validar: comprobar paso a paso rel-me, h-card y h-entry con IndieWebify.me
- Participar en la comunidad: compartir lo que hiciste aunque sea una sola página, y documentarlo en la wiki para la siguiente persona
- IndieMark es una escala por etapas para desarrolladores que quieren adoptarlo gradualmente
Implementación real y funciones descartadas
- En el sitio real se aplicaron los siguientes elementos
- Envío y recepción de Webmention: se automatiza una tarea diaria para notificar los enlaces externos de nuevas publicaciones, dejando un margen de 24 horas para corregir errores tipográficos
- Los Webmentions recibidos se usan en la lista de referencias al final de cada entrada y se mantienen separados de los comentarios gestionados por email
- Se aplicó h-entry a todas las publicaciones y h-card a la página principal, validándolo con mf2py
- En el pie de página se enlazaron Mastodon, GitHub y Org Social con
rel="me"para obtener la marca de verificación
- Se excluyeron los elementos que no encajaban con las necesidades ni con el flujo de trabajo existente
- Micropub e IndieAuth: como el editor y Git son la interfaz de publicación y los textos se escriben en Markdown con control de versiones, no hace falta un endpoint de publicación independiente
- WebSub: como la publicación se retrasa intencionalmente 24 horas, la entrega en tiempo real no justifica la complejidad adicional
- h-feed: la plantilla de tarjetas de artículos también se reutiliza dentro del cuerpo, por ejemplo en secciones de recomendación, y un parser podría interpretarlas ambiguamente como h-entry; además, RSS ya cumple bien esa función
Principios prácticos que duran más que la tecnología
- El HTML normal es el formato más duradero para leer contenido completo sin necesidad de JavaScript
- Según el principio “Cool URIs don't change”, hay que diseñar URLs que puedan mantenerse para siempre
- En el sitio real, aunque cambie el slug de una entrada, la URL anterior sigue funcionando
- No hace falta abandonar los silos de golpe: es posible una transición gradual publicando primero en tu sitio según el tipo de contenido
- También conviene pensar en una permanencia extrema a largo plazo
- Se puede considerar un “dead man's switch” para pasar las llaves del sitio a una persona de confianza después de la muerte
- También hay que resolver quién pagará el dominio cuando el operador ya no esté
- Encaja mejor con los principios de IndieWeb gestionar con gusto un sitio web personal imperfecto y único que mantener una plantilla perfecta pero aburrida
1 comentarios
Opiniones en Hacker News
Si IndieWeb quiere contenido, enterrarlo bajo una pila tecnológica compleja es exactamente lo contrario
Este conjunto de protocolos es, en la práctica, inutilizable para el 90% de los usuarios, y si se quiere priorizar la experiencia de uso del contenido, hace falta una solución de un clic que permita empezar de inmediato
En el momento en que exiges línea de comandos, Docker o editar HTML/CSS a mano, creas una barrera que la mayoría no puede cruzar; tal como está ahora, parece más NerdNet que IndieWeb
micro.blog, el principal punto de entrada de un clic, ofrece un sitio personal con funciones modernas de IndieWeb por 5 dólares al mes
Como la mayoría de los interesados hoy son desarrolladores que quieren montarlo por su cuenta, los textos relacionados parecen llenos de tecnicismos, pero atraer a no desarrolladores también es un cambio que la comunidad desea. David Shanske ha estado creando durante la última década plugins de WordPress que incluyen herramientas de IndieWeb por defecto: https://profiles.wordpress.org/dshanske/#content-plugins
Tampoco hace falta usar toda la tecnología para ser IndieWeb. Puedes empezar con un dominio propio, crear páginas con HTML, Markdown, Django, etc., e ir agregando microformatos y Webmention poco a poco; en cualquier etapa ya puede considerarse un sitio IndieWeb
Internet era mejor cuando era un lugar donde la gente interesante se reunía por cuenta propia, antes de convertirse en un Walmart global
Internet siempre ha avanzado empezando por cosas difíciles pero divertidas hechas por raros, que luego se vuelven gradualmente más fáciles para la gente común. IndieWeb también está en una etapa temprana; si sobrevive, la masificación llegará sola, así que por ahora hay que dejar que sigan construyendo
El problema es la viabilidad económica. Las soluciones de un clic suenan bien, pero IndieWeb resuelve un problema ideológico, no uno urgente para el usuario, así que es difícil conseguir clientes que paguen la inversión o el costo operativo del servicio
micro.blog es lo más cercano, pero como es un servicio centralizado que no puede ejecutarse sobre infraestructura propia, aunque tenga compatibilidad con protocolos no es una herramienta IndieWeb completa
Hay posibilidades como el registro de actividad de agentes o herramientas de publicación para sensores y servidores, pero sin demanda real de usuarios parece difícil que eso funcione como un servicio terminado
En vez de ceder ante lo popular, hay que alentar a la gente a crear lo que quiere. Los perfiles de marketing que se enfocan en rentismo y lobby en vez de crear valor real empeoran la sociedad, así que haría falta menos de eso
La forma de pensar de Nostr me parece más cercana a POSSE que Mastodon o AT Protocol, y por eso la prefiero
Mantengo un blog con regularidad y también soy dueño de mi dominio y de mis publicaciones, pero si por usar WordPress eso no cuenta como IndieWeb, entonces al final igual dependo de una empresa. Incluso blogs que hice antes en Blogger siguen ahí casi intactos desde hace cerca de 10 años
Tener el servidor por cuenta propia no es realista. Si es un servidor virtual, está en la nube de Amazon o Microsoft; y aunque sea un servidor físico, tendría que estar en el centro de datos de una empresa, y es difícil encargarse también de un UPS y de una conexión permanente a internet
Las alternativas anteriores por lo general se quedaban en perseguir nostalgia noventera, así que fuera de un rato de nostalgia era difícil verles utilidad, pero este enfoque sí se ve distinto
Acepta la web moderna y al mismo tiempo permite que el creador controle por completo su propio espacio. Cuando tenga tiempo, me gustaría hacer que el blog myzopotamia.dev participe en IndieWeb
indiekit básicamente trae todo el paquete de funciones de IndieWeb. Lo uso en https://rmendes.net y también estoy trabajando para implementarlo en https://textcaster.app
El problema del principio DRY en los feeds RSS parece exagerado. No recuerdo la última vez que hubo problemas para generar automáticamente un feed RSS sin importar con qué framework open source estuviera hecho
h-entry, termina siendo frustrante tener que mantener dos versiones del mismo contenido y además XMLRSS fue inventado justo antes de la revolución del marcado semántico, cuando recién terminaban los layouts basados en tablas, así que le tocó un mal momento
Me incomoda cuando veo en sitios que se presentan como IndieWeb una bio del autor, foto de rostro hecha por un profesional, trayectoria en instituciones prestigiosas y un blog pulido
Se parece a entrar a una tienda de ropa bien iluminada en un centro comercial elegante donde todos los productos tienen símbolos anarquistas, y al mirar de cerca las etiquetas de precio están casi en cuatro cifras
Un sitio personal puede ser lo que uno quiera. El mío también se ha vuelto cada año más personal y centrado en hobbies desde que dejé de necesitarlo para buscar trabajo, pero un sitio sigue siendo producto de la sociedad en la que vive esa persona y también hay que ganarse la vida
Mi vida profesional también es parte de lo que soy, y en el sentido de ser autónomo incluso podría llamarme trabajador independiente, así que no veo por qué eso sería malo
IndieWeb no rechaza lo profesional; sostiene que el contenido debe pertenecer a uno mismo y sobrevivir más que las plataformas. Una foto de rostro, un currículum y un blog pulido están bien; lo criticable es encerrarlos dentro de plataformas que pueden cerrar, vender tus datos o desaparecer
Hacer que las máquinas lean contenido sin archivos paralelos ni API era, desde el inicio, un problema que casi no necesitaba resolverse
Igual que con ontologías anteriores, eso termina alimentando de datos a entidades inútiles u hostiles sin aportar nada a los visitantes humanos
Está bien compartir de forma constante otros blogs que te gusten. IndieWeb depende del boca a boca y de la curaduría humana, así que sirven mucho los posts tipo “lo que disfruté este mes”
También hace falta elogiar sin tacañería, mandar correos de agradecimiento e iniciar conversaciones. Un sitio estático sin rastreo de usuarios puede sentirse como hablar solo, así que los mails de lectores animan muchísimo
Como corresponde a un sitio personal, está bien que sea imperfecto y raro, y no todo el contenido tiene que ir en un feed cronológico. Puedes organizar tu espacio como quieras, como un jardín digital
Me pregunto si sabían que el dominio
.devpertenece a Google