O que aprendi ao participar da IndieWeb

 (en.andros.dev)
2 pontos por GN⁺ 18 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • IndieWeb é uma alternativa e uma comunidade centrada nas pessoas para a web centrada em empresas, preservando conteúdo, identidade e conversas em um domínio pessoal, enquanto se conecta a redes sociais conforme necessário
  • Com base em um domínio próprio, combina pequenos padrões como microformats2, rel="me", Webmention, IndieAuth e Micropub para tornar o HTML legível por máquinas e oferecer suporte a autenticação, publicação e conversas entre sites
  • 23 milhões de páginas do GeoCities e mais de 50 milhões de músicas do MySpace desapareceram; uma pesquisa da Pew Research de 2024 também mostrou que 38% das páginas da web existentes em 2013 estavam inacessíveis 10 anos depois
  • POSSE publica primeiro o original no próprio site e depois distribui para plataformas externas; Backfeed devolve curtidas, respostas e republicações externas ao original via Webmention, preservando toda a conversa no domínio pessoal
  • No site real, foram aplicados Webmention, h-entry, h-card e rel="me", mas Micropub, IndieAuth e WebSub foram excluídos por não se adequarem ao fluxo de trabalho existente com Git e Markdown nem ao atraso de 24 horas na publicação; em vez de adotar todas as especificações, é mais adequado aplicar gradualmente as tecnologias necessárias primeiro

A web que a IndieWeb busca

  • IndieWeb se define como uma “alternativa centrada nas pessoas à web corporativa” e é mais próxima de uma base ideológica que acolhe várias abordagens e projetos do que de um software ou framework específico
  • Em 2010, Aaron Parecki e Tantek Çelik participaram do Federated Social Web Summit em Portland e concluíram que era necessária uma abordagem centrada nos criadores em vez de protocolos
    • Em 2011, o primeiro IndieWebCamp foi realizado em Portland e, desde então, acontece anualmente em várias partes do mundo
    • No Homebrew Website Club, participantes se reúnem para melhorar seus próprios sites pessoais
  • Os três pilares da IndieWeb são os seguintes
    • Propriedade do conteúdo: o conteúdo publicado na web deve pertencer ao publicador, não a empresas
    • Melhor conectividade: deve ser possível distribuir posts para várias plataformas e trazer respostas e curtidas externas de volta para o próprio site
    • Controle: deve ser possível publicar e ler no formato desejado e manter URLs permanentes
  • Ela não proíbe o uso de redes sociais em si, mas se opõe a ecossistemas fechados que aprisionam conteúdo e interações

Silos e o desaparecimento de conteúdo na web

  • Um silo geralmente é um site centralizado operado por uma empresa com fins lucrativos que reivindica direitos sobre conteúdo contribuído por usuários ou restringe o acesso a ele
    • Para participar, é necessária uma conta específica do serviço
    • Só é possível interagir com contas do mesmo serviço
    • Também podem existir termos de uso restritivos, exigências de licenciamento de conteúdo, bloqueio de indexação por buscadores e barreiras para importar e exportar dados
  • Quando um silo é encerrado, o conteúdo dos usuários pode desaparecer junto
    • GeoCities foi encerrado pelo Yahoo em 26 de outubro de 2009, fazendo desaparecer 23 milhões de páginas
    • MySpace perdeu mais de 50 milhões de músicas enviadas por 14 milhões de artistas nos primeiros 12 anos durante uma migração de servidores em 2019
    • Google+ foi encerrado em abril de 2019
    • Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost e outros também entram na lista de serviços encerrados
  • Mesmo que um silo não seja fechado, o conteúdo da web pode desaparecer
  • O princípio de resposta não é deixar de usar redes sociais, mas manter a cópia canônica do conteúdo em um domínio que você controla

Os 11 princípios da comunidade

  • Os 11 princípios não são uma lista de prioridades, nem uma obrigação de cumprir todos
    1. Possuir seus dados: manter conteúdo, metadados e identidade em seu próprio domínio e preservar o acesso no longo prazo
    2. Usar e publicar dados visíveis: priorizar pessoas e considerar máquinas em seguida; se for possível colocar os dados no HTML, não criar uma API separada
    3. Criar o que você precisa: construir ferramentas para você mesmo, uma pessoa real, não para usuários hipotéticos cuja existência é incerta
    4. Usar você mesmo: usar diariamente o que criou e verificar se vale a pena depender daquilo
    5. Documentar: registrar processos, ideias e código no próprio site para ajudar outras pessoas e seu eu do futuro
    6. Abrir o código: não é obrigatório, mas ajuda outras pessoas a participar da web independente mais rapidamente
    7. UX acima de protocolos: definir primeiro a experiência do usuário e usar apenas os protocolos mais simples e pequenos que a sustentem
    8. Modularidade: criar componentes pequenos e fracamente acoplados para evitar dependência de dispositivos, linguagens ou plataformas específicas
    9. Longevidade: construir tecnologias web que não obriguem a descartar o trabalho existente a cada poucos anos em nome do progresso
    10. Pluralidade: incentivar deliberadamente várias abordagens para formar uma comunidade mais resiliente do que uma monocultura técnica
    11. Diversão: manter expressões pessoais estranhas e interessantes, como na web dos anos 1990

Estrutura técnica que começa no domínio pessoal

  • Usar um domínio próprio como identidade principal online é o pré-requisito de toda a configuração
    • Mesmo que você troque de hospedagem ou CMS, manter o domínio permite preservar links, leitores e ranking de busca
    • Também é a condição mínima que a comunidade reconhece como participação na IndieWeb
  • Em vez de uma plataforma única, a IndieWeb usa pequenas especificações que podem ser combinadas entre si, e o índice oficial de especificações é organizado por histórico de implementação e alcance de adoção

microformats2: usar HTML como API

  • microformats2 torna o conteúdo legível por máquinas adicionando classes CSS ao HTML existente, sem arquivos ou APIs separados
    • h-*: objeto raiz
    • p-*: texto simples
    • u-*: URL
    • dt-*: data
    • e-*: HTML incorporado
  • h-card representa a identidade pessoal, como nome, URL e foto, permitindo que aplicações exibam o perfil ao lado de posts e reconheçam o usuário
    • Diferentemente do Gravatar baseado em e-mail, funciona com base no domínio
  • h-entry é o componente central do conteúdo IndieWeb, marcando título, autor, data de publicação, corpo etc. de um post
  • h-feed agrupa vários h-entry e transforma a própria página de lista em HTML em um feed assinável
  • Usando microformats para leitura e Micropub para escrita, forma-se uma estrutura em que “o site é a própria API”

rel="me" e verificação de identidade distribuída

  • rel="me" declara que o destino do link representa a mesma pessoa da página atual
  • Quando um site e perfis externos se conectam mutuamente com rel="me", torna-se possível a verificação mútua de identidade sem uma autoridade central
    • Mastodon usa essa estrutura para oferecer um indicador verde de verificação em um domínio
    • Threads, PixelFed, GitHub, Keybase e Wikipedia também dão suporte
  • RelMeAuth delega a prova de identidade a um provedor OAuth, como GitHub, vinculado a partir da página inicial, permitindo autenticar em serviços com uma URL pessoal

Webmention: conversas entre sites

  • Webmention é uma W3C Recommendation desde 12 de janeiro de 2017 e sucede o Pingback, transmitindo comentários, curtidas, respostas e republicações entre sites sem depender de plataformas
  • O procedimento de envio é o seguinte
    1. O post de origem inclui um link para o post de destino
    2. O servidor de origem encontra o endpoint receptor no cabeçalho HTTP Link do post de destino ou em <link rel="webmention"> no HTML
    3. Envia uma requisição POST contendo apenas source, o post de origem, e target, o post de destino
    4. O servidor receptor baixa source e verifica se ele realmente contém um link para target
    5. Analisa o h-entry de source para distinguir resposta, curtida e republicação, e usa h-card para exibir o nome e a foto do autor
  • Cada site se torna um nó e os links entre sites formam um grafo social, mas problemas de spam e moderação permanecem
    • Vouch move o custo de filtragem para o remetente ao transmitir, como terceiro parâmetro, um site de garantia que o receptor já conhece e que tenha linkado para o domínio remetente
    • Salmention propaga threads de conversa fazendo com que o post original envie Webmentions atualizados aos participantes quando um comentário recebe uma resposta
  • Sites estáticos sem backend podem usar webmention.io para receber Webmentions em seu nome e oferecer uma API de consulta
    • Pode ser usado com geradores de sites estáticos como Hugo, Jekyll e Eleventy

