Operando um site totalmente independente por 15 won por dia

 (neatnik.net)
3 pontos por GN⁺ 22 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Hardcore IndieWeb é uma abordagem em que você mantém o conteúdo original e os HTML/recursos web publicáveis no seu próprio dispositivo, sem entregar a um provedor de serviços sua identidade e o controle do conteúdo
  • Seguindo um processo de publicação ao estilo dos anos 1990 — visualizar o HTML no navegador antes de enviar ao host — é possível manter um site sem CMS, SSG, framework, CLI ou assinatura mensal
  • Basta ter um editor de texto, uma ferramenta de SFTP e uma hospedagem web; no NearlyFreeSpeech.net, dá para operar um site estático por US$ 0,01 por dia e recarregar a partir de US$ 0,25
  • Você pode gerenciar diretamente em arquivos a landing page, posts individuais, arquivo e feed Atom, mudar estrutura e design de cada página e enviar apenas os arquivos alterados
  • Mesmo que o host desapareça, é possível subir o site completo em outro lugar, mas quanto mais ferramentas forem adicionadas, mais dependências surgem; por isso, manter os originais locais e a versão publicada é a condição para preservar a independência

A independência exigida pelo Hardcore IndieWeb

  • O IndieWeb é uma abordagem prática para possuir diretamente sua identidade e conteúdo na web e escapar do controle externo das empresas
  • Serviços de blog por assinatura também podem ajudar na participação no IndieWeb, mas se o conteúdo existir principalmente no banco de dados e nos servidores de outra pessoa, isso não é independência total
    • Mesmo que seja possível exportar em formato aberto, durante o uso do serviço você não tem controle completo sobre o conteúdo
    • É uma abordagem mais adequada para quem quer independência e controle total sobre o conteúdo do que para quem já está satisfeito com um serviço existente
  • O Hardcore IndieWeb aplica aos princípios existentes do IndieWeb critérios concretos de controle e portabilidade
    • Se o conteúdo não estiver principalmente no seu próprio disco, é difícil dizer que você o controla por completo
    • Se você não tiver no disco uma cópia do HTML publicado e dos recursos web, o site não está em um estado totalmente portátil
  • Se o serviço encerrar as atividades e não for mais possível exportar os dados, você pode ter a posse nominal do conteúdo, mas não conseguirá acessá-lo ou migrá-lo
  • Mesmo que queira deixar um serviço por causa da conduta do operador, talvez seja preciso encontrar outro serviço que suporte o formato exportado, ou converter o conteúdo e mudar ferramentas e procedimentos
  • Se você tiver localmente os originais do conteúdo e a versão final publicada, poderá manter controle e portabilidade mesmo nessas situações

O processo de publicação web ao estilo dos anos 1990

  • O Hardcore IndieWeb segue a forma simples de publicação da web dos primórdios
    1. Escrever o conteúdo no disco rígido
    2. Visualizar no navegador web
    3. Quando estiver satisfeito, enviar para a hospedagem e repetir sempre que necessário
  • Além do domínio, o que você precisa é apenas de um editor de texto, uma ferramenta de transferência de arquivos e uma hospedagem web
  • Não são necessários ambiente de programação, IDE, framework, shell, ferramenta de CLI nem assinatura mensal
  • É preciso saber HTML, mas dá para aprender com materiais como HTML for People, e também é possível começar com poucas tags e copiar/colar
  • SaaS complexos, CMS, SSG, linguagens de marcação e sistemas de template são opcionais; o método simples de publicar arquivos diretamente continua funcionando

