Quantos serviços de mensagens usa? Slack, Discord, WhatsApp, Apple iMessage, Signal, Facebook Messenger, Microsoft Teams, Instagram, TikTok, Google Hangouts, Twitter Direct Messages, Skype? As nossas famílias, amigos e colegas de trabalho estão espalhados por dezenas de serviços, nenhum dos quais fala entre si. Mesmo sem tentar, podem-se facilmente acumular 40 aplicações no telemóvel que permitem enviar e receber mensagens. Estes números não estão em queda.
Não é a primeira vez que estamos nesta situação. Na década de 2000, os utilizadores tinham de escolher entre MSN, AOL, ICQ, IRC e Yahoo! Messenger, muitos dos quais seriam incorporados noutros serviços maiores. Programas como o Pidgin e o Adium agregavam os contactos num único lugar e permitiam aos utilizadores finais alguma independência de serem bloqueados por um serviço – ou pior, ter que escolher com quais os amigos com que se importavam o suficiente para aderir a outro serviço de mensagens.
Assim, a proliferação de serviços de mensagens não é nova. O que é novo é o ambiente de interoperabilidade. Empresas como a Google e o Facebook – que antes suportavam protocolos interoperáveis, até usando o mesmo protocolo de “chat” – agora rejeitam-nos. Mesmo empresas recentes como o Signal tentam dissuadir os programadores de desenvolverem os seus próprios, não oficiais, [programas-]cliente.
Encontrar uma maneira de unir todos esses serviços pode deixar muitos utilizadores da Internet felizes, mas não emocionará os investidores ou tentará uma empresa gigante de tecnologia a comprar uma startup. A única forma de reconhecimento garantida a quem tenta resolver esse problema são as ameaças legais – muitas ameaças legais.
Mas isso não parou os contribuidores voluntários de uma mais ampla Internet de interesse público (“Public Interest Internet”).
Veja-se o Matterbridge, um projecto de software livre/aberto que promete ligar “Discord, Gitter, IRC, Keybase, Matrix, Mattermost, MSTeams, Rocket.Chat, Slack, Telegram, Twitch, WhatsApp, XMPP, Zulip”. Esta é uma tarefa ingrata que requer que os seus colaboradores entendam (e, às vezes, façam engenharia reversa) de muitos protocolos. É um trabalho árduo e precisa de actualizações frequentes à medida que todos esses protocolos mudam. Mas eles estão a gerir a isso e a fornecer as ferramentas para se fazer isso gratuitamente.
Curiosamente, algumas das pessoas que trabalham nesta área são as mesmas que se dedicaram a ligar diferentes serviços de mensagens na década de 2000, e ainda estão a trabalhar nisso. Pode-se assistir a um dos principais programadores do Pidgin a codificar ao vivo no Twitch, redireccionando a base de código para uma nova era.
O Pidgin conseguiu sobreviver durante um longo tempo no deserto, graças ao apoio institucional da Instant Messaging Freedom (IMF), uma organização sem fins lucrativos que administra as suas limitadas finanças e garante que, mesmo que o desenvolvimento seja lento, ele nunca páre. A IMF iniciou-se em meados da década de 2000, após a AOL ameaçar os programadores do Pidgin, então denominado de GAIM. Planeado inicialmente como uma organização de defesa legal, ficou por aí para servir de base para as operações do serviço.
Perguntámos a Gary Kramlich do Pidgin sobre a sua devoção ao projecto. Kramlich demitiu-se em 2019 e viveu das suas poupanças enquanto empreendia uma remodelação séria do código do Pidgin, algo que planeia manter até Setembro, quando vai ficar sem dinheiro e terá que regressar a um trabalho remunerado.
“É tudo uma questão de comunicação e de aproximar as pessoas, permitindo que falem nos seus próprios termos. É enorme. Não é preciso ter 30 GB de RAM para executar todos os seus [programas-]cliente de ‘chat’. As comunicações funcionam em efeito de rede. Se a maioria dos seus amigos usar uma ferramenta e você não gostar dela, os seus amigos terão que fazer algo mais para o incluir na conversa. Isso obriga as pessoas a escolher entre os amigos e as ferramentas a que melhor se adaptam. Um cliente multiprotocolo como o Pidgin significa que se pode ter os dois”.
Muitos projectos de Internet de interesse público reflectem esse padrão: passar anos a trabalhar numa relativa obscuridade em tópicos que exigem trabalho concentrado, mas com pouca recompensa imediata, sob uma nuvem de risco legal que afugenta empreendimentos comerciais. Este tipo de trabalho é, por definição, trabalho para o bem público.
Após anos de trabalho lento, paciente e sem glamour, chegou o momento para o qual Pidgin, Matterbridge e outros estabeleceram as bases. Os utilizadores da Internet estão demasiado frustrados com a complexidade de gerir vários serviços de “chat” e de mensagens. As empresas estão a perceber isso.
Trata-se de uma aposta legalmente arriscada, mas acertada. Após décadas de crescentes restrições legais contra a interoperabilidade, a lei está a mudar para melhor. Numa tentativa de quebrar o aprisionamento dos grandes fornecedores de serviços de mensagens, o Congresso dos EUA e a União Europeia estão a considerar leis de interoperabilidade obrigatórias que tornariam o trabalho destes programadores muito mais fácil – e legalmente mais seguro.
A interoperabilidade é uma ideia cujo tempo chegou. Frustrados com o rastreamento universal e a publicidade invasiva, os programadores de software gratuito criaram “front-ends” alternativos para sites como o YouTube, Instagram e Twitter. Eles estão cansados de esperar pelos serviços que pagam para usar para adicionarem os recursos de que precisam, por isso estão a desenvolver [programas-]cliente alternativos para o Spotify e o Reddit.
Estas ferramentas já estão a atingir as metas que os reguladores estabeleceram para si mesmos como parte do projecto de domesticar a Big Tech. A Internet de interesse público dá alternativas sem rastreamento, serviços interoperáveis e ferramentas que colocam as necessidades do utilizador e a prosperidade humana antes do “envolvimento” e da “aderência”.
As ferramentas da interoperabilidade são mais do que uma forma de remodelar ou de combinar serviços existentes – são também formas de criar alternativas completas para os gigantes da media social. Por exemplo, o Mastodon é um concorrente do Twitter desenvolvido num protocolo aberto que permite que milhões de servidores e vários “front-ends” personalizados se interliguem uns com os outros (o Peertube faz o mesmo para o vídeo).
Estes serviços estão a prosperar, com uma base de utilizadores na casa dos sete dígitos, mas ainda lutam para convencer o criador ou o utilizador médio do Facebook ou do YouTube a mudar, graças aos efeitos de rede dos quais esses serviços centralizados beneficiam. Um criador do YouTube pode odiar as políticas de moderação autoritária da empresa e as recomendações algorítmicas imprevisíveis, mas ainda usa o YouTube porque é onde estão todos os espectadores. Cada vez que um criador entra no YouTube, ele dá aos espectadores outro motivo para continuar a usar o YouTube. De cada vez que um espectador assiste a algo no YouTube, dá aos criadores outro motivo para colocar os seus vídeos no YouTube.
Com [programas-]cliente interoperáveis, esses efeitos de rede são compensados por “custos de mudança” mais baixos. Se se podem misturar os feeds do Twitter e do Mastodon num cliente Mastodon, não importa se se é um “utilizador do Mastodon” ou um “utilizador do Twitter”. Na realidade, se os seus amigos do Twitter se podem inscrever para receber os seus “posts” no Mastodon, e se você pode usar o Mastodon para ler os seus “posts” no Twitter, então não perde nada ao sair do Twitter e passar a estar em exclusivo no Mastodon. Na verdade, até pode ganhar ao fazer isso, porque o seu servidor Mastodon pode ter recursos, políticas e comunidades que são melhores para si e para as suas necessidades do que o Twitter – que deve satisfazer centenas de milhões de casos de uso.
Na realidade, parece que os executivos do Twitter já anteciparam esse futuro, com o seu apoio ao BlueSky, uma iniciativa interna para acelerar esta interoperabilidade para que possam estar em melhor posição de lhe sobreviver.
Agora mesmo, neste exacto momento, existem centenas, senão milhares, de programadores a apoiar milhões de utilizadores iniciais na construção de uma visão de um mundo pós-Facebook, desenvolvido no interesse público.
No entanto, estes projectos raramente são mencionados nos círculos políticos, nem recebem apoio político ou governamental. Eles nunca são tidos em consideração quando são promulgadas novas leis sobre responsabilidade do intermediário, conteúdo extremista ou prejudicial ou direitos autorais. Se uma instituição pública alguma vez os considera, quase sempre são os tribunais, já que quem assegura esses projectos luta com a insegurança jurídica e cartas de advogados aterradoras exigindo que parem de procurar o bem público. Se o “establishment” político deseja realmente descomplicar a grande tecnologia, deveria estar a trabalhar com esses voluntários, não os ignorando ou se opondo a eles.
Este é o quinto artigo sobre a Internet de interesse público. Leia mais da série (em inglês):
Introducing the Public Interest Internet
The Enclosure of the Public Interest Internet
Outliving Outrage on the Public Interest Internet: the CDDB Story
Organizing in the Public Interest: MusicBrainz
* Texto original de Cory Doctorow e imagem publicados na EFF (CC).