Login e publicação baseados em domínio

  • IndieAuth usa uma URL pessoal como identidade de login, em vez de uma conta Google ou Facebook
    • Baseia-se em OAuth 2.0 e identifica usuários e aplicações por URLs
    • O DNS substitui o registro prévio de clientes, e PKCE é obrigatório para impedir o roubo de tokens de acesso
    • O serviço encontra o servidor de autenticação em rel="indieauth-metadata" na página do usuário e, após a autenticação, verifica o controle sobre aquela URL
    • Senhas, e-mail, RelMeAuth etc. podem ser usados como métodos de autenticação
  • Micropub é uma W3C Recommendation desde maio de 2017 e separa o software do site da interface de publicação
    • Clientes web, iOS e Android podem criar, editar e excluir posts em um domínio pessoal
    • Em vez de MetaWeblog e AtomPub, que compartilhavam senhas, usa tokens OAuth obtidos por IndieAuth
    • Sem criar um vocabulário separado, serializa e transmite propriedades de h-entry, como h=entry e content

Feeds em tempo real e leitores desacoplados

  • WebSub era chamado anteriormente de PubSubHubbub e é uma W3C Recommendation desde janeiro de 2018
    • Em vez de assinantes consultarem o servidor periodicamente, o publicador informa novos posts a um hub, e o hub os entrega imediatamente aos assinantes via webhook
    • Reduz carga no servidor, elimina atraso de atualização e é suportado por Feedly, NewsBlur e outros
  • Microsub é a especificação mais nova e ainda está em rascunho, separando aplicações sociais de leitura em duas camadas
    • O servidor cuida de gerenciamento de assinaturas, coleta e análise de feeds e normalização de dados
    • O cliente exibe apenas a interface de leitura, podendo competir em UX, e as informações de assinatura podem ser movidas entre clientes
    • Ao combinar publicação de respostas via Micropub e notificações via Webmention, completa-se a estrutura de um leitor social IndieWeb

POSSE, PESOS e Backfeed

  • POSSE é a estratégia recomendada de publicar primeiro em seu próprio site e distribuir externamente
    • A cópia externa inclui o link original, então leitores continuam lendo na plataforma existente, enquanto o publicador mantém a cópia canônica
    • Mesmo que a plataforma seja encerrada ou a conta seja bloqueada, o original permanece
    • Tantek Çelik cunhou o termo em 2012, e Cory Doctorow, Molly White e outros o utilizam
    • O efeito de fazer sites de spam copiarem o post junto com o link original é chamado de “aikido da internet”
  • PESOS é o caminho inverso: publicar primeiro em um silo e depois copiar para o próprio site para arquivamento
    • Permite usar aplicativos de silo bem acabados e publicar mesmo que o site pessoal esteja fora do ar
    • Mas o conteúdo já fica sujeito aos termos do silo desde o início, a cópia no site pessoal não é a canônica e restrições como limite de caracteres ou links t.co também são herdadas
  • Backfeed devolve ao original, via Webmention, curtidas, respostas e republicações feitas nas cópias externas
    • Bridgy observa cópias no Mastodon, GitHub, Flickr, Reddit e Bluesky e envia uma Webmention para cada interação
    • Como resultado, toda a conversa ocorrida em plataformas externas pode ser armazenada no domínio pessoal

