Willow at large

New clearnet domain

Willow et al — Thu, 23 Jul 2026 02:54:14 GMT

So, besides ICANN wanting to phase out .su by 2030, it looks like Russia is getting stricter with their domains. Basically since I'm not Russian, just a vaguely communist person who thinks a Soviet Union domain is pretty cool, it would cost me twice the price to keep willow.su, and I wouldn't be able to transfer it either. Fortunately, willow.al (as in Albania) is cheap and it gels as "willow at large". Unfortunately it looks like registration is handled manually lol. Also there's no WHOIS server, which I didn't even know is allowed :O

I don't like this domain as much as my .su but I guess all good things must come to an end.

Username systems, ranked

Willow et al — Thu, 18 Jun 2026 05:42:21 GMT

When designing a platform with user-facing/public profiles, the way you go about handling usernames is important. Here I look at various systems for that.

Awful: un-namespaced usernames

This is what most sites use, including Discord and Twitter. Your username has to be a unique entry in a singular giant pool of usernames. These suck because there's a limited pool of usernames and so it's likely that your idea is already taken, leaving you to either choose a username you'd less prefer, or add punctuation to vary it. Discord actually gets a dishonorable mention here, because they used to use discriminators and then moved to this inferior username system.

Decent: Usernames with discriminators

Blizzard does this, and Discord originally took a page from their book. This is where you can pick whatever username you want, and the system adds numbers to the end of it to help prevent your username from being taken. For example, my Signal username is Willow.1312. This lets me have Willow even though that's a pretty common name. From what I've heard, Blizzard even adds digits if the base 10,000 are taken. And Signal puts between 2 and 9 digits after a username, which should make it extremely unlikely whatever username you want is taken. This approach is good for silos, ie platforms that have your data locked in to one server.

Good: namespaced usernames

This is what Bluesky and the fediverse do. In Bluesky, usernames are just domain names! That means the entire breadth of the DNS can be used for a username. So mine is @willow.su, but if I didn't have my own domain, I could use someone else's or a subdomain of the standard .bsky.social domain. This is just a DNS entry that refers to my ATProto DID, and my actual profile could be hosted anywhere (although Bluesky is basically a silo at the moment). It's not exactly the same on fedi, where instead of an arbitrary domain name, the domain name identifies the server, as in @Willow@translunar.academy. Here, translunar.academy is the server that hosts my profile.

It's less common for people to share their domain names than people opening their fedi instance registration, so I still prefer how fedi does it.

Unfortunately, though, you can only use ASCII characters in these usernames. Discord's old username system didn't have this limitation. I hope someday fedi and Bluesky won't either, using IDN.

A Case for Proprietary Software

Willow et al — Wed, 27 May 2026 02:21:51 GMT

I am a free software advocate, but I have limits. I can think of three reasons not to publish my own code or not to always use "free" licenses.

EDIT: This mostly only applies to server-side code, as that's most of what I've written. I don't have a strong opinion about this when it comes to compiled code, as I have no experience with it.

1. Opsec

Publishing your code can be a huge opsec risk. Maybe you have commits under an old handle. Maybe you have an oddly unique code style. Maybe you use an obscure programming language. Maybe you want to publish anonymously (via Tor or I2P). Or maybe you have a "contact me" page on your blog that you want to not publish the history of (ahem). Sometimes you can get away with publishing an archive of the code without the VCS (e.g. git) history, but other times merely publishing any amount of the code would be enough to dox you. This is especially true of server-side code, where any kind of code could have generated that same HTML or JSON response.

This doesn't just apply to you. If you release your code under the AGPLv3, everyone running your code will have to show their work too, meaning their opsec could be at risk too. For this reason, I used a permissive license for my upcoming comments system replacement, dsc.

2. Scraping

Scrapers are often highly dependent on the markup of the site they're scraping. Publishing your scraping code accelerates the cat and mouse game you're playing with the site you're scraping, making it harder to accomplish your goals with the software in the first place.

3. Disagreements about what licenses are free

I like the SSPL. I don't really plan to use it for my own code, as I find that the AGPLv3 is enough, but I'm not gonna fault anyone for using it. Why? I think it's not unreasonable to show your work for everything needed to run the software, including backup scripts. It might violate the OSI, sure, but I don't really care about the OSI anyway :) I still think it's an open source / free software license. Copy far left is cool, when it doesn't fall under the previous two reasons.

Types of post link trackers and how to avoid them

Willow et al — Sat, 18 Apr 2026 04:09:09 GMT

Sometimes when you share a link to a video, post, or photo, the link includes tracking details that reveal a shocking amount of data to the platform owner when your recipient opens the link, or even just when you share it, depending on where you share it. I came up with two different types of link trackers, and how to avoid them (usually). We'll look at those, and then look at what they reveal, to whom, and when.

