This is very interesting, thanks! I didn't think these 32-bit integer 
operations were practically on the table for WebGL, but this proves 
otherwise. I'm glad to see that it actually works. I've updated my 
article with links to these Shadertoy experiments.

Oh, duh, you're right! It seems so obvious now that you've spelled it 
out. I've added an update to my article about this. Thanks!

I did some reading of the RFC to catch up.

The change with .strip() doesn't account for the fact that Message-ID 
isn't a required field. If not present, this method will be called on 
None. It was already expected this might be None ("not msgid"), so this 
also isn't consistent with the existing code.

The In-Reply-To header may contain multiple Message IDs, and this 
possibility isn't considered. However, not a single email in my personal 
archives has more than one Message ID in In-Reply-To. Mutt supports 
crafting such messages, and I was able to do so in a test. Since it's so 
unusual and rare, and would be really confusing for threading (what 
happens if a message spans independent threads?), it's probably not 
worth considering.

I'm seeing quite a lot of oddball email today! Here's a similar 
situation:

https://lists.sr.ht/~skeeto/public-inbox/%3C87pnfb69f3.fsf%40bernat.ch%3E
https://lists.sr.ht/~skeeto/public-inbox/%3C87a76f4fro.fsf%40bernat.ch%3E

The Message-ID and In-Reply-To match up, but they're not threaded 
together. Looking closely at the headers, Vincent's In-Reply-To includes 
a parenthetical. In my personal email archives that only occurs 0.49% of 
the time (i.e. 49 messages in every 10,000), so it's pretty rare. 
Perhaps lists is treating this as part of the ID? (Maybe the RFC says it 
should?)

I tested Python's "email" package, and it definitely doesn't strip this

> BTW, I love the idea of using a public-inbox for comments.

Glad to hear it! I liked what I saw with Drew DeVault's public inbox and 
wanted one for myself. All these years I had essentially been treating 
Disqus as a mailing list, replying to all comments by email, but I was 
constantly frustrated that I couldn't do quoting, and at how it would 
mangle my responses if they were anything more complex than prose.

Inspired by Drew's public inbox, I've just started making use of a 
public inbox myself, so I'm still getting a feel for everything. I 
noticed these two messages aren't threaded together, and I'm curious as 
to the cause:

https://lists.sr.ht/~skeeto/public-inbox/%20%3CDM6PR09MB253761A38B42C713082A7CE2C60C0%40DM6PR09MB2537.namprd09.prod.outlook.com%3E
https://lists.sr.ht/~skeeto/public-inbox/%3C20200122160438.browlclypkwa6wg3%40nullprogram.com%3E

The Message-ID and In-Reply-To match up. I suspect this may be a bug 
based on what I'm seeing in the URL above. The Message-ID header has a 
space following the colon and spans two lines. It seems lists is keeping 
that space in front of the message ID. Note the %20 in the URL above.

Examining my personal email archives (~10k messages), this is the first

At least for me, cgo means giving up some of Go's biggest strengths. 
With the C dependency, cross-compilation and library management is just 
as troublesome as it would be with C. (Yes, I do both often in C.) I 
really like Go and enjoy programming in it, but C is still my personal 
favorite programming language. If I'm going to accept the worst parts of 
C, then I'd rather just do the project in C in the first place.

If you really want to avoid C, then I completely understand how cgo is a 
great tool for doing so.

I agree, those are definitely all downsides to vendoring. I don't think 
it's appropriate for, say, open source projects that are collaborated 
upon over the internet. Though it's a trade-off, and in certain other 
situations — offline development, offline builds, etc. — it's worth 
accepting those downsides. It was one of those situations where I 
learned about "go mod vendor".

In my article I was specifically highlighting the case where you *don't* 
check them into source control, just distribute them in your a release 
tarball, so it has none of the downsides except making the "standalone" 
release tarball bigger. Future archivists would probably love to find 
these kinds of releases.

Impressive work! I remember your email about this 3 years ago, and I'm 
happy to see you've followed through on your plans. This is such a slick 
solution to the Trusting Trust problem.

I've been observing Drew DeVault's public inbox for awhile now, and I 
really love this idea. So I've set one up for myself. This is where my 
own blog comments will be hosted going forward.