I’m glad you enjoyed reading it. This was basically an invitation to brain-dump my thoughts from this past week, in light of Bluesky’s recent record user-counts, and also because I just finished reading the recently-published book Character Limit: How Elon Musk Destroyed Twitter, a multi-faceted chronicle of how and why it happened and who knew what and when. Check your local library if they already have it.

I also follow Mike Masnick on Mastodon via Bluesky bridging, and listen to his podcast on the topic of Trust & Safety. He’s also the one who coined the term Streisand Effect, which I think makes him fairly well qualified to write banger articles like Speedrunning The Moderation Curve, which are examples of unintended consequences running amok.

To start, let’s verify that Bluesky the app is indeed open-source. Yep, it is. But that’s not the same as having all the machinery be open-source, where anyone could spin up their own, compatible service; maybe named ExampleSky. To be compatible, ExampleSky would need to use the same backend interface – aka protocol – as Bluesky, which is known as ATProto. The equivalent (and older) protocol behind Mastodon and Lemmy is ActivityPub.

ATProto is ostensibly open-source, but some argue that it’s more akin to “source available” because only the Bluesky parent company makes changes or extensions to the protocol. Any alternative implementation would be playing a game of chase, for future versions of the protocol. History shows that this is a real risk.

On the flip side, Mike Masnick – founder of Techdirt, author of the 2019 paper advocating for “protocols, not platforms” that inspired Bluesky, and recently added member of the board of Bluesky, replacing Jack Dorsey – argues that the core ability to create a separate “Bluesky2” is where the strength of the protocol lays. My understanding is that this would act as a hedge to prevent Bluesky1 from becoming so undesirable that forking to Bluesky2 is more agreeable. To me, this is no different than a FOSS project (eg OpenOffice) being so disagreeable that all the devs and users fork the project and leave (eg LibreOffice).

But why a common protocol? As Masnick’s paper argues, and IMO in full agreement with what ActivityPub has been aiming towards for years, is that protocols allow for being platform-agnostic. Mastodon users are keenly aware that if they don’t like their home instance, they can switch. Sure, you’ll have to link to your new location, but it’s identical to changing email providers. In fact, email is one of the few protocol-agnostic systems in the Internet still in continued use. Imagine if somehow Gmail users couldn’t send mail to Outlook users. It’d be awful.

Necessarily, both ActivityPub and ATProto incorporate decentralization in their designs, but in different fashions. ActivityPub can be described as coarse decentralization, as every instance is a standalone island that can choose to – and usually does – federate with other instances. But at the moment, core features like registration, login, or rate limiting, or spam monitoring, are all per-instance. And as it stands, much of those involve a human, meaning that scaling is harder. But the ActivityPub design suggests that instances shouldn’t be large anyway, so perhaps that’s not too big an issue.

ATProto takes the fine-grained design approach where each feature is modular, and thus can be centralized, farmed out, or outright decentralized. Now, at this moment, that’s a design goal rather than reality, as ATProto has only existed for so many years. I think it’s correct to say for now that Bluesky is potentially decentralizable, in the coarse sense like how Mastodon and Lemmy are.

There are parts of the Bluesky platform – as in, the one the Bluesky organization runs – which definitely have humans involved, like the Trust and Safety team. Though compared to the total dismantlement of the Twitter T&S team and the resulting chaos, it may be refreshing to know that Bluesky has a functional team.

A long term goal for Bluesky is the “farming out” of things like blocklists or algorithms. That is to say, imagine if you wanted to automatically duplicate the blocks that your friend uses, because what she finds objectionable (eg Nazis) probably matches your own sensibilities, then you can. In fact, at this very moment, I’m informed that Bluesky users can subscribe to a List and implement a block against all members of the List. A List need not be just users, but can also include keywords, hashtags, or any other conceivable characteristic. Lists can also be user-curated, curated by crowd sourcing, or algorithmically generated. The latter is the long goal, not entirely implemented yet. Another example of curation is “Starter Packs”, a List of specific users grouped by some common interest, eg Lawsky (for lawyers). Unlike a blocklist which you’d want to be updated automatically, a Starter List is a one-time event to help fill your feed with interesting content, rather than algorithmic random garbage.

So what’s wrong with Bluesky then? It sounds quite nice so far. And I’m poised to agree, but there’s some history to unpack. In very recent news, Bluesky the organization received more venture capital money, which means it’s worth mentioning what their long term business plan is. In a lot of ways, the stated business plan matches what Discord has been doing: higher quality media uploads and customizations to one’s profile. The same statement immediately ruled out any sort of algorithmic upranking or “blue checks”; basically all the ails of modern Twitter. You might choose to take them at their word, or not. Personally, I see it as a race between: 1) ATProto and the Bluesky infra being fully decentralized to allow anyone to spin up ExampleSky, and 2) a potential future enshittification of Bluesky in service of the venture capitalists wanting some ROI.

