cada dia mais motivos pra ficar por aqui mesmo
Hey everyone! :)
Não po, o brasileiro gosta de pagar pra ser sodomizado.
O Boulos perdeu quando foi apoiado pelo Lula, não tem jeito. O Marçal foi só a cereja do bolo.
Getting mad on ticcmds...
Anyone that knows redb can try to run this and explain why it happens?
https://github.com/cfcosta/redb-bug/blob/main/src/main.rs
Basically I inject errors on storage operations, but the database gets inconsistent/borked when it happens.
Of course, I'm pushing it to an extreme level, but I kinda need that level of trust.
Cardanistas sempre bem vindos (por mim pelo menos)
Será que se o PCC começar a usar o X pra trabalho eles liberam?
Dentro da cadeia internet é livre
Worst part is not even the network itself, couldn’t care less and much prefer nostr.
It’s the people that are there and that now will be out of our reach. I’m not going to fucking instagram
But in the end, here's the deal.
I created mugraph precisely because I saw the censorship coming. Privacy is a human right, and I'll do my part so it stays that way.
Feels good to actually see more brazilians here.
Hopefully this is the kickstart we need, considering both bluesky and the fediverse are left eco-chambers.
Oh boy… 
I've specified something like this before, worked almost full time just thinking about this problem for 3 months or so. In a short answer: Double Ratchet/X3DH for messaging, zero-knowledge proofs so the server doesn't know the sender or the receiver.
Keep the merkle root of a Merkle Search Tree, derive the next key based on the root of the current chat tree. Tree is self-balancing and automatically ordered to keep causality in check.
Inside each message, keep an encrypted Hybrid Logical Clock id on each message, to keep both causal and wall clock synchrony, even in case of clock drifts.
For each destination (like a group), publish a single entry, and multiple public keys, one for each destination. Add a random number of other public keys to obfuscate which are real and which are not.
When fetching, user sends a proof that, given the sender public key, they have ownership of the proof. Proof is consumed on the relay. User updates their own Merkle Search Tree on the client with each proof they consumed.
User then publishes new proofs for the same content they received, but with their own "backup key". These are kept in the relay for user device backup.
All keys are ephemeral, except the backup key, which can be the user nsec key. User publishes public one-time-use keys (either by publishing to relays or NIP-05).
Basically the chat conversation is a CRDT, and the same relay mechanism that nostr uses guarantees delivery without the need for consistency (which are also not required for crdts).
A little bit stream of counciousness, but I can give detailed explanations about everything I talked about here, and even wrote most of it down, just ping me if you need.
Covenants? DLCs? Stablecoins? What are you daydreaming about? Take your creatine, it's leg day.
Hot take: WASM is a better Docker, not a better jvm. Being better than the JVM is just a nice side-effect.
I really like the one time payment model, but if I had to choose a recurring one, would prefer to pay yearly. Recurring transactions in crypto are shit right now.
Is there a NIP already covering client auth?
