blog.canoi.dev.br
Um servidor em Go para integrar a IndieWeb
Vou colocar algumas especificações aqui que podem vir a ser uteis para alguém, mas também irá me servir como material de consulta, e quem sabe um possível devlog a medida que o projeto for evoluindo.
A princípio a ideia é extremamente simples, fazer um servidor que consiga consumir e enviar informações a outros servidores através dos protocolos e padrões da IndieWeb (micropub, webmention, jf2, indieauth, microformats, ...). Para uso estritamente pessoal até então.
Deixando claro que eu não sou nenhum especialista em desenvolvimento web. Seguindo tutoriais e olhando algumas documentações eu consigo facilmente configurar servidores e rodar serviços, mas tenho pouquíssimo conhecimento internalizado. Meu lance é mais desenvolvimento de jogos mesmo.
# Estrutura base
O site terá um único **Owner** , essa é a parte mais fácil, posso fazer de várias maneiras, como um arquivo .json fixo, uma entrada em um banco de dados, por aí vai. Mas relativo às informações do Owner, eu preciso basicamente de:
* Nome
* Website
* Avatar
Porém como pretendo mais para frente suportar também o ActivityPub, a ideia é ter outros campos como:
* Summary
* Banner
* Links
E por aí vai.
Esses dados serão utilizados para assinar os posts e notas do site.
`Published by <b><a class="p-author h-card" href="${WEBSITE}">${NAME}</a></b>`
## Informações em bancos de dados, site construído dinamicamente
A ideia é que todo o site seja gerado estaticamente, com isso consigo reduzir a carga do servidor, ele só precisa ficar responsável por atender às requisições da IndieWeb; serão somente nesses momentos que caso haja necessidade, eu preciso atualizar o site. Exemplos:
* Mostrar no rodapé do meu post todas as menções e respostas que outras pessoas fizeram ao mesmo
* Mostrar seguidores, amigos, etc..
* Mostrar curtidas em postagens
Todos esses são cenários onde ao receber alguma dessas interações, o site estático precisar ser atualizado. Isso pode ser um verdadeiro problema em caso de interações massivas, porém como não é o cenário que busco aqui, funciona bem. Fora que minha ideia é gerar o site inteiro uma vez, e as atualizações possam funcionar em cima de modificar somente os arquivos necessários.
Porém acredito que essas interações acima são opcionais, acho que o único estritamente necessário será geração de posts dinamicamente ao receber alguma requisição do `/micropub`. Onde pode envolver **criação** , **atualização** ou **remoção** de postagens, e em todos esses casos eu preciso atualizar efetivamente a postagem e as páginas das tags.
## Recebendo e guardando postagens
Como citei anteriormente, a ideia é receber posts via micropub e os registrar, para isso preciso começar identificando quais dados devo receber e quais armazenar.
Para começar, eu devo identificar o tipo da entrada:
* `h=entry`
* `h=card`
* `h=event`
* `h=cite`
O _entry_ é o tipo mais comum, basicamente todas as postagens (que podem ser notas ou artigos) serão desse tipo. O _card_ serve principalmente para indicar o perfil de um usuário. E os outros eu também não vi muita coisa até agora.
O entry tem diversas informações padrão, porém nem todas são obrigatórias:
- name
- summary
- content
- published
- updated
- category
- location
- A plaintext string describing the location
- As a Geo URI [[RFC5870](https://micropub.spec.indieweb.org/#bib-rfc5870 "A Uniform Resource Identifier for Geographic Locations ('geo' URI)")], for example: `geo:45.51533714,-122.646538633`
- As a URL that contains an [[h-card](https://micropub.spec.indieweb.org/#bib-h-card "h-card")]
- As a nested [[h-adr](https://micropub.spec.indieweb.org/#bib-h-adr "h-adr")] object
- in-reply-to
- like-of
- repost-of
- syndication - Pass one or more URLs pointing to places where this entry already exists. Can be used for importing existing content to a site.
- mp-syndicate-to = https://myfavoritesocialnetwork.example/aaronpk, https://archive.org/, etc.
- This property is giving a command to the Micropub endpoint, rather than just creating data, so it uses the mp- prefix.
Retirado de [1]
Então a princípio, minhas postagens tem os seguintes dados:
* Primary key
* Slug (formatar-o-titulo-dessa-forma) ou ID
* Title
* Summary
* Content
* CreatedAt
* ModifiedAt
CREATE TABLE IF NOT EXISTS posts (
id INTEGER PRIMARY KEY AUTOINCREMENT,
slug TEXT NOT NULL UNIQUE,
title TEXT,
summary TEXT,
content TEXT NOT NULL,
createdAt INTEGER NOT NULL,
modifiedAt INTEGER
);
Porém talvez precise adicionar outros campos posteriormente, como relativos a replies e likes...
As categorias também são enviadas junto, através da chave _category_ , que na requisição pode ser um array `category[]=ideia&category[]=tecnologia&...`. E para isso eu crio uma tabela separada somente para armazenar as tags:
CREATE TABLE IF NOT EXISTS tags (
id INTEGER PRIMARY KEY AUTOINCREMENT,
post_slug TEXT NOT NULL,
tag TEXT NOT NULL,
FOREIGN KEY post_slug REFERENCES posts(slug),
UNIQUE(post_slug, tag)
);
## Conhecendo e interagindo com pessoas
Esse é uma ideia que ainda estou construindo, mas a ideia base é manter guardado em um banco de dados uma relação de todas as pessoas que as quais aquele servidor já interagiu, e utilizar isso para criar certas relações de confiança e possivelmente uso de chaves públicas e privadas para criptografia; todos recursos que redes do ActivityPub já suportam.
Porém como falei, a ideia a princípio é ser simples, então em sua máxima simplicidade, a única coisa que eu precisaria guardar de um usuário é uma "identidade" ou referência para o mesmo. Aqui a URL do site pode ser facilmente utilizada para isso, já que serão sempre endereços únicos. E esses endereços, umas vez que possuam HTMLs devidamente formatados com microformatos, seja possível retornar os metadados e recriar seu perfil. Ou, posso simplesmente cachear algumas das informações, o que eu acho particularmente mais fácil.
A ideia é que seja possível tanto "conhecer" pessoas adicionando as URLs manualmente, quanto a partir de certas interações como menções, likes e coisas assim. Daí posso implementar em cima disso parâmetros de confiança.
CREATE TABLE IF NOT EXISTS persons (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
website TEXT NOT NULL UNIQUE,
avatar TEXT
);
E aí posso tanto adicionar essas propriedades direto no objeto.
friend BOOL NOT NULL,
following BOOL NOT NULL,
follower BOOL NOT NULL
Quanto criar tabelas separadas para as relações:
CREATE TABLE IF NOT EXISTS friends (
id INTEGER PRIMARY KEY AUTOINCREMENT,
person_id INTEGER NOT NULL UNIQUE,
FOREIGN KEY person_id REFERENCES persons(id)
);
CREATE TABLE IF NOT EXISTS followers (
id INTEGER PRIMARY KEY AUTOINCREMENT,
person_id INTEGER NOT NULL UNIQUE,
FOREIGN KEY person_id REFERENCES persons(id)
);
CREATE TABLE IF NOT EXISTS following (
id INTEGER PRIMARY KEY AUTOINCREMENT,
person_id INTEGER NOT NULL UNIQUE,
FOREIGN KEY person_id REFERENCES persons(id)
);
Porém não faço ideia da melhor resolução.
Além disso, também estou pensando sobre lidar com atualizações em registros dos sites (em casos de migração ou desativação). Em caso de migrações, preciso de alguma forma de atualizar o perfil antigo para a nova referência, uma ideia que me veio é que talvez seja possível fazer uma checagem através dos dados públicos do domínio. Nesse caso talvez eu precise armazenar mais algumas informações, para fazer essa comparação depois, como um e-mail, ou um telefone (não sei quais dados consigo resgatar...).
A outra ideia são as chaves públicas e privadas, e aí cada usuário deve cuidar para não perder a sua. Porém isso traz uma complexidade a mais, pois a partir daqui talvez deixe de ser algo para interagir puramente com a IndieWeb, e começa a se tornar algo próximo a um protocolo ou padrão próprio. O ActivityPub faz isso, por exemplo, há essa necessidade de chaves públicas e privadas exatamente para mediar as interações entre os usuários. É algo que pretendo implementar, mas não agora.
Os sites da IndieWeb podem ser simplesmente estáticos, ou seja, a pessoa não precisa rodar um servidor nem mesmo um banco de dados para poder integrar esse "espaço". A única coisa que é necessário é popular o HTML com os microformatos e links para os endpoints corretos. Com isso talvez você não consiga utilizar o `/micropub` para escrever postagens dinamicamente no site; mas pode subir artigos estaticamente, e digamos que seja um texto em reposta a um outro artigo, de um site de outra pessoa, você pode enviar (e até receber) a menção via webmention através de alguma ferramenta de terceiros, como o webmention.io, por exemplo.
Ou posso ir pelo caminho mais fácil, cabe ao usuário a garantia de manter o registro, e em caso de migração, um novo registro de usuário é criado, e somente serão registradas as novas interações. Os registros perdidos se mantém perdidos, a menos que o dono do servidor decida arbitrariamente manter esses dados em cache.
O que me leva a pensar em outra questão enquanto escrevo, um usuário também pode ter mais de um domínio e serviço rodando, então de fato preciso de maneiras então ainda preciso aprender a diferenciar esses casos de casos de migração sem notificação ou redirecionamento do endereço antigo para o novo. Consigo pensar em uma solução que envolve o IndieAuth, mas daí fica a cargo do usuário que migrou ir atualizar seu registro.
Me parece que o mais fácil por agora é só ignorar isso mesmo.
Mas é isso, o conceito de pessoa é importante dentro desse sistema, pois pretendo as relacionar com outros objetos, como respostas a postagens, citações; além das que já citei de "seguindo e seguidores", amigos, e por aí vai.
CREATE TABLE IF NOT EXISTS replies (
id INTEGER PRIMARY KEY AUTOINCREMENT,
post_slug TEXT NOT NULL,
person_id INTEGER,
person_post_url TEXT NOT NULL,
reply_by_me BOOL NOT NULL,
FOREIGN KEY person_id REFERENCES persons(id),
FOREIGN KEY post_slug REFERENCES posts(slug),
UNIQUE(post_slug, source)
);
# Ideias para o futuro
A princípio eu quero explorar o que eu consigo construir em cima dessa ideia de operar em cima de um protocolo aberto, como o IndieWeb e o ActivityPub. Mas a ideia também é a de integrar futuramente ferramentas comunitárias, no sentido de possibilitar meios de comunicação públicos, abertos e de fácil acesso.
Acho que a ideia mais ousada que tenho em mente é conseguir tornar o próprio celular em um endpoint, para isso eu preciso de alguma maneira de torná-lo um mini-servidor móvel.
> Jogando aqui uma ideia que me surgiu em mente, mas talvez exista alguma maneira de aliar isso a uma conexão mais direta, como rápidas requisições via bluetooth, ou algum "tunelamento" (sei nem direito o que é isso) entre dispositivos
No ideal o uso seria para promover eventos da cidade e comunidade, organização social em diferentes núcleos (poderíamos ter "servidores núcleo" a nível municipal, estatal e federal); nada inovador, seria mais como alternativa às Big Techs nesse controle pela comunicação. Eu não preciso criar uma grande estrutura de rede social, se as pessoas diariamente utilizam celular com acesso à internet em suas mãos. Daí um serviço como o Gov.br poderia facilmente se tornar responsável por mediar essa relação de identidade.
O que preciso considerar?
* O que um projeto como esse tem de benéfico?
* Simplesmente porque há uma descentralização dos dados, há também uma descentralização do poder?
* Talvez uma motivação seja exatamente ajudar a pensar e desenvolver alternativas às Big Techs (?)
* Na realidade objetiva do brasileiro, a necessidade diária muitas vezes é chegar em casa vivo.
* De que adianta uma forma diferente de se interagir digitalmente, se no dia a dia a luta é pela sobrevivência?
* Qual a necessidade de ferramentas de organização, se não há organização?
* Nos movimentos políticos nos mais diferentes núcleos, qual o interesse de utilizar uma tecnologia do tipo?
* É preciso criar uma necessidade que sobreponha os benefícios do uso da Big Tech
* Somente a motivação moral e política, de ser uma alternativa muito mais segura à dados centralizados na mão de grandes empresas, não parece mover bastante esse senso de dever da maior parte dos grupos políticos
* Com certeza existe uma certa falta de conhecimento do assunto, é um movimento que ainda é pouco aderido, e geralmente é mais operado por uma comunidade mais técnica. Mas entendo também que há um senso de prioridade, e também concordo que existem outras lutas que estão na nossa janela de possibilidade agora e que precisam ser travadas também agora.
* Até que ponto é seguro apostar em redes centralizadas? Entendo que ainda há uma certa dimensão de ganho político em atuar nesses espaços, quase totalidade dos cidadãos do país estão nesses espaços, então a informação por consequência chega a mais pessoas. Por outro lado, são espaços que servem a interesses específicos, interesses voláteis que podem facilmente pender para um autoritarismo.
# Desafios
## É possível uma rede online sem a macro internet?
A necessidade de estar online para ser visto e ter postagens visualizadas.
**Possíveis soluções**
* A partir da adoção de um protocolo padronizado, os servidores em suas implementações podem guardar em cache esses valores. Talvez cabendo até ao usuário "salvar" certas postagens para ver offline, e fazer um cache do perfil da outra pessoa.
* Mecanismos de sincronização de dados, o que aumenta a complexidade.
* Servidores intermediários de store-and-forward
## Backup de dados
É ilusório achar que todas as pessoas irão se preocupar em fazer backup e guardar seus dados. Eu sendo bem sincero ainda não tenho uma resposta para isso, só consigo pensar que o ideal sejam serviços próprios para backup, como literais "bancos de dados", que servem exclusivamente para isso. Porém os dados mais atualizados devem sempre ser offline first.
Além disso, os arquivos HTML são gerados dinamicamente e servidos estaticamente, então os textos em si sempre estarão a fácil disposição, e em caso crítico, pode ser utilizado para recriar parte do banco de dados. Mas esse tópico dos dados é realmente muito sensível, difícil ter alguma resposta agora.
## Problema da identidade
Como falei anteriormente, preciso garantir uma forma segura de identificar pessoas. Eu descrevi alguns problemas mais cedo, mas talvez as soluções já se encontrem nos protocolos abertos que pretendo explorar (IndieWeb e ActivityPub), mas ainda preciso estudar mais sobre o assunto.
# Referências e links úteis
* https://indieweb.org/
* Princípios da IndieWeb: https://indieweb.org/principles
* Specs dos protocolos da IndieWeb: https://spec.indieweb.org/
* Micropub: https://micropub.spec.indieweb.org/
* Webmention: https://webmention.net/draft/
* IndieAuth: https://indieauth.spec.indieweb.org/
* Specs do ActivityPub: https://www.w3.org/TR/activitypub/
* Um texto interessante para entender como iniciativas como o BlueSky que se dizem descentralizadas fogem um pouco do princípio que o ActivityPub busca, por exemplo, como uma estrutura verdadeiramente descentralizada: https://dustycloud.org/blog/how-decentralized-is-bluesky/
* Nesse texto a autora também explica um pouco exatamente o problema da identidade que cerca o BlueSky
* Um projeto que acho que vai bem de encontro com o que estou pensando atualmente, mas que ainda estou devendo explorar mais, é o: https://activitypods.org/
* E o próprio projeto Solid, que busca trazer esse conceito da informação do usuário centralizada em um único ponto, os chamados Pods, que são utilizados para acessar diferentes tipos de serviço. A ideia é exatamente ser utilizada a nível governamental para gerir a permissão de dados públicos e privados: https://solidproject.org/
* * *
1. https://micropub.spec.indieweb.org/#examples-of-creating-objects-li-5↩︎