Untracked links

"Untracked" links are the same for everyone. They just refer to the content itself, with no identifying details about the sender. Some examples of untracked links:

https://youtu.be/Ps-8QspaBug
https://www.tiktok.com/@ad_em_up/video/7623830159128333599
https://www.instagram.com/p/DXP8AYND-6b/

The ID of the content (Ps-8Q..., 762383..., DXP...) is the same for everyone, and it's harder for Google/TikTok/Meta (in this case) to track you or your recipient. This is what you want when sharing a link to a friend.

Opaque trackers

"Opaque" trackers, such as https://www.facebook.com/share/v/1AF.../ (link censored to protect the anonymity of my mom), just have one parameter that uniquely identifies the content, but it also identifies when and who shared the video. This is kind of a nightmare to handle because you have to identify yourself in order to unmask the link.

Transparent trackers

Here's an example of a link with a "transparent tracker": https://www.instagram.com/p/DXP8AYND-6b/?utm_source=ig_web_copy_link&igsh=NTc...

You can see the static post ID (DXP8...) as well as an ugly link tracker, utm_source, but more importantly igsh=Ntc... Fun fact, this parameter used to be called igshid, which they probably shortened because it was too immature lmao. Say it a few times fast sometime though.

Another example is https://youtu.be/Ps-8QspaBug?si=dsj... The si probably stands for "share ID" and is another example of a transparent link tracker.

What they reveal (in theory)

Platform owners can glean a lot of data from people that share links from their site.

Who shared it
Who they shared it to (be it via IP address or worse, if the recipient is signed in to the platform, what user account opened it)
When they shared it / when it was opened
What kind of device they shared it from and what kind of device it was opened on
What platform it was shared on, if that platform does link embedding

Link embed tracking

When you share a link on Discord, Twitter, or Signal, the link is fetched in order to extract a link preview, like this:

So now YouTube knows (in theory) that the video was shared on Signal. This is because Signal sends a unique User-Agent string to every site it fetches that identifies itself as a Signal client.

Signal is actually a little worse about this because it uses your IP address to fetch the embed, rather than some centralized proxy like it used to do. (That proxy was getting blocked.) Discord etc fetch the link using their centralized servers, but Google (in this case) still knows the link was shared on that platform.

How to avoid transparent trackers

Identify the component of the URL that stays the same for everyone. This is usually the first part of the URL, like the Ps-8QspaBug in https://youtu.be/Ps-8QspaBug?si=dsj.... Then remove the rest. Or try Firefox's "copy clean link" context menu item, although this is not foolproof.

You should also enable a filter list in your ad blocker. AdGuard includes a URL link tracking filter list, and so does uBlock Origin.

How to avoid opaque trackers

This is a little harder, and not always even possible. The best way, though, is to fetch the opaque link in a web browser, and see if it redirects to a transparent link. This at least works on TikTok, but I've also had some grief trying this technique on other sites, where I would either not get a new link, or it would try to get me to sign in constantly.

This is not a 24-hour clock

Willow et al — Fri, 17 Apr 2026 05:40:59 GMT

A 24-hour clock should cycle every 24 hours. Seems obvious right? But in a lot of apps, we get something like this:

This is basically two 12 hour clocks jammed together. It forces you to think in lowly 12-hour terms rather than thinking about what part of the entire day cycle you need.

It gets worse too:

This is Kvaesitso's "orbit" clock when you have the system set to 24h. It's basically just a 12 hour clock with a 24 hour face. The bigger planet still has a 12 hour orbit but it displays 0-23 instead of 12-12.

What should a 24 hour clock look like? Behold, one of the few things OnePlus did right in their buggy-ass OS:

0 is at the top, 12 is at the bottom, and it cycles once a day. Glorious.

Hello, world!

Willow et al — Thu, 16 Apr 2026 06:27:25 GMT

The site

In case you missed the footer, this is using Nikola. I wanted something lightweight and fast, so I was gonna go with Hugo, but I find Go's text/template rather annoying to work with. So I tried out Pelican briefly, but apparently it doesn't do incremental compilation very well, and that is important to me. Next I looked at Nikola and I quite like it! It does support incremental compilation (although it's kinda slow to start up, so that may not pay off for a while) and it uses Jinja which I quite adore <3

The comments

Getting comments on here was quite a journey. I wanted something that federated over ActivityPub, so I first tried Pinka but I couldn't get it to federate properly. So then I tried Leah's Mastodon-API fetching script along with GoToSocial and a read-only API key. Turns out there's a bug in that script which doesn't allow top level comments from other servers. At this point I was running out of options, so I ended up just going with Isso, which is an old Python project that just does local comments and nothing else. I really wanted federation though, but I figure this is even lower friction because it doesn't require an account.