Self-driving cars are sorta not really all that tricky. Build out an infrastructure specifically for them, and we already have all of the technology to make them run safely and efficiently. The reason we don't already have widespread adoption of self-driving cars is that we don't have that infrastructure, and no one wants to build it. The real problem car companies are struggling with is designing self-driving cars that can navigate the existing infrastructure that's made for and used by people.

The current wave of AI hype demonstrates of the problem of capacity creep. In some measurable regards, hardware keeps getting better, right? More powerful, more efficient, more affordable. But rather than letting those gains ameliorate the problems created by tech, tech companies see them as increased capacity, and look to fill that capacity. So while hardware improvements should be reducing the emissions caused by computing, their growing as companies look for ways to turn capacity into profit.

The big problem that the current trend in "AI" is meant to solve is that of too much opportunity. The web opened up all sorts of creative spaces and jobs to anyone who could navigate the technology. But it's hard to build an effective elite when the same opportunities are available to everyone. You have to counteract that leveling effect by redirecting all of that creative power to a relatively small pool of comparatively privileged people capable of functioning as a virtual aristocracy.

"Reverse chron IS an algorithm."

Yes, but even more than that, we're all of us making our own custom algorithms by the way we arrange our accounts. The software and services we use provide us with particular tools for doing so. Reverse chron and follow are the basic underlying tools, but there's also block account, block domain, mute account, mute word, follow hashtag, mute replies from this account, and so on. Even choosing a host instance can be a means of shaping your algorithm.

Origami is Turing complete. https://www.quantamagazine.org/how-to-build-an-origami-computer-20240130/ #origami #computing

If Microsoft isn't your email provider, don't use Outlook. (Don't use it either way.) https://mailbox.org/en/post/warning-new-outlook-sends-passwords-mails-and-other-data-to-microsoft

"Great Andamanese, it turns out, is exceptional among the world's languages in its anthropocentrism. […] Because no other known language has a grammar based on the human body or shares cognates […] with Great Andamanese, the language constitutes its own family." https://www.scientificamerican.com/article/this-ancient-language-has-the-only-grammar-based-entirely-on-the-human-body/ #language #linguistics #India

Been daydreaming about a modular ActivityPub implementation. Each instance could decide which service types to offer, and each account could decide which to use. Accounts are held at the TLD level, services on subdomains.

So maybe foo.bar offers micro.foo.bar, photo.foo.bar and checkin.foo.bar. You have a foo.bar account, but only connect to micro.foo.bar and photo.foo.bar. And I only follow you on photo.foo.bar.

Don't know how feasible that is with AP.

These are my attempt at a few fast-and-sloppy diagrams illustrating how #Mastodon and #bluesky handle two kinds of message, both in the simplest scenario and in the more complicated conditions they'll both operate under when Bluesky goes into full production. Part of the point here is that the beta obscures some of the major differences between them. Seeing how Bluesky is intended to operate according to the spec makes it easier to assess its implication.

If you're attracted to Bluesky by the promise of account portability, then I think it's important to understand what that entails. Because one of the claims they're making is that you'll be able to rescue your account in the event that your home server suddenly closes. But how would that work? How do you migrate an account from a server that's no longer accessible? And part of the answer has to be: Well, you don't. Because it lives somewhere else. 🧵 1/?

Some interesting discussion here about using Mastodon to build server-specific funding programs for artists and writers: https://mstdn.social/@Jonathanglick/110181080905371639

The potentials being discussed are due in no small part to the fact that we're not all on one big server, and can more easily build communities of alignment by leaning on the soft borders created by decentralizing social media across multiple servers, each with their own identity.

Here's the latest Mastodon development roadmap: https://blog.joinmastodon.org/2021/12/roadmap/

Some interesting stuff in here, like reply controls, dynamic roles, and groups potentially replacing (or only supplementing?) the local timeline. Seems like some items have already been implemented in v4, though—like batch filter rules and post editing.

Make fun of John Mastodon all you want, but he gave an unflinching, nuanced performance in Goncharov (1973).

In the past, I've had accounts that crossposted to Twitter, but I've ultimately either disconnected the crossposting or let the accounts go defunct. And gradually I've come to the conclusion that crossposting undermines the goal of building a better social media ecosystem. It provides people with an excuse for staying on corporate social media and encourages them to see it as your responsibility to deliver your posts to them wherever they already have an account.

The threshold for discoverability on Mastodon is pretty high, so be generous about boosting other people. Sometimes you're the signal, and sometimes you're the path the signal takes through the noise.

When I start to doubt my decision to buy an e-reader: