Meus 2 cents,
Parabens pela iniciativa e por compartilhar conosco !
Sempre eh positivo mergulhar em projetos como esse - seja como aprendizado ou como a busca em criar algo para a comunidade.
Focando no projeto, vamos tentar sintetizar seus objetivos:
- Criar uma metodologia de envio de mensagens assincronas baseado em uma estrutura "cliente" e "servidor", onde as mensagens nao expiram e ficam em stand-by caso do destinatario nao esteja disponivel ate que a entrega seja realizada. As mensagens podem ser apagadas pelo remetente caso desejado. Toda a comunicacao deve ser criptografada e os servidores apenas fazem o delivery da mensagem, sem interagir com seu conteudo.
OK - acho que isso meio que cobre "o que" o projeto deve fazer.
Agora vem o "como fazer".
Uma questao que se torna meio obvia eh que nao podemos ter apenas 1 servidor - afinal a ideia eh resiliencia. Entao precisamos pensar em uma forma de ter diversos servidores comunicando-se entre si. Mas estes servidores precisam ser independentes - mas seria legal se pudessem trabalhar em conjunto para a entrega das mensagens, roteando (relay) o trafego.
Alem disso tem a questao do registro: o cliente precisa ter uma identificacao unica nesta rede - mas os servidores precisam saber onde o cliente esta conectado para fazer o delivery.
Seria algo como: cliente se conecta no servidor, servidor divulga que tem este cliente, servidores ja sabem onde deve entregar a mensagem.
Legal, mas tem um problema: volume de trafego - se tivermos milhoes de clientes se conectando, ficar gerando anuncios de conexao pela rede nao eh pratico (alem do fato de que esta conexao pode cair e precisamos anunciar novamente, talvez ate sem que o primeiro anuncio tenha terminado).
Um passo atras: precisamos de uma rede de servidores descentralizados que consigam saber quais os servidores disponiveis e quando alguem conecta neles para fazer o delivery.
Mas surge uma pergunta: o delivery sera do tipo "push" ou "pull" ? Como fazer isso de forma eficiente ?
Exemplificando: o cliente se conecta, a rede de servidores detecta isso e envia as mensagens pendentes ("push") ou o cliente se conecta e sai perguntando para os servidores "voce tem algo para mim ? ("pull")·
Hummm, nenhuma das forma parece muito eficiente - temos de repensar um pouco aqui.
Uma possibilidade seria o cliente ter um servidor de preferencia/referencia - assim resolve varios problemas: nao preciso ficar fazendo o anuncio e os servidores ja sabem onde entregar a mensagem independente do cliente estar conectado.
So preciso que cliente identifique qual o servidor de preferencia - e isso poderia ser dinamico.
Hummm, eh uma ideia: um cliente com identificacao unica, que aponte seu servidor de mensagens de preferencia e que os servidores consigam entregar as mensagens entre si.
Parece fazer sentido.
Poderiamos ter 2 protocolos especificos: o protocolo entre cliente e servidor e o protocolo entre servidores - para tornar o processo mais eficiente, afinal as necessidades do delivery para o cliente sao um pouco diferentes do roteamento entre os servidores.
Hummm, poderiamos chamar este protocolo entre cliente e servidor de IMAP ou POP e o protocolo entre servidores de SMTP - parece fazer sentido.
Bricandeiras a parte - acho a ideia interessante: so precisa pensar um pouco em como diferenciar do email e aproximar de sistemas de IM.
Talvez pensar nos servidores em rede MESH ou ate algo semelhante ao um sistema de BLOCKCHAIN (TANGLE ?) para viabilizar.
Saude e Sucesso !