Ferramentas e hospedagem necessárias

  • Qualquer editor de texto serve, desde que consiga salvar arquivos no disco
  • Para transferência de arquivos, é necessária uma ferramenta com suporte a SSH ou SFTP
    • O FileZilla é uma opção compatível com vários sistemas operacionais
  • Recomenda-se o NearlyFreeSpeech.net como host para site estático, com operação por US$ 0,01 ao dia
    • Adam Newbold usa esse serviço desde 2008
    • É possível adicionar saldo na conta a partir de US$ 0,25 e incluir sites static, non-production
    • Ao selecionar o nome do site na aba Sites, você pode ver as credenciais de login para transferência de arquivos
    • Um subdomínio gratuito é fornecido, e você pode adicionar um domínio próprio na aba Domains
  • O NearlyFreeSpeech não é obrigatório; também é possível escolher outro host que ofereça hospedagem básica de arquivos estáticos

Preparando um site existente e o HTML

  • Se o seu site ou blog atual já estiver em HTML, é fácil começar imediatamente
  • Se ele estiver em outro formato, dependendo do serviço, talvez seja possível exportar ou converter para HTML
    • Para blogs grandes, costuma ser mais adequado usar uma ferramenta de conversão
    • Se o volume for pequeno, você pode rever os posts e criar os arquivos HTML manualmente
  • Você pode preferir Markdown, mas HTML é a linguagem da web, e às vezes é mais simples lidar com HTML puro do que brigar com um parser de Markdown
  • Se for difícil criar um design do zero, você pode baixar e editar designs e templates gratuitos como os do HTML5 UP

Os arquivos que compõem um blog

  • Um blog típico é composto por landing page, posts, página de arquivo e feed, e tudo isso pode ser gerenciado diretamente sem um serviço de blog dedicado

  • Landing page

    • Você pode dispor livremente o post mais recente inteiro ou em parte, vários posts, ou conteúdo que não seja post
    • Para mostrar o post mais recente, copie o conteúdo e adicione um link para a página independente dele
    • Para manter os 5 posts mais recentes, cole o novo no topo e remova o mais antigo da parte de baixo
    • Como não há restrições de CMS, SSG ou engine de template, é possível mudar a estrutura e a apresentação de cada página
    • O nome do arquivo da landing page deve ser index.html e ele deve ficar na raiz web
    • No NearlyFreeSpeech, a raiz web é /home/public

  • Posts do blog

    • Cada post vira uma página web; você pode criá-lo copiando o arquivo de um post anterior, dando um nome único ao arquivo e inserindo novo conteúdo
    • A estrutura de arquivos no disco se reflete na URL, então organize as pastas conforme o esquema de endereços que desejar
    • Para usar o caminho /blog/, crie uma pasta blog na raiz web
    • Você pode usar nomes de arquivo baseados em slug, como the-best-lunch-i-ever-had.html
    • Se colocar um index.html dentro da pasta de cada post, poderá ocultar a extensão .html na URL
    • Ao gerenciar os posts como arquivos HTML independentes, e não como itens de Markdown ou de banco de dados, você pode dar a cada texto um estilo, visual, layout e personalidade diferentes
    • A convenção de que todos os posts precisam ter a mesma aparência vem das ferramentas modernas de publicação; em HTML feito à mão, não há necessidade de segui-la

  • Página de arquivo

    • Crie uma pasta chamada, por exemplo, archive, coloque um index.html dentro dela e monte a lista de posts
    • A forma de ordenar e organizar é livre, e você pode destacar separadamente no topo da página os posts de que mais gosta

Gerenciando diretamente um feed Atom

  • Um feed RSS não é um sistema especial, mas sim um arquivo salvo no disco, então pode ser editado diretamente em um editor de texto
  • Você pode copiar o feed de exemplo da página da Wikipedia sobre Atom ) e começar com um arquivo feed.xml
    • Atom é compatível com RSS e amplamente suportado
    • Troque valores como example.com, <title> e <subtitle> pelo seu domínio e suas informações
    • Crie um <entry> para cada post que quiser incluir no feed e preencha data, hora, título, resumo etc.
    • Em <id>, use um novo UUID obtido no UUID Generator
  • Você pode colar o feed pronto no W3C Feed Validation Service para verificar se ele pode ser interpretado corretamente
    • Se houver erros, o serviço de validação mostra o que precisa ser corrigido