If scenario 1 happens first, then everyone wins, as bridging between ActivityPub and ATProto would make leaps and bounds, and anyone who wants their own ATProto instance can do so, choosing whether they want to rely on Bluesky for any/all features or none at all. Composability of features is something that ATProto can meaningfully contribute to the protocol space, as it’s a tough nut to crack. Imagine running your own ATProto instance but still falling back on the T&S team at Bluesky, or leveraging their spam filters.

But if scenario 2 happen first, then we basically have a Twitter2 cesspool. And users will once again have to jump ship. I’m cautiously hopeful that the smart cookies at Bluesky can avoid this fate. I don’t personally use Bluesky, being perfectly comfortable in the Fediverse. But I can’t deny that for a non-tech oriented audience, Bluesky is probably what I’d recommend, and to opt-in to bridging with the Fediverse. Supposed episodes of “hyping” don’t really ring true to me, but like I said, I’m not currently an invested user of Bluesky.

What I do want to see is the end result of Masnick’s paper, where the Internet hews closer to its roots where interoperability was the paramount goal, and the walled gardens of yore waste away. If ATProto and ActivityPub both find their place in the future, then IMO, it’ll be no different than IMAP vs POP3.

Pew Research has survey data germane to this question. As it stands, a clear majority (79%) of opposite-sex married women changed their family/last name to their husband’s.

But for never-married women, only a third (33%) said they would change their name to their spouse’s family name. 24% of never-married women were unsure whether they would or wouldn’t change their name upon marriage.

From this data, I would conclude that while the trend of taking the husband’s last name is fairly entrenched right now, the public’s attitude are changing and we might expect the popularity of this to diminish over time. The detailed breakdown by demographic shows that the practice was less common (73%) in the 18-49 age group than in the 50+ age group (85%).

However, some caveats: the survey questions did not inquire into whether the never-married women intended on ever getting married; it simply asked “if you were to get married…”. So if marriage as a form of cohabitation becomes less popular in the future, then the change-your-family-name trend could be in sharper decline than this data would suggest.

Alternatively, the data could reflect differences between married and never-married women. Perhaps never-married women – by virtue of not being married yet – answered “would not change name” because they did not yet know what their future spouse’s name is. No option for “it depends on his name” was offered by the survey. Never-married women may also more-strongly consider the paperwork burden – USA specific – for changing one’s name.

So does this help answer your question? Eh, only somewhat. Younger age and left-leaning seem to be factors, but that’s a far cry from cause-and-effect. Given how gradual the trend is changing, it’s more likely that the practice is mostly cultural. If so, then the answer to “why is cultural practice XYZ a thing?” is always “because it is”.

For anyone looking at Keygen Church, also see their adjacent project, Master Boot Record for computer metal.

I’m not a water or energy expert, but I have occasionally paid attention to the California ISO’s insightful – while perhaps somewhat dry – blog. This is the grid operator that coined the term “duck curve” to describe the abundance of solar energy available on the grid during the daylight hours, above what energy is being demanded during those hours.

So yes, there is indeed an abundance of solar power during the daytime, for much of the year in California. But the question then moves to: where is this power available?

For reference, the California ISO manages the state-wide grid, but not all of California is tied to the grid. Some regions like the Sacramento and Los Angeles areas have their own systems which are tied in, but those interconnections are not sufficient to import all the necessary electricity into those regions; local generation is still required.

To access the bulk of this abundant power would likely require high-voltage transmission lines, which PG&E (the state’s largest generator and transmission operator) operates, as well as some other lines owned by other entities. By and large, building a new line is a 10+ year endeavor, but plenty of these lines meet up at strategic locations around the state, especially near major energy markets (SF Bay, LA, San Diego) and major energy consumers (San Joaquin River Delta pumping station, the pumping station near the Grapevine south of Bakersfield).

But water desalination isn’t just a regular energy consumer. A desalination plant requires access to salt water and to a freshwater river or basin to discharge. That drastically limits options to coastal locations, or long-distance piping of salt water to the plant.

The latter is difficult because of the corrosion that salt water causes; it would be nearly unsustainable to maintain a pipe for distances beyond maybe 100 km, and that’s pushing it. The coastal option would require land – which is expensive – and has implications for just being near the sea. But setting aside the regulatory/zoning issues, we still have another problem: how to pump water upstream.

Necessarily, the sea is where freshwater rivers drain to. So a desalination plant by the ocean would have to send freshwater back up stream. This would increase the energy costs from exorbitant to astronomical, and at that point, we could have found a different use for the excess solar, like storing it in hydrogen or batteries for later consumption.

But as a last thought experiment, suppose we put the plant right in the middle of the San Joaquin River Delta, where the SF Bay’s salt water meets the Sacramento River’s freshwater. This area is already water-depreased, due to diversions of water to agriculture, leading to the endangerment of federally protected species. Pumping freshwater into here could raise the supply, but that water might be too clean: marine life requires the right mix of water to minerals, and desalinated water doesn’t tend to have the latter.

So it would still be a bad option there, even though power, salt water, and freshwater access are present. Anywhere else in the state is missing at least one of those three criteria.