Avatar
EddieOz ⚡
eac630759e313832c4d0113b9e1082279fb0efa6a9ce81cda9e8a366b4988b48
Privacy. Freedom. Cryptography. Buidler/Creator/Artist/Educator/Anti-influencer 🇧🇷🇪🇪 E-Residency Envoy [GPG][C2056B0C12D579A5B172AB853480FB98373B56FB]

Eu testei lá e vi que dá pra usar uns templates do Ghost (onde eu hospedo meu blog) e que vc escolhe se quer que ele publique posts longos, notas, etc. Muito bacana!

Eu só entrei mas não fiz a jornada completa e crítica. Vou dar uma atenção pra ele com mais calma después.

Replying to Avatar Girino Vey!

nostr:npub1atrrqav7xyur93xszyaeuyyzy70mpmax488grndfaz3kddyc3dyquawyga, conhecia esse?

nostr:note1kdp9ad8rlzhds0cye74d8mn0k79w6jwh2233aw8t9e3pwzcczvksckdx3s

Conheço não! Acabei de ver que tem menos de uma semana de vida!

É uma boa pedida tb. Uso para algumas coisas, e o Brave pras coisas do dia-a-dia

sempre a mesma desculpa... no sistema deles que é todo regulado e acontece coisa pior o tempo todo, todo mundo solto.

A EU tá #$@%N@#$%H

"Chat Control", a proposta de lei da UE que pode banir os serviços de mensagens criptografadas na União Europeia, retornará novamente este mês.

O projeto de lei tem como objetivo vasculhar todas as mensagens e chats privados em busca de conteúdo suspeito (chamado de controle de chat ou regulamentação sobre abuso sexual infantil).

De acordo com a última proposta, os provedores teriam a liberdade de decidir se usam ou não ‘inteligência artificial’ para classificar imagens e chats de texto desconhecidos como ‘suspeitos’.

No entanto, eles seriam obrigados a procurar todo o conteúdo de chats conhecido como ilegal e relatá-los, mesmo que isso custe a quebra da criptografia de ponta a ponta nas mensagens.

Os governos da UE devem se posicionar sobre a proposta até 23 de setembro. Atualmente, apenas a Polônia e a Alemanha indicaram que votarão contra.

Estônia, Tchéquia, Áustria, Eslovênia e Holanda têm dúvidas.

Os ministros do interior da UE devem aprovar a proposta em 10 de outubro.

Os provedores de mensagens Signal e Threema já anunciaram que nunca concordarão em incorporar essas rotinas de vigilância em seus aplicativos e preferem encerrar as operações na UE.

(post original: https://x.com/visegrad24/status/1834401718458593447)

Valeu nostr:nprofile1qqs20ncyach78fcrspuwegzje73u2und2wf96gtz23rgkseteem9gpgpz3mhxue69uhkummnw3ezuctnv3nzumtc9uq3samnwvaz7tmwdaejumr0dshjxemjdamkummnw3eqz9mhwden5te0dehhxarj9e3kj7ndv9ezumn9wshsrqn6nn! A única contribuição que eu posso fazer é que a computação quânticaa tem uma taxa de erro muitpo alta, e gasta-se boa parte de recursos (qubits físicos) no tratamento e correção de erros. É como se qto maior a velocidade, maior o ruído. Então o aprimoramento depende tb de aperfeiçoar métodos de correção de erros.

Pra isso chegar em escala comercial, estima-se décadas ainda.

Obrigado pela recomendação!! Valeu!!

Recentemente eu mostrei na live!Basicamente é ataque de side channel

Essa eu mostrei logo que lançaram! Testei e tava tudo zuado o serviço

Se você utiliza Monero na Cake Wallet, exclua o node node.moneroworld.com da lista.

Este pode ser um dos nodes espiões que foram infiltrados na comunidade para rastrear transações.

Já providenciaram a retirada no github, deve vir sem em uma próxima versão: https://github.com/cake-tech/cake_wallet/commit/580bd013457e40719f07ff22838467c02a1562d8

Vc sabe que o Nostr ainda não tem relevância para criarem um malware pra roubar as chaves dele, né? Os malwares estão focados em seeds e private keys em apps de criptomoedas.

Ainda não entendi a correlação. De acordo com o post da Mcafee os 280 apps malware tinham comportamento similar, e nenhum sobre o Nostr.

Acho que quem usa Nostr tá bem safeenquanto não tem relevância para virar alvo.

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

.

Acabei de ver na NIP 17 que eles aconselham o client manipular o campo 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

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.