Publicação e atualização

  • Na publicação inicial, conecte-se ao servidor com um programa de transferência de arquivos e copie o site inteiro para a hospedagem web
  • Depois disso, basta enviar apenas os arquivos novos ou alterados
    • Os alvos normais de atualização são a landing page, o novo post, o feed e a página de arquivo
  • O processo de publicação pode ser feito basicamente arrastando arquivos locais para o servidor remoto

Portabilidade e o limite das ferramentas adicionais

  • Como o site completo está no seu computador, mesmo que o host atual desapareça, você pode enviá-lo do mesmo jeito para outro host
  • Não é preciso gerenciar grandes falhas de segurança de um software de blog nem dependências de SSG, e você pode controlar diretamente todos os aspectos do conteúdo
  • Apenas mantendo esse procedimento, já é possível continuar operando um site totalmente independente
  • Você pode adicionar ferramentas e processos para ajudar no fluxo de trabalho, mas cada ferramenta extra também cria uma nova dependência
  • Se os originais do conteúdo estiverem no seu dispositivo e você tiver uma cópia do site inteiro pronto para publicação, isso atende às condições do Hardcore IndieWeb

A autonomia de lidar diretamente com HTML

  • O procedimento central é escrever HTML diretamente e enviá-lo para um servidor web
  • As camadas adicionais de tecnologia, procedimentos e expectativas acumuladas nos últimos 30 anos tornaram o trabalho na web mais complexo e fizeram com que o controle e a independência fossem entregues a outras pessoas
  • Mesmo usando serviços IndieWeb, se você deixar com o operador do serviço a única cópia de toda a sua presença na web, isso não é independência total
  • O Hardcore IndieWeb não é uma abordagem para todos, mas é adequada para quem valoriza quem guarda seus textos e onde, de que forma, eles são publicados
  • Lidar diretamente com HTML e copiar arquivos para o espaço da sua hospedagem web oferece uma experiência direta e autônoma que reconecta você com a diversão da web inicial

Leituras relacionadas

