this is not altogether surprising, given an august 2023 filing in his market manipulation case that disclosed that the FBI had found CSAM while searching a cell phone of his in relation to his crypto theft
silver lining: it was awfully thoughtful of all these boston college administrations to draw the attention of a group of young, energetic, politically active students to last year's "tent ordinance" that cruelly targets the unhoused and is now being used to crack down on speech
interesting, Roger Stone deleted one of his tweets shilling a "MAGA Memecoin" after I pointed out that these tweets likely violate SEC rules
most of his other promo tweets remain, though, and have similar issues
took me a few attempts to say "bitcoin memecoins" in my newsletter voiceover without saying "beancoins", but I think I may be on to something here
oof to whoever paid the 10¢ PACER fee for this
Infra stack: from AWS to on-prem. AWS was becoming too costly, so Bluesky moved over to dedicated data centers and bare-metal machines.
Gergely Orosz and Elin Nilsson in The Pragmatic Engineer.
Bluesky is built by around 10 engineers, and has amassed 5 million users since publicly launching in February this year. A deep dive into novel design decisions, moving off AWS, and more.
So excited to hear that the Ghost blogging software is going to support federation via ActivityPub! https://activitypub.ghost.org/
If you sign up for updates, they have a survey where they're asking for feedback. Now's your chance to get your suggestions in!
Cool to see Ghost taking this step, while Substack is over there trying to build walls around their product to trap people in.
Ghost's post is also how I learned that Buttondown is working on ActivityPub support! 🙌 Exciting times.
it is such a delight to have my own microblogging space again, for random braindumps that don't belong in the newsletter
i missed it
Hosting Ozone behind nginx
Bluesky has released Ozone, a community moderation tool for the network. Although all Bluesky users get the default moderation out of the box, they can also subscribe to any of a number of user-created and run "labelers" (which you can see in this Bluesky list, or on this website).
Some of them label posts with content that could trigger various phobias, some label posts from Twitter, some label AI generated images, some hide spoilers, and some label... posts of beans. Others build an additional entire moderation layer on top of the defaults.
Honestly, I think it's a pretty cool approach to moderation.
So, of course, I wanted to try it out for myself. I've created a labeler to mark crypto spam: @cryptolabeler.w3igg.com. If you subscribe to the labeler, you'll see some blatant cryptospam posts marked with labels (or hidden, if you choose). You'll also see an option in the reporting screen to report posts to my labeler service:
The setup guide is pretty straightforward, but because it's so new, it doesn't have much detail about running Ozone with different infrastructure. Because I'm running the labeler service on a VPS I use for a few different things, and because I already have nginx running there, I didn't want to stand up Caddy alongside it. So, in case it's helpful to others, here's how I got Ozone running behind nginx:
Follow the HOSTING.md instructions, but skip the "Create the Caddyfile" step.
After copying the compose.yaml file, delete the entire caddy: block.
Configure nginx as a reverse proxy. Here's the relevant block in my configuration:
server {
server_name ozone.w3igg.com;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/ozone.w3igg.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/ozone.w3igg.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
# WebSocket support
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://127.0.0.1:3000;
}
}
Lines 4–8 are autogenerated by Certbot and shouldn't be added manually. If you want to use Certbot/Let's Encrypt for your SSL certificates, the command is: sudo certbot --nginx -d ozone.w3igg.com (obviously replacing ozone.w3igg.com with your own domain).
I got tripped up while setting this up because I didn't realize Ozone requires a websockets connection. Lines 17–19 should handle that, and Ozone has added some instructions to HOSTING.md to describe how to verify websocket connections are working. Note that if your domain is behind Cloudflare/Fastly/etc. this may require more wrangling.
Dan Luu benchmarked a bunch of different web platforms to illustrate the bloat that makes some of them completely unusable on lower-end mobile devices. His analysis was incredibly illuminating, and I thought his comments on CPU vs. bandwidth were interesting:
It's still the case that many users don't have broadband speeds, both inside and outside of the U.S. and that much of the modern web isn't usable for people with slow internet, but the exponential increase in bandwidth (Nielsen suggests this is 50% per year for high-end connections) has outpaced web bloat for typical sites, making this less of a problem than it was in 2017, although it's still a serious problem for people with poor connections. CPU performance for web apps hasn't scaled nearly as quickly as bandwidth so, while more of the web is becoming accessible to people with low-end connections, more of the web is becoming inaccessible to people with low-end devices even if they have high-end connections.
I also liked his callout on LCP, which fits well with some of my recent complaining about web animations:
As sites have optimized for LCP, it's not uncommon to have a large paint (update) that's completely useless to the user, with the actual content of the page appearing well after the LCP. In cases where that happens, I've used the timestamp when useful content appears, not the LCP as defined by when a large but useless update occurs.
He rightfully points out some of the issues with "Core Web Vitals", such as its omission of CPU time: "if a page has great numbers for all other metrics but uses a ton of CPU time, the page is not going to be usable on a slow device". Perhaps it ought to be added, given that it is considerably more challenging to teach to the test when it comes to CPU — that is, optimize for the metrics rather than make meaningful improvements to the end user experience.
This is also incredible:
While reviews note that you can run PUBG and other 3D games with decent performance on a Tecno Spark 8C, this doesn't mean that the device is fast enough to read posts on modern text-centric social media platforms or modern text-centric web forums. While 40fps is achievable in PUBG, we can easily see less than 0.4fps when scrolling on these sites.
I liked his notes about how attempts to optimize for slow devices through lazy-loading are often counterproductive:
Sites that use modern techniques like partially loading the page and then dynamically loading the rest of it, such as Discourse, Reddit, and Substack, tend to be less usable than the scores in the table indicate. Although, in principle, you could build such a site in a simple way that works well with cheap devices but, in practice sites that use dynamic loading tend to be complex enough that the sites are extremely janky on low-end devices. It's generally difficult or impossible to scroll a predictable distance, which means that users will sometimes accidentally trigger more loading by scrolling too far, causing the page to lock up. Many pages actually remove the parts of the page you scrolled past as you scroll; all such pages are essentially unusable. Other basic web features, like page search, also generally stop working. Pages with this kind of dynamic loading can't rely on the simple and fast ctrl/command+F search and have to build their own search.
Some other excellent points:
There are two attitudes on display here which I see in a lot of software folks. First, that CPU speed is infinite and one shouldn't worry about CPU optimization. And second, that gigantic speedups from hardware should be expected and the only reason hardware engineers wouldn't achieve them is due to spectacular incompetence, so the slow software should be blamed on hardware engineers, not software engineers. ... Another common attitude on display above is the idea that users who aren't wealthy don't matter. When asked if 100% of users are on iOS, the founder of Discourse says "The influential users who spend money tend to be, I’ll tell you that".
CPU performance for web apps hasn't scaled nearly as quickly as bandwidth so, while more of the web is becoming accessible to people with low-end connections, more of the web is becoming inaccessible to people with low-end devices even if they have high-end connections.