The next US president will be from the America party. "I guaran-damn-tee it"

QUIC is pretty cool. You can start a client and then the server afterwards, and it still connects. A client can switch from WiFi over to 4G and still be connected.

as for Mosaic... Motivation comes from unrealized ideas. You have an idea. It doesn't exist. You are motivated to make it real. Procrastination comes from a series of attempt-fail cycles. After a certain amount of failure, your motivation is drained, and a deep-seated human brain heuristic kicks in which makes you not want to try again. This heuristic works well in the physical world, but is misapplied in the abstract programming world since in the abstract programming world trying again always means trying something different. Yet the heuristic is low-level and you need to use mental tricks to bypass it. Higher level wisdom that might tell you something like "don't build mosaic, it could fork the community" isn't actually effective at stopping you from doing something that you are motivated to do. Because higher level thinking evolved much later and doesn't affect your core motivations. So that motivation to make it real just nags at you until you do it. I supressed it for many months and it didn't go away. To those of you who found mosaic: please don't use it. It will change drastically over time. Nobody has reviewed it yet. I've not pointed at it and held it back from review, comments and feedback because I didn't want to waste people's time with incomplete stuff that was rapidly changing. Will it be a new protocol that starts over? Or is it an experiment to learn from? I don't know. I can't seem to figure out how to get these features into nostr, the nostr community seems happy with JSON, with websockets, with a single key using FROST remote signing, with finding relay lists on "popular" relays, with relays using URLs not keys, depending on CAs and DNS, outbox model being optional, AUTH command ordering issues, kind1 vs kind1111 issues, the notion of relays being front-and-center in user's minds is debatable (I think they can and should be mostly hidden magic), the fact that every relay is deeply different and there is almost no way to know what you are getting. The simplicity ethic I feel is taken too far. And the just one-way rule. NIP-11 out of band is a pain. Endless stream of breaking changes. Maybe these are irreconcilable differences. It is becoming harder for me to imagine that they are not.

Interesting video on money, quite a different take than I hear from bitcoiners: My summary of the video: There were never any barter economies. Money predates writing (the oldest writing cuniform on clay tablets were accounting records). Money is always tightly tied up with state power, primarily because states can enforce payment for debts owned which originated from people accidently harming other people.. the governmental power steps in and says "A owes B X amount of state-approved money to make this right." Thus, the value of a currency without intrinsic value is imparted to it by the power of the state that controls that money. Taxes just tie it even tighter to the governmental power. Every central power (state) has it's own money, with few exceptions (e.g. the Euro experiment, which is failing).

Conspiracy theories are so popular now, I just ran across a YouTube video that asks whether the Gilligan's Island shipwreck was by design. 🤦

Ask yourself this question: Who does the government work for? They work for the people of the nation, right? So when interviewed about a military op, should they tell the truth? No. Because that would be working for the whole damn world, including your enemies.

I've been working on alt-tls. I have a lot of commits that haven't been pushed, which will push once I finish and test all the algorithms. Why? I want these things: 1) I want a pure-rust solution because that will compile everywhere that rust compiles without system library version issues, people filing bugs related to linking shit that I don't care about. A pure rust solution will be a bit slower but that is OK by me. 2) I want QUIC support 3) I want to hack the CertificateVerifier to simply verify that the public key is exactly as the library consumer expects it to be, rather than trusting CAs and DN namespaces. 4) I wanted a blake3 variant cipher suite (because IMHO blake3 is just better). A while back I created alt-tls and did (3) cert verifier and (4) blake3 cipher suite. It also satisifed (1) pure rust. But it didn't have (2) quic support. Surveying all the providers I could find yielded this: Provider Quic Support rustls internal: ring Ring Yes rustls internal: aws_lc AWS LC Yes boring-rustls-provider Boring Yes rustls-graviola Graviola No rustls-openssl OpenSSL Yes rustls-rustcrypto Rust Crypto No (barely started and stalled) rustls-mbedtls-provider mbedtls No rustls-symcrypt Microsoft SymCrypt No rustls-wolfcrypt-provider wolfcrypt No I currently have full quic support working and tested against RFC 9001 appendix test vectors for : TLS13_CHACHA20_POLY1305_BLAKE3 (non-standard) TLS13_CHACHA20_POLY1305_SHA256 What is left to complete is: TLS13_AES_128_GCM_SHA256 TLS13_AES_256_GCM_SHA384 It is the smaller keysize of AES 128 that requires the next refactor.