Relação com Fediverse e RSS

  • Webmention, Micropub, WebSub e ActivityPub vieram todos do W3C Social Web Working Group, mas seguem filosofias diferentes
  • O Fediverse federa servidores e representa identidades como @user@instance, portanto, se você não opera sua própria instância, depende de outro operador
    • Operar uma instância envolve a admintax, o alto custo de moderação e manutenção
  • A IndieWeb federa sites e usa domínios pessoais como identidade; a federação é tratada como apenas um entre vários canais de distribuição
  • Bridgy Fed converte h-card, h-entry e Webmention de e para ActivityPub e o AT Protocol do Bluesky
    • O domínio pessoal se torna uma conta Fediverse no formato @example.com@example.com
    • É possível buscar e seguir essa conta no Mastodon, e respostas retornam ao post original via Backfeed
  • A IndieWeb considera que RSS e Atom exigem manter uma cópia XML separada do HTML, criando custo de manutenção e possibilidade de inconsistências
    • Alguns arquivos Atom são até 4,5 vezes maiores que o HTML com o mesmo conteúdo
    • A experiência quando uma pessoa abre diretamente um link de feed também não é boa
  • A alternativa h-feed usa o próprio HTML como feed, mas pouquíssimos leitores dão suporte
    • Portanto, em um ambiente IndieWeb, recomenda-se oferecer h-feed e, para leitores em geral, também RSS ou Atom

Ordem para começar

  • Getting Started recomenda a seguinte ordem
    1. Garantir um domínio: usar como identidade principal online e escolher privacidade WHOIS apenas quando confiar totalmente no provedor
    2. Configurar hospedagem: iniciantes usam serviços gerenciados como GitHub Pages, Netlify ou Neocities; quem tem experiência pode hospedar por conta própria
    3. Criar páginas: pode-se usar gerador de site estático, HTML escrito diretamente ou CMS; não há tecnologia oficial
    4. Aplicar POSSE: distribuir para outras plataformas junto com o link original
    5. Adicionar microformats: colocar rel="me" na página inicial e h-entry nos posts
    6. Validar: verificar rel-me, h-card e h-entry passo a passo com IndieWebify.me
    7. Participar da comunidade: compartilhar o que foi criado, mesmo que seja só uma página, e documentar no wiki para os próximos usuários
  • IndieMark é uma escala de orientação por etapas para desenvolvedores que querem adotar gradualmente

Aplicação real e recursos excluídos

  • No site real, os seguintes elementos foram aplicados
    • Envio e recebimento de Webmention: automatizar a tarefa diária de notificar links externos em novos posts, deixando uma margem de 24 horas para corrigir erros de digitação
    • Webmentions recebidos são usados na lista de referências ao final de cada post e separados dos comentários gerenciados por e-mail
    • h-entry em todos os posts, h-card na página inicial, validados com mf2py
    • No rodapé, Mastodon, GitHub e Org Social foram vinculados com rel="me" para receber indicadores de verificação
  • Elementos que não combinavam com as necessidades e o fluxo de trabalho existente foram excluídos
    • Micropub e IndieAuth: como o editor e o Git são a interface de publicação e os posts são escritos em Markdown versionado, não há necessidade de um endpoint de publicação separado
    • WebSub: como a publicação é atrasada deliberadamente em 24 horas, a entrega em tempo real não justifica a complexidade
    • h-feed: o template de cards de posts é reutilizado também em áreas de recomendação dentro do corpo, o que pode levar parsers a reconhecê-los como h-entry ambíguos; RSS cumpre esse papel suficientemente bem

Princípios práticos que duram mais que a tecnologia

  • HTML comum é o formato mais duradouro, permitindo ler todo o conteúdo mesmo sem JavaScript
  • É preciso projetar URLs que possam ser mantidas permanentemente, seguindo o princípio “Cool URIs don't change”
    • No site real, mesmo que o slug de um post seja alterado, a URL antiga continua funcionando
  • Não é necessário abandonar os silos de uma vez; é possível fazer uma transição gradual publicando primeiro no próprio site, por tipo de conteúdo
  • Também é preciso considerar a longevidade em casos extremos
    • Pode-se avaliar um “dead man's switch” que entregue as chaves do site a uma pessoa de confiança após a morte
    • Também é necessário resolver quem pagará pelo domínio depois que o operador desaparecer
  • Operar com prazer um site pessoal imperfeito e único está mais alinhado aos princípios da IndieWeb do que manter um template perfeito, mas entediante de cuidar

Leituras relacionadas

