translator_nbot

"40328080857ce321f9e89741e559f0a41edb3362cdcad3a163f1ede4e91536058e6094fa45b1b2adc4b40d2fbffb3445f4cc82b9dab8fe11d248ad0ac9da91a2"

Last Notes

2026-10-14 13:25:23 UTC

- reply

Você divide sua chave em muitas partes e dá a operadores semicondiáveis para assinarem coisas em seu nome.
Mais tarde, você precisa ser capaz de contatar esses operadores para recuperar seus fragmentos e reconstruir sua chave, ou pedir que eles as excluam. Portanto, você precisa de um mecanismo alternativo de autenticação.
Não precisa ser Google, como eu disse acima, pode ser qualquer outro método, mas o Google era fácil o suficiente para começar e chegaria a muitas pessoas.

2026-10-14 12:28:31 UTC

- reply

I really hate Google and don't want anything to do with it, I even used nostr-mill on @Ramal but removed that part of the code.
As long as there's another alternative, I'll be rehabilitating it. I'm going to take a look to understand it better.
Fuck Google Control
#nevent1q…54qd
#brasil #brazil #nostr #dev #devnostr #nostrdev

2026-10-09 03:38:20 UTC

- reply

@npub180c…h6w6 #asknostr #bloossom #ipfs
I think there is a way IPFS could be implemented as a second option to recover the same file if it's on both Bloom servers and IPFS.
A file has a sha256 and a unique CID, if both the name and the file structure are always the same when uploaded on NOSTR clients.
If a file is uploaded to servers first, the sha will be obtained first and then the CID would be obtained in case the user also decides to upload their files via IPFS to be able to recover them from that network.
A detail I noticed is that if the servers compress the file before uploading it, then the sha256 of the original file and its CID will no longer be the same, so if the file is later passed to IPFS, the file would have to be kept with the same structure and the same name so that both its sha256 and its CID are always the same in case the user decides to change servers in the future and make links from posts from years ago keep working thanks to always being able to have on a server a file with the same sha and the same CID.
If the file is uploaded to IPFS first, it would already have a fixed CID and sha256, trying to compress the file afterwards for Bloom servers would cause both its CID and its sha256 to no longer be the same, so now there would be 2 identical files but with different IDs, so the NOSTR client would no longer be able to recover it from IPFS because its CID doesn't match the original file.

2026-10-08 19:40:42 UTC

- reply

User Safety: safe

2026-10-08 19:32:00 UTC

- reply

User Safety: safe

2026-10-08 19:20:51 UTC

- reply

Right in front of me, a cat trying to climb a mere 15cm step tripped. I wasn't even laughing, but the cat yelled "Nyaa!" right at me, just for watching.
Did I do something wrong?