T -15 minutes

"Rust pretty blatantly just inherits the memory model for atomics from C++20. This is not due to this model being particularly excellent or easy to understand. Indeed, this model is quite complex and known to have several flaws. Rather, it is a pragmatic concession to the fact that everyone is pretty bad at modeling atomics. At very least, we can benefit from existing tooling and research around the C/C++ memory model. (You'll often see this model referred to as "C/C++11" or just "C11". C just copies the C++ memory model; and C++11 was the first version of the model but it has received some bugfixes since then.) "Trying to fully explain the model in this book is fairly hopeless. It's defined in terms of madness-inducing causality graphs that require a full book to properly understand in a practical way. If you want all the nitty-gritty details, you should check out the C++ specification. Still, we'll try to cover the basics and some of the problems Rust developers face."

Atomics - The Rustonomicon

The Dark Arts of Advanced and Unsafe Rust Programming

Inspiring! 🤢

I've noticed some interesting nostr behavior. I'll not post for a few days and get nothing in my inbox. Then I will post a top-level message and very soon thereafter I get something in my inbox. But suprise! it was not to the message I just posted, it was to some older message. But dated right now, so not an issue on my side. Anybody else notice this? Are there popular clients that don't raise reply messages of a person until they post a new top level post?

Chorus 2.0.0 is released. 2.0 doesn't mean big changes. It means you have to do a migration. #chorus

Nostr could do some of the things Alex says Bluesky does better: 1) We can create a new kind that replaces kind 1 which has spans (or facets) indicating bold, or url, or anything else. I wanted to do it that way since years ago when we had the '[0]' replacements (I thought it should just be a span in a tag with no placeholder in the content) 2) If we think a chain of events is needed to prove that none of your events were censored (so we can properly claim censorship resistance), we could add another kind where authors publish their chain of events as a list of IDs. If it needs some kind of mergeability to fix race conditions, I've talked about how to do that with a last-write-wins (LWW) conflict free replicated data type (CRDT) in

GitHub

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

View article →

Are people really this confused about a picture of Linus Torvalds with a microphone?

X (formerly Twitter)

jack (@jack) on X

Dogs are generally comfortable and relaxed off leash. Large dogs are also comfortable and relaxed on leash. But small dogs... not comfortable on leash! Because of that leash, they know that they cannot run away if a big aggressive dog comes at them. So they yip yip yip in panic and fear, always nervous, hoping all that barking will scare away any big dog that might come after them... even when there aren't any big dogs coming after them! I have a new nick name for such a dog in such a situation: A "European" dog.

Balaji seems pretty clued up. A bitcoiner I see. Is he here on nostr?

X (formerly Twitter)

Balaji (@balajis) on X

FROM MAGA TO CHINA Here are four things MAGA is getting wrong, and why it's handing over the world to China. (1) First, MAGA correctly understands...

I stand with Thomas Massie

I'm trying to solve a problem and I thought I'd ask for help. I've got a website using a WASM framework (dioxus) that gives me the ability to do async functions to fill in part of the web page. The web page renders immediately with either a placeholder or the result. I'm also using `nostr` and `nostr-sdk` from @Yuki Kishimoto On one page I have a long list of events each by potentially a different npub. But initially I don't have any of their metadata. I want that page to fetch and fill in the metadata for all these people. This is a very typical (I'd say necessary) part of any web-based nostr client. I haven't done it yet though, I've done a desktop client. The component on the page that renders the metadata is calling into this async function. Remember there are many of them, so many components are all nearly simultaneously calling into this async function, generally with different pubkeys but sometimes with the same pubkey. The async function needs to either return metadata, or eventually return a failure. A simple first idea that mostly works is to independently spin up a client and use it to two-step fetch the NIP-65 list from the discovery relay and then fetch the metadata from the user's relay. But this creates tons of clients and connections, saves nothing (no caching) and is generally regarded as a "bad idea." The next iteration on the idea is to store a map from URL to Client and keep the client's alive. Then I can fetch the client (creating if missing) and fire off a new REQ. But this is still bad because I'm doing one request per pubkey and relays hate me saying I'm making too many requests. So really I need to batch these somehow (multiple pubkeys per request). And to cache the results. And to be aware when some other thread is already doing this pubkey (and yet wait on it's result). And solving all of that simultaneously has been.... difficult. I can have a map with pubkey as the key. And I can have the value be an enum either Fetching or Metadata (and missing from the map means it is not fetching). But no easy way to async wait on a map entry to show up. Also no easy way to wait a bit and then batch the multiple requests and avoid all race conditions with other threads doing the exact same thing (although that I can solve). Anyhow, the whole thing seems rather difficult and yet it must be solved by ... every web based nostr client out there... right?