1 comentários

 
GN⁺ 18 시간 전
Comentários no Hacker News

  • Se a IndieWeb quer conteúdo, enterrá-lo sob uma pilha tecnológica complexa é exatamente o oposto do que deveria fazer
    Esse conjunto de protocolos é, na prática, inutilizável para 90% dos usuários; para priorizar a experiência de quem cria conteúdo, é preciso uma solução de um clique que permita começar imediatamente
    No momento em que se exige linha de comando, Docker ou edição manual de HTML/CSS, cria-se uma barreira que a maioria não consegue superar; do jeito que está, parece mais NerdNet do que IndieWeb

    • Ao olhar a comunidade e a wiki da IndieWeb, há muita gente que concorda com uma abordagem de experiência do usuário em primeiro lugar
      O micro.blog, uma das principais portas de entrada de um clique, oferece sites pessoais com recursos modernos da IndieWeb por US$ 5 ao mês
      Como a maior parte do público interessado hoje é formada por desenvolvedores que querem construir por conta própria, os textos relacionados parecem cheios de tecnologia, mas a comunidade também deseja a entrada de não desenvolvedores. David Shanske vem criando, há 10 anos, plugins para WordPress que oferecem ferramentas IndieWeb por padrão: https://profiles.wordpress.org/dshanske/#content-plugins
      Também não é preciso usar todas as tecnologias para ser IndieWeb. Dá para começar com um domínio próprio, criar páginas com HTML, Markdown, Django etc. e depois adicionar microformatos e Webmention aos poucos; em qualquer etapa, o site pode ser considerado um site IndieWeb
    • Na verdade, abrir para todo mundo é o que estraga coisas boas. Como no Setembro Eterno, a internet acaba cheia de mídia de baixa qualidade e caça-cliques, então barreiras de entrada e limites de participação são benéficos
      A internet era melhor antes de virar um Walmart global, quando era um espaço em que pessoas interessantes se reuniam por conta própria
    • Como alguém que acabou de conhecer isso, é difícil culpar a IndieWeb. Quem tenta escapar dos jardins murados das plataformas sociais costuma ser engenheiro ou gente familiarizada com a web, e é natural resolverem o problema com as ferramentas que conhecem
      A internet também sempre evoluiu partindo de coisas difíceis, mas divertidas, feitas por geeks, que aos poucos se tornam mais fáceis para o público geral. A IndieWeb ainda está no começo; se sobreviver, a popularização virá naturalmente, então por enquanto é melhor deixá-los construir mais
    • Em 2014, comecei a startup Known como parte do movimento IndieWeb para implementar esse objetivo, e o código open source ainda existe
      O problema é a viabilidade econômica. Soluções de um clique são boas, mas a IndieWeb resolve uma questão ideológica, não um problema urgente do usuário, o que dificulta conseguir investimento ou clientes que sustentem os custos de operação do serviço
      O micro.blog é o que chega mais perto, mas é um serviço centralizado que não pode ser rodado em infraestrutura própria; embora seja compatível com os protocolos, não é uma ferramenta IndieWeb completa
      Há possibilidades, como registros de atividades de agentes ou ferramentas de publicação para sensores e servidores, mas sem demanda real dos usuários parece difícil isso virar um serviço acabado
    • Eles sabem que é difícil para 90% dos usuários, mas não se importam. Assim como o software livre, a IndieWeb também é uma filosofia de resolver diretamente as próprias necessidades, sem remuneração, e não tem como objetivo dominar o mercado
      Em vez de ceder ao que é popular, deveríamos incentivar as pessoas a criarem o que desejam. Profissionais de marketing que se concentram em estratégias de rent seeking e lobby, em vez de criar valor real, tornam a sociedade pior e precisam diminuir em número

  • A forma de pensar do Nostr parece mais próxima do POSSE do que Mastodon ou AT Protocol, por isso eu o prefiro

  • Eu mantenho um blog regularmente, tenho meu domínio e sou dono dos meus posts, mas se não for IndieWeb só porque uso WordPress, então no fim ainda dependemos de empresas. Blogs antigos feitos no Blogger continuam praticamente intactos há quase 10 anos
    Possuir o próprio servidor não é realista. Se for um servidor virtual, ele estará na nuvem da Amazon ou da Microsoft; se for físico, terá de ficar no datacenter de alguma empresa, e é difícil gerenciar por conta própria UPS e conexão permanente à internet

  • As alternativas existentes geralmente se limitavam a perseguir a nostalgia dos anos 1990, e era difícil ver utilidade além de um breve saudosismo, mas este caminho parece diferente
    Ele abraça a web moderna ao mesmo tempo que permite ao criador controlar completamente seu próprio espaço. Quando eu tiver tempo, quero fazer o blog myzopotamia.dev participar da IndieWeb

  • O indiekit basicamente oferece todo o conjunto de recursos IndieWeb por padrão. Estou usando em https://rmendes.net e trabalhando para implementá-lo também em https://textcaster.app

  • O problema do princípio de não repetição (DRY) em feeds RSS parece exagerado. Não me lembro de ter tido problemas para gerar automaticamente um feed RSS, independentemente do framework open source usado para escrever o site

    • Ainda assim, a duplicação no RSS é evidente. Ele replica a página de listagem do site e, mesmo havendo h-entry, é preciso manter duas versões do mesmo conteúdo e ainda XML, o que frequentemente me frustrou
      O RSS foi inventado logo antes da revolução da marcação semântica, quando os layouts em tabelas estavam chegando ao fim, então não teve sorte no timing
    • Pouca gente parece gostar de criar ou ler feeds RSS. Há muitas alternativas, mas nenhuma superou a popularidade do RSS

  • Fico incomodado ao ver um site que se apresenta como IndieWeb destacando o currículo do autor, uma foto de rosto profissional, uma bio que enfatiza passagens por instituições de prestígio e um blog refinado
    Parece uma loja de roupas iluminada em um shopping de luxo, com símbolos anarquistas em todos os produtos, e quando você olha de perto as etiquetas de preço quase chegam a quatro dígitos

    • Vejo com mais frequência blogs simples sobre o prazer de manter um blog, o que é muito melhor do que a indústria paralela voltada a crescer no Substack
      Um site pessoal pode ser o que a pessoa quiser. O meu também fica mais pessoal e voltado a hobbies a cada ano, agora que não preciso mais procurar emprego, mas um site é, no fim, produto da sociedade em que aquela pessoa vive, e também é preciso ganhar a vida
    • Meu site também não se apresenta como IndieWeb, mas tem link para meu site de consultoria e uma foto de rosto
      A vida profissional também faz parte de quem eu sou; no sentido de ser autônomo, eu poderia até ser chamado de trabalhador independente, e não entendo por que isso seria ruim
    • Colocar o currículo em um domínio pessoal é uma das atitudes mais IndieWeb possíveis. Isso coloca a identidade profissional sob seu próprio controle, não no LinkedIn
      A IndieWeb não rejeita profissionalismo; ela defende que o conteúdo pertence a você e deve sobreviver às plataformas. Foto de rosto, currículo e blog refinado são aceitáveis; o alvo da crítica é prender tudo dentro de plataformas que podem fechar, vender seus dados ou desaparecer

  • Tornar conteúdo legível por máquinas sem arquivos paralelos ou APIs era, desde o início, um problema que quase não precisava ser resolvido
    Como ontologias anteriores, isso é inútil para visitantes humanos e só alimenta dados para agentes hostis

  • Seria bom compartilhar com frequência outros blogs de que você gosta. A IndieWeb depende de boca a boca e curadoria humana, então posts do tipo “coisas que curti este mês” são úteis
    Também é importante elogiar generosamente, enviar agradecimentos por e-mail e iniciar conversas. Sites estáticos sem rastreamento de usuários podem parecer monólogos, então e-mails de leitores dão muita força
    Como em qualquer site pessoal, não há problema em ser imperfeito e excêntrico, e nem todo conteúdo precisa ser um feed cronológico. Dá para organizar o espaço do jeito que quiser, como um jardim digital

  • Fico curioso se você sabia que o domínio .dev é propriedade do Google

    • Eu sabia, e queria obter meu próprio domínio de topo, mas o processo parecia complicado