agora, fiquei surpreso. acabei de criar um grupo com amigos próximos achando que a porra era criptografada kkkkk

grupos não são criptografados no tg, apenas chats 1 pra 1 são.

explicando melhor: grupos são criptografados com o certificado do servidor do telegram, ou seja, pessoas de fora não leem, mas os "donos" do telegram lêem. Chats 1 pra 1 são criptografados "ponto a ponto", ou seja, são teoricamente privados. mas.... A criptografia do telegram é proprietária, não usam algoritmos padrão do mercado, o que leva a crer que podem haver backdoors mesmo na cripto ponto a ponto deles.

E você pode puxar absolutamente todas as conversas e participantes de qualquer grupo, sem sequer ser participante do grupo.

essa eu não sabia. Como? usando a API de bot?

Nao não... as apis publicas mesmo... não precisa registrar bot

Methods

Accepting the Terms of Service Name Description help.getTermsOfServiceUpdate Look for updates of telegram's terms of service…

O problema do 0xchat é que ele é só um wrapper para as DMs do Nostr. E infelizmente tem uma questão de privacidade muito grande, pq a única coisa privada é o conteúdo da mensagem. Todo o restante como a identidade das partes, timestamp, e outros metadados ficam disponíveis. Por exemplo, você sabe quem conversa com quem e quando estiveram trocando mensagens, além da qtde de mensagens trocadas. Isso pode ser usado para montar um mapa de atividades/clusterização e relacionar a outras informações coletadas online. Ideal é que houvesse a implementação de um protocolo que realmente trouxesse privacidade ao Nostr, como essa prova de conceito que eu demonstrei aqui:

GitHub

GitHub - eddieoz/nostr-stealth: Built on top of the Nostr protocol, specifically designed to ensure sender and receiver metadata full anonymity. Leveraging the concept of channels (or mixers), Nostr-Stealth ensures that individual messages between users cannot be distinguished or differentiated, thus enhancing user privacy.

Built on top of the Nostr protocol, specifically designed to ensure sender and receiver metadata full anonymity. Leveraging the concept of channels...

Verdade, mas o 0xchat tem uma função que não vaza os metadados, acho que se chama gift wrapped, ou algo assim.

Sim, por isso mesmo, mas grupos abertos não vejo problema, Agora DM eu acho que sempre vai ter problema pois se vazar a nsec de alguma da partes o conteúdo é vazado. Além disso, uma nsec pode vazar e você nunca saber que vazou, e a pessoa ficar bisbilhotando suas DM's. Eu vi um pessoal comentando sobre usar a nsec como uma chave privada do Bitcoin, aí vc manda uns Bitcoins para essa chave, se a chave vazar, a pessoa terá um incentivo para roubar seus bitcojns e assim vc saberia que a chave vazou. Sei que o pessoal está trabalhando em outros esquemas para resolver esses problemas de DM no Nostr, mas não tenho acompanhado.

O wraped gift sempre vaza o destinatário e o horário da mensagem, assim como o volume de mensagens recebidas - mostrando o nível de atividade de comunicação privada. Eu acompanhei a criação do modelo e na época a discussão foi que preferiam implementar esse modelo pq achavam seguro o suficiente e tinha a NIP praticamente pronta, ao invés de iniciar a discussão sobre um modelo totalmente privativo e confidencial. Foi aí que concluí o protocolo por conta própria e publiquei para o caso de alguém achar interessante e implementar num cliente. A grande diferença da minha proposta é que um canal deve ser aberto para as partes (é só um nome de canal em comum para a conversa, mais ou menos como Veilid e SimpleX), enquanto que o wrapped gift manda a mensagem diretamente para o recipiente. Só que o wrapped gift vaza alguns metadados e na minha proposta, não. Outro ponto que me incomoda nos wrapped gifts é a sugestão de que o cliente tem que tomar alguns cuidados opcionais na implementação para proteger os metadados, e um erro ou não observação (ou atualização maliciosa) faz com que o protocolo continue funcionando, mas outros metadados acabem vazando sem que o usuário saiba.

O wrapped gift vaza o destinatário sim, senão não seria possível a pessoa receber. A diferença é que uma DM normal é kind 14 (ou kind 4 se for muito antigo) e o wrapped gift é kind 1059. Talvez o bot não esteja monitorando kind 1059 ou o cliente usado esteja usando um alias para o <p>. Acabei de ver na NIP 17 que eles aconselham o client manipular o campo <created_at> para não mostrar a data de criação, mas o relay que receber a mensagem terá esse log. Assim como uma sugestão dos relays de não servir 1059 para clientes não listados, que é interessante mas depende da configuração de cada relay. Vi um ponto de colocar no <p> ou a pubkey ou um alias. Isso também é interessante, mas depende da implementação do cliente. No NIP 17 eles fazem várias recomendações de implementação para os clientes e relays, para protegerem os metadados. Não é uma coisa que o protocolo faça sozinho e tem vários pontos de atenção: desde a possibilidade de censura pelo relay, como enumeração. Apps ou relays maliciosos ou comprometidos poderiam reter certas informações sem que o público saiba.