Jake Lazaroff apresentou uma palestra argumentando que o protocolo AT (atproto) poderia ser usado como base para aplicações distribuídas, e não apenas como infraestrutura para redes sociais. A sessão centrou-se numa arquitectura local em que os utilizadores armazenavam os seus próprios dados em servidores de dados pessoais (PDS), enquanto as aplicações utilizavam uma infra-estrutura de protocolo partilhada para armazenamento, autorização, sincronização e actualizações. Sua afirmação central era.
Lazaroff começou com a história de um aplicativo de planejamento de viagens que ele construiu durante um período sabático. O aplicativo usou YJS junto com um servidor de sincronização gerenciado. Cerca de um ano depois, o provedor de sincronização foi adquirido e encerrado. O aplicativo ainda funcionava localmente, mas a sincronização de vários dispositivos não funcionava mais, deixando a passagem manual de arquivos como alternativa. Ele usou esse exemplo para ilustrar a tensão mais ampla entre a infraestrutura colaborativa e a resiliência: o mesmo servidor que permitiu a sincronização entre dispositivos também se tornou a dependência mais fraca da aplicação.
Ele então descreveu o atproto como um modelo arquitetônico alternativo. Em vez de cada aplicativo manter seu próprio back-end isolado, cada usuário manteve os dados em um PDS e concedeu aos aplicativos acesso a eles. Neste modelo, o PDS fornecia armazenamento, autenticação refinada e atualizações push. Lazaroff descreveu o App View, um servidor personalizado por aplicativo na arquitetura atproto padrão, como opcional e como o ponto mais fraco da pilha.
O segundo experimento implementou uma lista de tarefas colaborativas usando registros CRDT nativos. Os registros eram objetos JSON simples contendo campos como `$type`, `listId`, `text`, `done` e `createdAt`, com metadados CRDT anexados separadamente. Lazaroff argumentou que isso tornava os registros autoexplicativos, mesmo para aplicações que ignoravam os metadados do CRDT. O design usou registros last-write-wins para cada campo, o que evitou conflitos quando edições simultâneas tocavam campos diferentes. Quando as gravações simultâneas visavam o mesmo registro, a lógica de comparação e troca rejeitava a gravação, após o que o cliente buscava o estado mais recente, mesclava localmente e tentava novamente. O principal desafio neste caso foi lidar com gravações simultâneas no mesmo registro sem perder atualizações ou quebrar o modelo CRDT.
No terceiro experimento, Lazaroff usou atproto como mecanismo de sinalização para chat de vídeo WebRTC. Um par escreveu registros de candidatos ICE (Estabelecimento de Conectividade Interativa) em um PDS nomeando o destinatário pretendido, o outro par ouviu através da retransmissão e respondeu, e os pares então estabeleceram uma conexão WebRTC direta. Durante a demonstração ao vivo, as condições de Wi-Fi da conferência exigiram o uso de um relé TURN (Traversal Using Relays via NAT), que ele chamou de "servidor TURN da vergonha". Ele também sugeriu que os canais de dados WebRTC poderiam complementar o atproto, fornecendo transporte em tempo real para aplicações locais. O principal desafio aqui foi a travessia da rede, uma vez que a conectividade de conferência não confiável impediu uma conexão peer-to-peer limpa e direta e forçou o retorno à infraestrutura TURN.
Durante a palestra, Lazaroff argumentou que os desenvolvedores deveriam construir em infraestrutura compartilhada, em vez de servidores por aplicativo. Ele citou a ideia de que os servidores deveriam permanecer simples, genéricos e fungíveis. Ele apontou vários hosts PDS independentes, retransmissões públicas gratuitas e esforços de agregação apoiados pela comunidade como sinais de que o atproto já apoiava essa direção. Na discussão final, as perguntas do público centraram-se nas vantagens e desvantagens da interoperabilidade, sincronização e implantação do WebRTC. A principal conclusão permaneceu consistente durante toda a palestra: o atproto foi apresentado como uma base viável para aplicações distribuídas, não apenas para plataformas sociais.
As informações são do site InfoQ