1 comentários

 
GN⁺ 22 시간 전
Comentários do Hacker News

  • Tenho hospedado sites estáticos gratuitamente no GitHub Pages e Cloudflare Pages e estou muito satisfeito. Mesmo pagando o NearlyFreeSpeech, no fim a dependência de hospedagem de terceiros é a mesma, então hospedar por conta própria não parece ter muito valor além da satisfação técnica
    O importante é gerenciar diretamente ativos como HTML e imagens como arquivos simples no disco. Graças à integração com Git, ainda há backup externo, e ao fazer push para master no VS Code, tudo é publicado em menos de 30 segundos, o que é muito mais prático do que o antigo FTP/SFTP

    • GitHub Pages e Cloudflare Pages têm a vantagem de que o site provavelmente sobreviverá mais tempo que o operador. Se você hospeda por conta própria, sem um plano de sucessão, um dia inevitavelmente tudo para por expiração do domínio ou cancelamento do cartão; já nos serviços gratuitos, isso continua sendo apenas uma possibilidade de que eles desapareçam
    • A diferença de que, ao pagar, você vira cliente em vez de produto é bem grande
    • Meu blog também funciona assim: https://gigatexal.blog

  • NearlyFreeSpeech também é um bom serviço, mas não é totalmente independente. Sem infraestrutura própria de internet, para chegar o mais perto possível da independência dá para operar um site de casa com port forwarding ou como serviço oculto do Tor
    Definir a porta no torrc não é difícil, mas os visitantes também precisam do Tor Browser, e é complicado explicar que o site está na “dark web”. É possível rodar isso em casa com hardware próprio e ainda esconder o IP do servidor, então é surpreendente que isso não seja mais usado no universo da web independente. Também dá para redirecionar um domínio normal para um endereço .onion
    O Beaker Browser, que permitia criar e hospedar sites diretamente no navegador, foi encerrado, mas ferramentas como um plugin de criação de sites para Tor poderiam ajudar na adoção

    • Serviços .onion podem ser colocados no ar com facilidade, são mais seguros que a web comum e até podem rodar em celular
      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
    • O Tor Browser oferece suporte a Onion-Location e Alt-Svc para descobrir endereços .onion a partir da internet comum. Onion-Location permite que um site HTTPS comum anuncie um serviço Onion, e Alt-Svc faz a descoberta e troca automaticamente, sem ação separada do usuário
      No futuro também pode haver conexão Onion baseada em DNS ou DNSSEC: https://onionservices.torproject.org/research/proposals/usab...
    • O ótimo é inimigo do bom. Num mundo em que ainda dependemos de operadoras e fabricantes de hardware, NearlyFreeSpeech é um meio-termo de baixo risco, sem histórico de abusar da confiança dos usuários, e o custo é praticamente insignificante
    • Tor não é um navegador, e sim um serviço. O Tor Browser é só um pacote de conveniência que junta um navegador focado em privacidade com o serviço Tor, então dá para operar um site Tor num servidor headless sem navegador algum
    • O motivo de serviços ocultos serem raros é que exigem esforço demais dos visitantes. Há uma grande diferença de acessibilidade entre passar myfirstnamelastname.com e ter que enviar um endereço .onion aleatório de 56 caracteres, além de instalar o Tor Browser no celular da pessoa

  • O maior obstáculo nesse contexto é o nome de domínio necessário para possuir o conteúdo, que, mesmo barato, custa cerca de 6 dólares por ano. Sites estáticos podem ser hospedados gratuitamente em inúmeros lugares, e para pessoas físicas o plano gratuito de CDN já basta
    Mais importante do que auto-hospedar o servidor é possuir o identificador único que é o domínio; para onde esse domínio aponta é bem menos importante

    • A engenharia de software sempre foi impulsionada por pessoas inteligentes que fazem coisas não por necessidade, mas por curiosidade. Ao contratar, sempre valorizei mais curiosidade e iniciativa do que diploma
    • 6 dólares por ano dá cerca de 0,016 dólar por dia; é mais caro, mas ainda assim barato
    • Na verdade não sei em que parte do texto foi dito que deveríamos hospedar o próprio servidor

  • É engraçado que enviar seus próprios arquivos para um servidor web seja tratado como se fosse um conceito novo

    • Vivemos numa época em que muita gente nem sabe o que é um arquivo, então é importante manter esse espírito vivo
    • É triste que toda a internet tenha virado um monstro hospedado e controlado por algumas poucas empresas gigantes, a ponto de precisar até de um novo conceito chamado IndieWeb. Hospedar arquivos não deveria ser privilégio; desde o início, deveria estar mais próximo de um direito humano
      A tecnologia para hospedar por conta própria ainda existe, mas a mentalidade mudou para algo exclusivo da nuvem
    • Antigamente, bastava colocar arquivos na pasta public_html e você já tinha imediatamente um site pessoal. Isso não quer dizer que fosse preciso continuar escrevendo HTML na mão, mas naquela época era uma forma rápida e natural de participar da web
      Contas Unix também ofereciam chat entre pessoas, permitindo verificar se um amigo estava online com finger e conversar via talk ou ytalk; mesmo com o amigo sentado no terminal ao lado, aquilo parecia mágica
    • Mal posso esperar até que as crianças conheçam hardware

  • Se pagar US$ 0,01 por dia ao NearlyFreeSpeech é uma forma de operação 100% independente, então isso não parece muito diferente da hospedagem estática da Vercel, Netlify, GitHub ou Cloudflare.
    O texto não diz o que fazer quando você precisa de banco de dados, formulário de feedback, prévia para redes sociais ou otimização para mecanismos de busca; talvez essa ausência seja justamente uma condição da “web independente”.

    • No NearlyFreeSpeech, é possível usar PHP e banco de dados
    • Se não há grande diferença entre NFS e Vercel, então os usuários deveriam estar divididos meio a meio, mas fico curioso para saber por que a maioria escolhe a Vercel
    • O NFS oferece um ambiente Linux completo com várias linguagens de programação instaladas, então também suporta sites dinâmicos, mas custa mais
    • Houve até quem recebesse uma conta de US$ 100 mil da Netlify no plano gratuito

  • Eu precisava de um domínio para um site de evento, e a Infomaniak também oferecia 10 MB de armazenamento junto com o domínio. Por cerca de 5 euros por ano, dá para ter domínio e site, o que não é nada mal

  • Criei um plugin JavaScript de comentários que guarda todos os dados dentro de um repositório Git https://github.com/est/req4cmt. Dá para usar com qualquer serviço Git que suporte HTTP, roda em um Cloudflare Worker gratuito, e backup e migração se resolvem com git clone e push.
    Também existe um projeto de substituto do Twitter baseado em Git: https://github.com/est/gitweets
    A demo está em https://f.est.im/ e também suporta comentários usando Git notes. Tudo isso é totalmente gratuito graças ao Cloudflare Workers e ao GitHub Pages

  • O sdf.org é útil para desenvolvedores que querem aprender Unix de forma prática. Pelo que lembro, ele oferecia contas de shell gratuitas em NetBSD Unix, e com uma pequena doação única era possível usar espaço web e recursos extras.
    Como o nome de login vira o subdomínio do seu espaço web, é bom escolhê-lo com cuidado

  • Fico feliz que um site fazendo esse tipo de argumento não esteja hospedado no Cloudflare ou no GitHub Pages

    • O GitHub Pages é uma hospedagem gratuita que oferece domínio e SSL, não cobra nada e parece ter boas perspectivas de longo prazo. Se você não quiser se preocupar com um site estático, grandes empresas como GitHub e Cloudflare parecem ser a melhor opção
    • Costumo recomendar bastante o GitHub Pages, mas também escrevi sobre como hospedar com um Raspberry Pi no quarto: https://joeldare.com/private-analytics-and-my-raspberry-pi-4...
    • Sou grato ao Cloudflare por continuar mantendo sites piratas no ar
    • O mesmo vale para a Vercel e a Netlify

  • Prefiro aprender e dominar o processo em vez de depender de uma ferramenta específica. Basta aprender a gerar HTML a partir de formatos fáceis de ler e escrever, como Markdown, usando ferramentas como Pandoc; aprender a enviar ou sincronizar HTML, CSS e JavaScript para um serviço de hospedagem; e aprender a ter um domínio próprio e apontar o DNS para GitHub Pages ou Cloudflare Pages.
    Como você não fica preso a uma ferramenta, serviço, plataforma ou empresa específica, pode mover seus arquivos de conteúdo para outro lugar a qualquer momento. O processo de converter o Markdown original em HTML pode ser automatizado com um gerador de site estático.
    Saber HTML é útil e divertido, mas não precisa ser condição obrigatória para “operar um site de forma 100% independente”. Você pode rodar tudo por US$ 0 por mês com GitHub e Cloudflare e, se o serviço acabar ou virar pago, simplesmente migrar para outro lugar

    • A ideia central do texto é que, se você mantiver os posts como arquivos HTML individuais, e não como Markdown ou itens de banco de dados, poderá dar a cada página um estilo, aparência, layout e personalidade próprios. Em vez de ficar preso ao molde padronizado de blog criado pelas ferramentas modernas de publicação, você pode tornar cada post diferente
    • HTML é um formato bom para humanos lerem e escreverem. Antes mesmo de existirem ferramentas adequadas, até pessoas que não eram da computação lidavam diretamente com HTML, JavaScript e CSS em editores de texto, e para sites simples isso não é difícil.
      Se você quer domínio total sobre o processo e independência completa, precisa entender e lidar diretamente com as linguagens da web. Geradores de sites estáticos como Nikola são convenientes, mas se você não consegue entender a saída ou modificá-la por conta própria, ainda continua dependente de uma ferramenta de terceiros