Todos os mensageiros existentes têm seus prós e contras, mas cada um deles puxa o cobertor para o lado devido à incompatibilidade com os outros - e os usuários sofrem com isso.
O XMPP poderia se tornar um padrão único, mas, diferentemente do E-Mail, parecia relativamente tarde e não conseguiu ganhar audiência suficiente para que as empresas já não pudessem recusar. Afinal, eles rapidamente perceberam que, sem reter o público dentro de seu próprio ecossistema, não há muito a ganhar. Além disso, devo admitir, o XMPP apresentava insuficiências suficientes devido à abundância de extensões, muitas das quais, apesar de sua importância, permaneceram em status experimental e algumas se duplicaram completamente.
Tendo vivido no “novo mundo maravilhoso” de uma dúzia de mensageiros instantâneos no smartphone e tendo sentido todas as deficiências desse estado de coisas, finalmente estamos prontos para algo novo.
E sim, precisamos de um novo padrão!
Um excelente Future Messenger atende aos seguintes requisitos: garantia de confiabilidade, segurança, por meio de desenvolvimento e descentralização abertos, portabilidade (multiplataforma), multiprotocolo (capacidade de conexão com outras redes de comunicação) e facilidade de uso.
Por que tudo é tão ruim?
Mas primeiro, vamos descobrir por que todo mundo simplesmente não muda para alguém já popular == mensageiro centralizado, seja um WhatsApp condicional ou, digamos, Telegram, que possui uma audiência considerável na Rússia.
Obviamente, a construção centralizada permite que os proprietários obtenham mais dinheiro e, portanto, não apenas paguem pelo desenvolvimento, mas também invistam dinheiro significativo em publicidade e até glorificação de funções praticamente ausentes , como segurança de serviço, por exemplo. No entanto, junto com isso, o proprietário pode decidir repentinamente fechar o serviço, o trator para mover o fio do data center ou apenas um mensageiro pode ser banido no território de um determinado país. Não necessariamente por razões políticas, talvez, e a pedido de detentores de direitos autorais condicionais, pode haver muitos motivos. É bom que, apesar do tamanho insignificante do mercado, o Telegram continue a trabalhar na Rússia com sucesso variável, mas isso se deva às contas pessoais do proprietário e, no caso de bloquear o mesmo WhatsApp, é improvável que o Facebook invista pesadamente para contornar os bloqueios.
É difícil falar imediatamente para todos os mensageiros centralizados, coletando sob um pente. Existe um mal absoluto com um cliente, servidor e protocolo proprietários que até funcionam em apenas algumas das plataformas mais populares e não possuem criptografia. Também há uma bondade relativa, por exemplo, o Signal messenger, que está totalmente aberto, mas os servidores não suportam o modo federado, e é por isso que todos dependem do servidor central com todas as conseqüências resultantes. Aqui, a classificação deve ser realizada de acordo com um princípio diferente, mas isso está além do escopo deste artigo.
Bem, por que não mudar para algo federal. Por exemplo, a mesma matriz. Não falarei sobre HTTP Long Polling, baixa resiliência do servidor e a nerdice explícita da interface do cliente - todas essas são tarefas solucionáveis, embora não triviais (no nível global, isso não muda nada). Eu gosto que os desenvolvedores levem em conta a experiência do XMPP e desenvolvam especificações comuns em vez de vários XEPs independentes, mas essa é apenas uma das desvantagens do XMPP. Outro problema é o dispositivo clássico da rede federal, quando somos forçados a escolher algum servidor e confiar no proprietário que ele garantirá que o servidor esteja funcionando e não o fechará. E, no caso de outra falha do datacenter, seremos afastados do mundo, não sendo capazes de nos comunicar com a conta anterior em outro servidor. Mesmo que você crie uma nova conta e, de alguma forma, transfira a lista de seus contatos para ela do servidor antigo, ao se comunicar, precisará confirmar de alguma forma que é realmente você e não alguém que o apresenta.
Nesse caso, talvez abandone completamente o servidor? Há vários mensageiros instantâneos baseados na tecnologia sem servidor. Um caso especial aqui é o popular em círculos estreitos, o Firechat, que usa uma rede de malha de dispositivos Wi-Fi e Bluetooth para se comunicar com os usuários. Esse messenger realmente funciona bem quando todos os usuários estão concentrados, por exemplo, na área. Mas essa é uma situação bastante específica e, mesmo que imaginemos uma situação em que todo habitante do planeta instale um aplicativo, isso cria muitos outros problemas, desde quebras na rede de malha por sinais geográficos e a velocidade de troca de mensagens com usuários distantes, até a quantidade de dados armazenados necessários nos dispositivos. Mas, provavelmente, esse mensageiro é eliminado da massa total e, em nossa comparação, é supérfluo. É mais experimental do que centrado no usuário.
Também existem projetos como o Tox tentando implementar um messenger p2p. Essa abordagem permite que você não se preocupe com a segurança do servidor e é quase impossível bloquear esse messenger. O Tox tem muitos problemas, mas este é um projeto muito interessante que tem seu próprio nicho. Não faz sentido listar as desvantagens específicas do Tox, porque o projeto está em desenvolvimento e, apesar de os serviços p2p serem muito mais difíceis de desenvolver, se você definir essa tarefa, poderá criar várias arquiteturas interessantes para a construção de uma rede: com vantagens e desvantagens próprias, requisitos diferentes para a largura do canal da Internet e a quantidade de espaço no dispositivo, com supernós, login simultâneo de diferentes dispositivos e até entrega de mensagens offline. Porém, comum sempre haverá redundância significativa de tráfego em comparação com a arquitetura cliente-servidor e aumento do consumo de bateria em dispositivos móveis devido à necessidade de manter constantemente um grande número de conexões e vários cálculos.
Portanto, embora o p2p seja uma tecnologia interessante, ele será ineficaz se, por exemplo, enviar suas coordenadas para equipes de resgate, estiver em algum lugar de uma árvore na taiga com quase nenhuma conexão com a Internet e 1% de carga da bateria.
Como consertar isso?
Portanto, quero introduzir uma arquitetura híbrida cliente-servidor que aproveite ao máximo as abordagens existentes e evite suas desvantagens.
Portanto, para que nosso messenger com os recursos mínimos necessários funcione em dispositivos móveis, usaremos o modelo cliente-servidor, onde o máximo de operações de computação e recursos exigentes de tráfego estão concentrados nos servidores e, no lado do cliente, os dados são descriptografados e exibidos ao usuário.
Endereçamento
Cada usuário recebe seu endereço no formato de email ou XMPP, ou seja, apelido @ domínio. Mas, diferentemente dos serviços mencionados acima, a especificação de um domínio não possui a mesma função de endereço importante nessa arquitetura.
É mais provável que os domínios sejam usados como registradores de apelidos para descartar a possibilidade de que todos os apelidos existentes possam ser ocupados intencionalmente ou não.
Os domínios custam dinheiro na Internet, o que não impede o registro em massa, mas reduz significativamente seu escopo. Nos serviços centralizados, o acesso geralmente ocorre por meio de um link para um telefone celular, o que também não é um fator exclusivo, mas os cartões SIM também não são retirados do ar! E a esse respeito, a propósito, eu me pergunto como eles vão combater isso em https://toxme.io/ - um serviço para o Tox que permite associar chaves longas a um apelido curto. Não vejo razão para que eles não possam receber spam com bilhões de apelidos indesejados.
Além disso, o domínio pode fazer sentido para várias contas de casa e trabalho. Ou para organizar uma rede corporativa interna.
Do ponto de vista do usuário, para escrever para alguém, você precisa conhecer o seu login completo ou chave pública.
Do ponto de vista do software do servidor, se um usuário solicitar sua impressão digital, o servidor pesquisará em sua tabela o logon associado a ele, se for solicitado imediatamente o logon, respectivamente, esta etapa será ignorada. Em seguida, são feitos o login e o endereço do servidor ao qual a conta está atualmente delegada. Se não houver essas entradas, considera-se que a conta indicada após @ no login é responsável pela conta.
Perfil do usuário
O aplicativo cliente armazena um perfil de usuário representando:
- Login completo do usuário
- Lista de servidores de backup
- Chave de usuário pública e privada
- Informações de perfil, como lista de contatos, configurações de bate-papo e perfil de usuário
As chaves públicas de cada usuário são distribuídas entre cada um dos servidores na rede federada. O usuário pode efetuar login em qualquer um dos servidores, pois a autenticação não usa um hash de senha armazenado no banco de dados do servidor, mas a chave privada do usuário.
O procedimento de autorização é o seguinte: o servidor envia um conjunto aleatório de dados criptografados com a chave pública do cliente para o cliente, o cliente descriptografa com sua chave privada e envia um hash dos dados descriptografados para o servidor. Se os hashes de dados corresponderem, o servidor autorizará o usuário. Ao mesmo tempo, se o usuário alterou pela última vez o servidor para o qual a conexão é estabelecida, todos os servidores da rede federada serão notificados do novo local do usuário.
A ausência da necessidade de lembrar a senha (no entanto, o cliente permite criptografar a chave privada) simplifica a interação com o messenger e cria o risco de perder as chaves. Para evitar isso, é recomendável duplicá-los para outros dispositivos do usuário. Nada impede o bate-papo na mesma conta de vários dispositivos ao mesmo tempo, a única limitação é que todos devem estar conectados ao mesmo servidor, caso contrário, a arquitetura se tornará muito confusa. Mas isso não é um grande sinal de menos.
Complemento para navegadores
Para muitos produtos, o ponto fraco é um aplicativo da web. E essa solução, é claro, tem muitas desvantagens. Esse bate-papo não será baixado enquanto você estiver off-line; será necessário aguardar o download completo e o endereço poderá estar bloqueado ou o servidor poderá falhar. Classificação manual de endereços - eu particularmente não gostaria.
E ainda não está excluída a opção de um invasor invadir um aplicativo Web e incorporar código que mesclará todos os seus dados - mesmo depois que a outra parte do aplicativo descriptografá-lo para você, e você nem o conhece.
Nesse sentido, proponho abandonar o aplicativo Web como tal e proponho a instalação de um complemento para o navegador, no qual todas essas deficiências estão ausentes por definição.
Além disso, a ausência da necessidade de os proprietários dos servidores de configuração do cliente da web reduzirem o limite de entrada para a criação de seu servidor. Cada família tem seu próprio servidor!
Transportes
Quem precisa de um mensageiro no qual não haja ninguém com quem se comunicar? Existem projetos interessantes de mensageiros incomuns, mas o problema da falta de audiência não lhes permite ganhar pelo menos alguma popularidade. Como resultado, na maioria das vezes os mensageiros com um grande público ganham ainda mais e os mensageiros instantâneos com um pequeno público o perdem. E, na maioria das vezes, essa situação só pode alterar investimentos significativos em publicidade.
Além disso, esse estado de coisas exige a instalação de outro messenger, quando você precisa entrar em contato com alguém que não está em outras redes.
Portanto, o servidor deve suportar a operação de transportes para redes de terceiros.
Se o usuário especificar os dados para conectar-se às suas contas em outros mensageiros instantâneos, ele verá pessoas das redes que ele conectou em seus contatos.
A conexão com redes de terceiros é feita no lado do servidor e, no cliente, os contatos são exibidos como os mais comuns, com diferenças mínimas - por exemplo, o ícone da rede de onde o usuário é é exibido.
Como desvantagem, torna-se necessário confiar no servidor com seus dados para conectar-se a redes de terceiros. Nem todo mundo está pronto para delegar sua autoridade a um servidor de terceiros, portanto, é necessário incentivar a criação de seus próprios servidores de todas as maneiras.
Criptografia
Obviamente, um dispositivo de rede descentralizado não consegue ficar sem a criptografia de todos os dados transmitidos, porque não podemos ter certeza de que, mesmo no servidor que nos foi confiado, não exista algum tipo de guia que mescla todos os dados.
Anteriormente, já foi indicado que o par de chaves do usuário é usado para autorização, todas as mensagens enviadas para outros usuários também são assinadas com a chave privada do remetente e são criptografadas com a chave pública do destinatário.
Não há nada de novo aqui, as ferramentas de criptografia GPG padrão são usadas.
O problema de criptografia em grupos ainda não foi resolvido, mas você provavelmente pode usar o mecanismo usado no Signal.
O que já foi feito
No momento, já criamos um servidor em Python usando o Tornado, que implementa as funções básicas do messenger, existe uma versão da Web ligeiramente congelada que deve ser convertida em uma adição para o navegador, existe uma biblioteca no Rust, com base na qual o cliente opera com uma interface QML.
A conexão com o servidor é realizada usando WebSockets, em que os dados são serializados por padrão no formato binário de representação de dados CBOR, mas ao estabelecer uma conexão WebSockets, é possível solicitar um formato diferente, por exemplo, protobuf.
Também considero importante observar que o cliente usa uma divisão em uma lista de bate-papos, classificados pela data das últimas mensagens, amplamente usada em mensageiros instantâneos modernos e em uma lista tradicional, com a classificação de contatos em categorias. Com o uso ativo do messenger, você precisa interagir com um grande número de bate-papos, e fica difícil procurá-los em uma ordem de lista em constante mudança. No mesmo telegrama resolve parcialmente o problema de fixar os chats selecionados no topo da lista, mas essa é apenas uma solução temporária para o problema.
→ Aqui estão os repositórios que contêm nossos insights