shreyan

Why 6-7 is the best meme

Mon, 02 Feb 2026 15:46:12 -0800

I’m sure my audience for this blog is familiar with the concept of memetics. If not, the basic premise is the idea that there are little bits of information that spread from person to person by observation and imitation. We call these little bits of information “memes” and they’re a lot like viruses.

As Wikipedia, the bastion of human knowledge and an absolutely incredible memetic feat, says, “A meme acts as a unit for carrying cultural ideas, symbols, or practices, that can be transmitted from one mind to another through writing, speech, gestures, rituals, or other imitable phenomena with a mimicked theme”. This is a pretty cool idea. Internet memes - those little funny copypasta phrases and images - get their name from this memetic concept.

The thing is, most memes have some kind of meaning behind them. In general, the reason a copypasta is funny is because the textual content makes you laugh. A silly image or gif is funny because it has some kind of humor in it, usually. That’s what gives them their virality. Nobody will spread an informational virus (yes I read Snow Crash recently, how can you tell?) that has no meaning. They need a way to infect people, and humor in order to be spread.

Or do they?

The genius of 6-7

Imagine a meme with no content - the purest informational virus possible. One that spreads itself and gains its infection vector purely by being a meme. The humor of this meme would be its own being a meme.

I’m sure you know what meme I’m talking about. I’m talking, of course, about 6-7.

Look, I’m sure there are other pure memes. But 6-7 is the most recent and most viral example. It’s gained its virality with no real reason other than its being a meme. Why is 6-7 funny? I know it has an origin in some guy’s song, but I’ve never heard the song, and I still find it funny. Something about its funniness has become embedded into our information environment and propagated its infection without preserving its original meaning at all.

I think that’s pretty cool. Don’t you?

A Bite of the Forbidden Fruit

Thu, 01 Jan 2026 12:54:36 -0800

Where did we leave off last time? In talking about macOS, we discovered many different little things signifying a wider rot. Through that exploration, a few consistent themes emerged.

Some of these themes were: don’t mix metaphors, articulate clear directions, and prioritize the human above all. We’ve seen individual symptoms. Time to make it more concrete.

Slowly then suddenly, macOS is facing its total destruction: its absorption into a homogenous & anti-human Apple “ecosystem” it’s alien to. For years now people have feared that Apple will go as far as to merge macOS and iOS, or at least to take us part of the way there through “convergence”; these fears have not yet come true. Many may be inclined to take macOS Tahoe as yet another harbinger of this fate; I see it differently. The truth is that Apple doesn’t have a direction for macOS; they don’t know who it’s for.

First let’s talk about that other fear.

Convergence

For a few years in the early 2010’s, there was a lot of craze around the idea of “convergence”; with the advent of multi-touch-based smartphones and tablets which housed full-fledged computers, people got quite hyped about bringing its innovations back to the personal computer. Take it a step even further and people got quite excited about the idea of one unified experience across all your devices; from the 5-inch screen in your pocket to the 34-inch monitor on your desk, anything and everything would converge.

Convergence is a nice idea, in theory. Imagine the prospect of having the same set of notes, messages, emails, documents, and photos available in the same interface, present on every single one of your devices; not only that, imagine they could even all be the same device! Connect the phone in your pocket to a monitor, keyboard, and mouse, and watch it become a full-fledged desktop.

Sounds beautiful. I’m fairly open to the idea of convergence, if executed well. However, it’s really, really hard to get convergence right. The trouble any attempt at convergence faces is the massive disparity between touch-based and pointer-and-keyboard-based interfaces, not only in methods of input and output but in their entire philosophies and paradigms.

We looked at this a lot last time in our examination of macOS; some recurring themes were the traditionally file-and-folder-centric, document-oriented model of the desktop PC being juxtaposed with the app-centric model of smartphones, and the tension between paradigms arising from these attempts to mix them.

Keep that in mind as we continue. Past attempts at convergence have felt unnatural simply because they have been — our expectations are broken by interfaces that, for example, use a long-press as a means for right-clicking, because while we expect that from a mobile device, we don’t from our desktop computers.

Past attempts at convergence learned these things the hard way: implementation followed by mass rejection. Perhaps the most famous attempt at convergence is Microsoft’s Universal Windows Platform; its arrival on desktop Windows with Windows 8 made the tension between paradigms impossible to miss.

The traditional desktop and the new “Metro-style” apps basically didn’t interact with each other at all. Metro apps always opened in full-screen, as if designed for a tablet, and the desktop, housing all your, you know, windows, became just one more of these full-screen experiences alongside the Metro apps. It was a deeply awkward experience; these UWP apps were also totally crippled in a way that users of desktop software didn’t appreciate. The kind of restrictions placed on UWPs are pretty much akin to those Apple imposes on iOS apps.

Even the most ardent fans of Metro, Windows 8, and UWP will admit just how awkwardly the two metaphors coexisted; even with Windows 10 bringing Metro apps back into the traditional desktop, UWP and the traditional Win32 still feel miles apart. As much as Microsoft needed to modernize their platform, UWP has been a flop.

Of course, Microsoft’s attempt at convergence was far from the only one. Other examples include Ubuntu Touch, Samsung DeX, and ChromeOS’s Android app capability. All of these attempts have felt just as awkward.

When the iPad was released, there was a lot of curiosity, even apprehension, around the direction of the next version of Mac OS X. For many, it seemed clear that Apple, too, would take the road of convergence; a unified platform emerging from the combined forces of iOS and Mac OS X, reuinited sisters.

Apple did indeed take a bite at bringing innovations from iOS to the Mac; it just did it a little differently.

Lion

Before going any further, I’d recommend reading John Siracusa’s Ars Technica review of Mac OS X 10.7 Lion. It’s a long but satisfying read; if you can’t be bothered to get through the whole thing, at least get yourself through “Reconsidering Fundamentals” to contextualize what’s coming up.

For those fearing iPadification, Lion certainly did not spare them the worry. Additions like trackpad gestures, Launchpad, and full-screen apps screamed iPad. Those fears weren’t unreasonable. Such changes were indeed scary; the mental models Apple asked Mac users to embrace were novel to desktop users despite their newfound ubiquity on mobile.

Those fears have persisted ever since, and each new release of macOS inches us ever closer to the day of their realization; however, Lion would not be that day. Lion borrowed from iOS, and yet, its goal really was to try to make the Mac better and easier. Crucially, Apple resisted blind imitation. Instead, they spotted the genuine usability enhancements that could be borrowed from iOS and used those to guide the Mac towards a unique vision for the future.

This vision of the future was an experiment, sure. Experiments always attract controversy. Changes would have both lovers and haters. There’d be resistance and adjustments would need to be made. This is standard; every big shift requires these things.

The thing is, Lion didn’t try to erase the Mac. It tried to bring it forward to stand proud alongside iOS. It brought multitouch gestures to the Mac world, but optimized them for trackpads rather than touchscreens, making them fit in to their new home despite their iOS origins. Launchpad became a genuine usability enhancement to novices; keep that in mind, because Launchpad will get a closer look later. As mentioned last time, Mission Control improved Mac window management by elegantly combining Exposé and Spaces into one interface; combined with multitouch gestures, Mission Control has become a sensible and intuitive solution for Mac multitasking.

One of our themes last time was the inherent risk in the mixing of conventions from different paradigms. This will be one of many recurring themes as this series progresses, and we’ll get pretty deep into it. Knowing that, Lion’s path looks risky; however, what it did best well was to take the ideas from iOS and adapt them to the Mac’s conventions and paradigms rather than simply shoehorn the iOS paradigms in.

One of Apple’s greatest usability enhancements in OS X Lion was its overhaul of the document model. You’ve probably guessed by now that documents are going to become a recurring character in this story; knowing that, it’s time to take a brief detour and talk about the macOS document model.

NSDocument

Last time, we talked about the original Mac philosophy of document-centrism over app-centrism, as a goal if not as a reality. Apple, of course, tried to reach these goals through experiments like OpenDoc; ultimately, that particular road was shuttered with Steve Jobs’ return.

Mac OS X, however, had its own document-centric tricks up its sleeve; NeXTSTEP’s NSDocument made its way into the new operating system, giving birth to an entire new generation of document-based Mac apps.

When you create a Mac application in Xcode, you can create it as a “document-based” application. Across various Mac applications, you’re probably used to a lot of niceties that are shared between them in terms of how they deal with files — for example, the titlebar being right-clickable to get a path menu, or the proxy icon you can drag around to move the file or reference it. It’s very convenient. That’s NSDocument working right there. It also provides niceties like the cool zooming animation when you open a file from Finder or close it, and prevents you from opening files twice by accident, etc, etc — overall it just creates a nice, coherent document model shared across Mac applications that work with files.

The app I’m using right now to write this post, Paper, is a great example of an NSDocument app. It’s great. I really appreciate this file-centric model of working. It lets me organize things by what they are related to rather than which app created them.

Of course, NSDocument is no OpenDoc; it doesn’t provide mix-and-matchable cross-application components, but it does make the applications using it feel part of a coherent Mac document model, and provide a lot of conveniences for the users of those applications. Suffice it to say that if my files are going to need individual applications to work with them, I’d rather have them be part of this nice, coherent document model.

In Mac OS X Lion, Apple took a look at the document model and decided it could use some revision. iOS had innovated in this regard with its apps like Notes using a document model that completely hid its internal files from the user, and included a lot of conveniences like autosaving, revision history, etc. Apple correctly concluded that simply imposing this totally different model on Mac OS X wouldn’t work; they instead looked at the parts of it that were true innovations Mac users would appreciate — ideas like autosave and version history — and made them parts of the Lion document model. NSDocument apps, with a little work, became part of this beautiful vision of the future.

Apple’s vision here did not do away with the document at all. It didn’t intentionally subjugate your work to the context of the application the way they would later. It simply tried to take the innovations from iOS that could actually improved how Mac users worked with their documents, and made them part of the Mac document model. And they’re good features! They work well and have become a standard part of the Mac experience. I take them for granted. Apps like my beloved Paper automatically save all my changes and keep track of different versions, and between different Mac apps, the UI for all these features remains the same.

Genuinely, please read the Siracusa Lion review. It goes very in-depth and is quite compelling. It’s really good.

So that’s Lion’s wise approach to convergence. A vision that doesn’t at all center around simply merging the desktop and mobile into one experience, but rather taking the best innovations from mobile and bringing them to the desktop without breaking its fundamental metaphors. If there’s one pattern you’ll notice with all the Lion changes, it’s that they don’t mess with the fundamental metaphors desktop users are used to.

Lion is emphatically not Apple’s original sin. It borrows from iOS, yes; but it shows no desire to subsume macOS and turn it into a simple extension of Apple’s mobile platform. That would come later. We’ll sketch out how we got there slowly.

Now, we’ve looked at document models again. It’s gonna be a recurring theme so I hope you payed attention. Next, of course, is iPads, again. If Lion proved Apple still understood what a computer was for, the iPad will prove they’ve forgotten.

The Sin

Last time I said iPads are general-purpose computers that don’t allow their users to perform general-purpose computation. What, exactly, should a computer be, and what should a computer do? These are important questions, especially when considering that Apple has been trying to position the iPad as being able to replace your computer for a while now. It offers a simplified world, awesome hardware, less worrying, a cool, fluid touchscreen interface, and nowadays, keyboard, trackpad, and stylus input. When it comes to input methods, the touchscreen and Apple Pencil add two things which Apple simply refuses to add to the Mac. These are capable devices! They’re great!

Apple really wants to position them as a computer. But that’s a sin; they leave it crippled in such a way that they can never really serve as a computer. And for that, I’m going to turn it over to my friend Roscoe who has already written a brilliant essay on this subject: What’s a computer?

It’s good and hits at the tension quite well. It correctly identifies the nature of Apple’s control over the iPad software and user experience. But is security really Apple’s motivation here? No; it’s a much greater sin than that. There are tastes that once tasted are too delightful to give up. And Apple has had a taste of something just like that.

Short of something truly radical happening, the iPad is forever trapped in this world of being positioned as a computer that can’t compute. And this is insidious and harmful; it slowly shifts control of computers away from the humans actually using them to the powerful corporations controlling software distribution.

What cripples iPads is not even the lack of Mac-like multitasking. Roscoe correctly notes that despite iPadOS 26 bringing these features to the iPad, it’s still a fundamentally crippled device. Try to write any code on an iPad, to name one creative task, and you’ll find yourself at a complete loss. It’s a model that deprioritizes this kind of creation; it becomes a secret knowledge that you’re not really supposed to have.

iPads hide core functionality away from you and expect you to live within their world — a veneer used to placate the “consumer” without exposing the true complexity underneath at all. I won’t spend too much time covering this since chances are you already know exactly what I’m talking about. The hidden filesystem, the lack of system extensibility, the inability to run any sort of executable not approved by Apple’s monopolistic App Store; you get the idea. Now, Apple will of course claim this is simplicity for your own protection — who wants users messing up their own devices or, worse still, malware running rampant? I would contend that there are ways to technologically limit the risk of these harms without seizing control away from users — i.e. capability-based security — but we don’t need to get into details; the point is that Apple’s restriction of your access to the internal complexity is a conscious choice not driven by outside constraints.

Companies like Apple, Google, and Microsoft frame this as an attempt to shield their users from complexity. The reality is that complexity isn’t something users need to be shielded from like this; rather, access to the full functionality of a system they own grants users power. The power to modify the computer to whatever usecase is needed — you know, the basic promise of a general-purpose personal computer — is what’s locked away when you don’t have access to that functionality. This is incredibly harmful because it locks the users of these products into the role of passive consumers. And that, of course, ends up being good for the profits of certain large tech companies due to the nature of the attention economy. And money from things like in-app purchases all flows back to the king of the App Store — Apple.

It’s all power and control for a few capitalists. A great sin! And an addictive one, once you’re hooked on it. What other power can Apple and its buddies consolidate by continuing to trap you in the cycle of consumption? A lack of any agency will naturally lead to the conditioning of users to not be able to use any agency they do have; that increases the need for — and thus the power of — the big tech companies actually controlling the products you nominally own.

Apple has embraced this model of computation completely and apparently now believes it to be a good thing. We’ll strike at the heart of this disease soon, but first let’s understand the symptoms of that embrace.

The Vision

In 2023, Apple announced the Vision Pro — framing it not as a “VR headset”, but rather as a “spatial computer”. They boldly claim on the Vision Pro’s landing page that “The era of spatial computing is here”.

I guess we should figure out what they expect this era to look like. Surely the natural thing to do for personal computing into these new horizons would be to take an existing computing environment and “spatial”-ize it; imagine a Mac, but in a 3D environment! When I think “spatial computer”, what comes to mind is our existing computing environments — with all the freedoms of access to filesystems, running your own executables, and, you know, not being siloed off into a fake “simplicity” — with all the supposed new benefits of having access to this third dimension.

Now, I don’t actually know what all these supposed new benefits are; I don’t know what’s so special about spatial, primarily because it doesn’t have much to do with how I personally use my computer. But ignoring that, let’s assume it does add something, and that on the whole, it’s a net positive to add spatial capabilities to a computer, in terms of power the user has access to. Okay, a cool product! Maybe spatial computing is the natural next step in where personal computing is headed.

That’s how it should go; but, of course, instead, the Vision Pro is a glorified iPad strapped to your face. This is concerning, because it means Apple’s vision ( wink ) for this supposed next era of “spatial computing” is one in which users have less power than our current era. It’s a transposition of the weakened, powerless model of consumption-centric devices like phones, tablets, TVs, smartwatches, etc etc etc, onto the existing world of the personal computer, a safe haven of freedom and power.

If Apple so clearly thinks that the future of computing will be so consumption-centric that they’ll declare the “era of spatial computing” will replace our existing computing era, while also making that new spatial computing era so consumption-centric, then what’s next for the one remaining powerful personal computing platform in Apple’s lineup?

Anyone hoping the Mac will remain a safe haven will be sorely disappointed.

I promise I am trying to keep this essay focused, so I think it’s time to talk about macOS 26 Tahoe itself.

Tahoe

First things first, we need to cover some well-trod-on ground. After WWDC ’25, every major source of commentary noted two themes in Apple’s updates to each of their platforms.   Tahoe, and its companion operating systems, represented a rapid acceleration of existing trends within the Apple ecosystem. Notably, Apple moved all its operating systems to a shared, year-based versioning scheme; together, all its platforms are now unified under version number 26. The other major change was in the design language; for the first time, platforms with previously disparate if similar design languages were unified under Liquid Glass.

For further evidence of Apple’s goals here, one need only look at the other changes announced at WWDC ’25. As discussed above, Apple brought more of a Mac-like veneer to the iPad, further drawing the two together; and the one new app introduced to macOS, Journal, was another direct port from iPadOS. The one major API announced was the Foundation Models Framework, simultaneously coming to all Apple OSes.

So, with WWDC ’25, Apple aimed to consolidate many pieces of its operating system; but to what end?

Liquid Glass

Apple’s unification of its platforms’ design languages has an obvious intent behind it, the same intent as that behind the version numbering shift. If all platforms share the same design language, then apps developed for one platform could look and behave roughly the same when ported to others!

Last post, I talked a lot about Catalyst and the invasion of foreign platform norms onto macOS. Those norms wouldn’t be so foreign anymore if they were shared across all platforms, would they? One could even envision — perhaps if all those platforms shared versioning schemes and APIs — that perhaps it’s not even a set of norms shared across different platforms but rather a platform in itself.

Before diving further into this theme, I will give you my brief, qualitative assessment of Liquid Glass, the design language, itself. While in general I’m inclined to like skeuomorphism, I think Liquid Glass badly misapplies it. To me, skeuomorphism is only useful when it actually mimics the behavior of something analogous in the real world.

So why glass? We don’t exactly have Control Centers and menus made of liquidy glass in the real world — so what is this skeuomorphism for? To look pretty? That is far too subjective of a criterion to base a design language that people will actually have to use on. I don’t even think it looks that pretty! To a good amount of people, the eye candy of transparency, refraction, and glossiness is actually distracting and even illegible. Stuff like floating sidebars — and imaginary content behind them — does nothing but add more confusion and clutter to the interface.

Liquid Glass on the Mac, in particular, also simply feels like an imitation of its iOS counterpart without even including any of the cool stuff like menus collapsing into buttons and whatnot. It’s a purely visual refresh to make it look more like iOS that serves no other discernible purpose.

Journal

I don’t have a lot more to say about Tahoe specifically, but I do think it’s worth noting the other major user-facing addition because it highlights many of the same trends.

The Journal app that now comes preinstalled with macOS Tahoe comes directly from the iPad and looks, works, and feels pretty much the same. This is an app that, in theory, should be encouraging reflection and creativity, right?

In practice, it’s another siloed app which encourages you to lock your thoughts within its confines, somewhere in some magical hidden database, with the option of syncing through Apple’s controlled iCloud service. Journal is just a continuation of the same trend of Apple bringing iOS-paradigm apps into the Mac world and encouraging you to lock yourself into siloes.

The Apple that thoughtfully brought innovations from iOS to the Mac document model is gone. NSDocument is nowhere to be seen in the paradigm Apple now encourages; instead, hidden, iCloud-backed databases are the norm for any app which isn’t solely for consumption.

macOS, in this world, becomes simply another deployment target for Apple apps. And that leads us to Apple’s real goal.

The Apple Platform

If there’s one trend among all of the things we’ve discussed so far, it’s direction. macOS increasingly lacks an independent direction; Apple doesn’t know who it’s for or what it’s meant to be. Without much of an independent role of its own, it simply follows the direction of whichever other platform Apple has decided to give its focus to at any point. Spoiler: it’s usually iOS.

Is Apple simply planning to merge macOS with iPadOS? Do all these signs point towards convergence? I don’t think so. Rather, I think Apple is trying to create a platform identity independent of any single operating system — a platform identity that, under the veneer of empowering creatives, really subordinates everything to a paradigm of siloed, consumption-focused apps.

What is the common thread between shared version numbers, Liquid Glass, and cross-platform apps? They all homogenize Apple’s various operating systems while preserving their nominal independence; after all, tvOS is still for TVs, iPadOS for iPads, and macOS for Macs. But they can all run the same apps, namely, the ones developed for iOS, and they will look mostly similar on all of these operating systems thanks to a shared design language. And they even all have the same version number!

It’s almost like there’s a single Apple Platform — an abstract target to which apps centered not around autonomy but around control can be deployed, and each kind of device, be it Mac, Vision Pro, iPad, TV, Watch, iPhone, or any other — is simply a window into that vast world of consumption.

Your computer is just a passive kiosk into their world. There is no utopian vision of convergence here. Just further removal from the actual creation and manipulation of software and media.

The Vision Pro, in Apple’s mind, is the computing paradigm of the future — centered around software distributed through their centralized app store that stores all information in its siloed world.

And that’s Apple’s real face — a business centered around turning its various devices into kiosks of passivity all peering into the same manufactured world.

Apple, we see your real face and it’s ugly as sin. It’s time to put you in your place, cause you’re rotten within.

Rotten Apple

I don’t think you’re ready for the takedown.

(okay, okay, i’m sorry for being cringe. it will happen again.)

After experimenting with various innovations in Lion — trying to craft a cohesive direction for the Mac and its future — how has Apple ended up here? What is the source of this pervasive rot that threatens to consume the whole fruit?

Some would attribute it to the death of Steve Jobs. I think that’s oversimplifying things and slips too much into the realm of deifying him without looking at larger factors.

In my opinion, the greatest factor in this shift is the rise of the iPhone. Never before had Apple ever controlled a market and had power over it the way they have with the iPhone; Macs always used to be tiny players amidst a Windows world, and thus Apple had to really maintain a sense of loyalty through carefully building a community.

That community centered around an ethos of enabling creativity and art. Macs and their software were beautifully crafted, document-based tools to allow people to create things that were impossible before widespread personal computing.

The iPhone emphasized a different modality. It’s a lot easier to consume than create on an iPhone, giving a rise to its nature as a celestial jukebox — a viewport into pre-prepared software and media meant to be consumed, not created. Now Apple has seen how profitable that is — cuts on subscriptions like Netflix and Spotify when purchased through their App Store, and sale of their own media-consumption subscriptions like TV+, naturally have them seeking to expand this paradigm to encompass their whole ecosystem.

Onwards

This is a pretty bleak moment for technology and society. The walls are closing in around us with every passing day. Not only is passivity the norm in the Apple ecosystem, but other ecosystems, like Android, continue to impose new restrictions on software installation. Centralized social media is controlled by the likes of Elon Musk and Mark Zuckerberg. Encrypted apps like Signal face attacks from governments worldwide. Generative AI continues to reduce opportunities for creatives (I feel like I have a pretty nuanced position on this one I’ll expand on at some point, but the reality right now is kind of bleak).

Things don’t look great, needless to say. But I don’t think doom and gloom is a productive outlook. By looking to the past and present, we can build on existing efforts to reach something better.

Now that I’ve got doomerism out of my system, I hope with the coming new year I can outline more perspectives and pathways to improve this situation. Like everything else, these efforts are, and must continue to be, a work in progress.

A Quick Look at macOS

Mon, 20 Oct 2025 10:36:45 -0800

This post exists because of macOS Tahoe. I’m rather irritated by the new release. This blog is trending towards becoming a place I dump complaints about the direction of current technology. I suppose if I’m going to seem like a grump, I might as well embrace it.

From my perspective, macOS Tahoe continues a trend in recent macOS releases of more-or-less just making the OS worse and harder to use.

I was going to just complain about macOS Tahoe in this post. As I was writing the introduction, I realized I was over 6000 words in and still hadn’t gotten to macOS Tahoe yet. This was not ideal, so I’ve decided to turn this into a series instead. This is the first part. The topic of macOS Tahoe specifically was also too restrictive, so the topic area has been widened. You’ll see what I mean.

I’ll explore a lot of different ideas… but I think it’s best to start with a Quick Look (sorry) at macOS, cause that’s a juicy topic that provides a Launchpad (sorry, again) into many more interesting roads.

So, I’ve mentioned that I’m annoyed by recent macOS releases in general. If I find recent macOS so irritating, why do I use it in the first place? Well, let’s talk about that.

Why macOS?

It’s a good question. After all, Linux and Windows are right there. Heck, even ChromeOS exists.

The truth is, I’m a Mac user, but one without any particular love of Apple. I use an Android phone, and I don’t use any of Apple’s cloud services. I use macOS because of desktop computer operating systems, it’s basically the only usable one.

This brings me no joy. I wish Linux was usable. I don’t want to have to use a proprietary operating system which is continuously moving in a direction I hate. But it has some things going for it that Linux and Windows simply do not.

The biggest one of these things is consistency. For me, it’s very important that things work the same way across the computer. I don’t want to have to relearn the way I use my computer every time I open a different app. macOS has a very strong personality that the vast majority of apps written for it do actually adhere to. For example, even most cross-platform apps will use the macOS menu bar instead of putting one in their windows, and the commands available from each menu are very consistent across applications. Also, the menu bar being at the top of the screen is just good.

Ideologically, I’d love to be a Linux user. I love open-source. The trouble with Linux is that, sure, it’s Unix, but at the end of the day, it’s just way too much of a patchwork of different technologies to feel very cohesive. Apple is not wrong that their extremely tight integration across all the layers of their platform makes for a very good user experience. Also, I just like the technologies used in macOS better than the ones used on the Linux desktop. Irritatingly, there is no Linux platform but rather a bunch of competing platforms that are somewhat-but-not-totally compatible with each other that all run on top of something called Linux. KDE and GNOME, as much as Linux proponents will say they’re interchangeable, produce applications that look and feel very out of place on each other’s desktops. They behave so differently that intuition developed for one becomes functionally useless in another. It’s basically unusable unless you like to spend more time wrangling the computer than using it. To get a semblance of a consistent desktop, you have to work to configure it, and at the end of the day, it won’t really work the way I want a desktop to anyways.

macOS won’t either! There are always certain options I have to configure on macOS to make it usable, but it’s a lot more tolerable since they’re pretty much always the same options. And that usability is not even close to how I want a computer to work, but it’s still a lot closer to it than anything even the most fine-tuned Linux desktop has ever been. At least, even if it won’t work the way I want it to, once I’ve learned what to expect from it, most things will stay consistent to those expectations. Also, there are really good Mac apps that make the platform feel like a platform.

I haven’t even talked about Windows, but suffice it to say that somehow it’s almost as inconsistent as desktop Linux, despite all its development being driven by one company (which is genuinely an impressive feat). Plus, as someone who likes to code, Unix-y operating systems are a lot easier to wrangle.

So, yeah, I end up using macOS. Not out of any great love of Apple, though. I think Apple is doing things to the platform that are in direct opposition to how I want my computer to work.

The state of macOS

Let’s see how macOS is doing, pre-Tahoe. Take a step back in time to September 14th, when the release version of macOS is still macOS 15 Sequoia.

We find ourselves on a desktop, but it’s a strange desktop. Hitting the icon for System Settings brings forth an alien apparition straight from iPadOS. Hints of a phantom “Apple Intelligence” litter the environment, but only hints. Apps like Stocks and Freeform have wandered in from a seemingly foreign world. A strange “Stage Manager” wants to manage your windows for you, but leaves itself off by default, for it has no confidence in itself.

All in all, it’s not the most horrible place in the world, but traces of malaise linger everywhere. Following these traces back to their beginning would take us farther back than I want to go right now, so let’s stick to the recent stuff.

The Big Sur era

2020 was a shakeup year for the Mac platform. Apple began the Apple Silicon transition, and with it, macOS Big Sur brought a fresh coat of paint to the operating system, along with a version number bump to 11 after 19 years of Mac OS X.

The previous year, macOS Catalina had already included signals of the direction things were going. The decision to drop support for 32-bit apps was one; Catalyst, the tooling to instantly make an iPad app Mac-compatible, was another.

Big Sur’s refresh of the macOS design was… something. I didn’t like it very much. I thought it mostly just made things uglier and kind of weird. A lot of places in the UI, colorful iconography was replaced with abstract symbols. Every app icon became roughly a squircle, a choice I found rather odd given that Apple had previously used the shape of app icons to help indicate the app’s category and task. The squircles were highly reminiscent of iOS icons and not in a good way.

Also, a lot of app icons were just lazy, with the old icon plopped into a white squircle. I thought these were the ugliest things ever. The direction macOS Big Sur took the appearance of macOS was just… ugly. Everything was rounder and more abstract. And also less usable.

On Apple Silicon, Big Sur also added the ability to run apps built for iPad without any modifications, not even requiring Catalyst. I think this deserves a moment of whining because it’s produced some truly awful Mac apps.

Catalyst is, in theory, fine. Having a codebase that works in multiple places is easier for developers and could create a more consistent experience across Apple’s platforms. But there’s a cost.

It’s actually really hard to make an app that feels good on iPad automatically feel good on macOS. I think the only good Catalyst app I’ve ever tried is Craft. Most of them feel terribly out of place because the entire UI paradigm they’re built for is iPadOS. As many of Apple’s own inbox apps have become Catalyst apps, the consistency of macOS has markedly degraded.

It turns out consistency across platforms, while a valuable goal, can really seriously break the internal consistency of each platform. iPadOS is a touch-based environment which has always operated within siloed apps that usually don’t expect you to have a keyboard or mouse. macOS is an environment which Apple has steadfastly refused to add any kind of touchscreen to, with apps that have traditionally run in windows, expected keyboards and mice or trackpads, and manipulated documents. They have menubars with generally consistent menus like File, Edit, View, Window, and Help.

The paradigms are just really different, and Apple seems to believe that just throwing software and conventions from one paradigm into another will work by itself. It won’t. It takes a lot of developer effort to make a good Catalyst app, and so most Catalyst apps are crap. Cross-platform Electron apps tend to feel more native to the platform than Catalyst apps, or even worse, just straight-up running a non-modified iPad app on macOS.

This is very embarrassing for Apple. It’s not as bad as the situation on competing platforms, but it is a problem macOS in particular has not had before, and the development of this problem is seriously concerning. Actually, it may even be a little worse on macOS, because other platforms don’t actually have a reference point for what a good, native app that’s part of the platform feels like. macOS does, and Mac users, consciously or unconsciously, know what to expect from a good Mac app, making every newly introduced inconsistency all the more jarring.

A miscellaneous complaint I have that I just want to throw in here is that previously, macOS notifications let you hover over them and instantly gain access to quick actions you could click on, with huge click targets, such as for quickly replying to a message. Big Sur didn’t remove this capability, but it turned them into tiny buttons that were hidden behind a submenu requiring an extra click. I can’t think of any good reason for that change.

The Apple Silicon transition elevated Mac hardware to levels basically unheard of in consumer PCs at the time. The power built in to these devices is insane. Meanwhile, the software has been on essentially a continuous downhill slope, affording less and less of that power to its users. Because Big Sur is just the beginning.

But first, the iPad philosophy.

iPads

iPads are weird devices. They’re general-purpose computers that don’t allow their users to do general-purpose computation. The Pro models are now upwards of a thousand dollars. Apple also apparently increasingly views it as the future of the “computer” in their lineup.

They’ll never admit it, of course. They’ll keep saying they believe the iPad and Mac are different products that are good for different things, and they intend to keep it that way. But their words belie their actions, such as bringing Final Cut Pro to the iPad and introducing window management that works pretty much the same as macOS, menubars and all, to the iPad.

Their words suggest a much wiser course than their actions do. The iPad philosophy runs directly counter to how I want my computer to work and how I believe it should. The prospect of my primary computer being an iPad horrifies me.

So what is it about the iPad that makes it so different from the Mac? Well, iPadOS, for one thing, is an outgrowth of iOS, an operating system designed for mobile phones and centered almost entirely around the concept of the “app”. Apps in a system like iOS are incredibly different from their counterparts in a system like macOS. Actually, they’re kind of a bad abstraction in general.

In order to talk about the reason apps are a bad abstraction, I suspect we’ll need to talk about what they even are.

Apps

(I am using way too many levels of subheading.)

Apps are an abstraction. I’m using that word a lot, so let me talk about what it means in this context.

The world of computers is very hostile to humans. At their core, these things are billions of transistors hooked up to one another and sets of input and output devices that create electrical signals that together manage to perform feats of computation unthinkable to humans of centuries prior. You or I cannot understand or create these electrical signals, so we don’t work with them. Instead we construct a world of “instructions” understood by what we call Central Processing Units and represent them in binary commands that, when fed into these CPUs, they will “know” how to execute.

These are pretty hard to work with as well, so on top of these instructions we craft an entire universe of higher-level programming languages that represents this still-inhospitable world in a way that we humans can at least wrap our heads around. At the level of Assembly Language, we still work with CPU instructions, but represented as English words instead of the computer’s binary; step higher and you might find yourself in the realm of C, working with functions and types that are still the computer’s, but that you might even begin to comprehend yourself; even higher and you might find yourself working with a language like Swift or (ahem) Ruby, a positively human-friendly fiction that attempts to hide away but cannot really conceal the unfriendly nature of the computer underneath.

And yet, no matter how far you go in crafting these fictions, at the end of the day they must all output the same things: binary instructions for the world of the computer. (I am skipping over subtleties like the differences between intepreting and compiling because they are not relevant to the user’s system image.)

If you want to make the computer do something useful, at the end of the day, you have to put a long sequence of binary instructions together into an “executable”. Now, while this is itself an abstraction, it’s not a particularly friendly one for most people; so we abstract away the “executable” as an “application” with a nice icon and name that hides all the gnarly computer bits underneath.

Now, the point I’m trying to make here is that we don’t have the abstraction of “apps” because they are a model friendly to humans that we’ve imposed on computers; rather, it’s an attempt to make the inner workings of computers, a model imposed on us by them, understandable to our mere mortal minds.

So, what would a human-oriented mental model look like?

Documents

What do you actually use an app for? Most computer users aren’t creating their own executables to perform specific computations; they’re using pre-prepared applications made by other people to perform specific tasks.

Let’s look back at the original Macintosh as a reference point. In 1984, most documents were created on paper; “typing” referred to using the typewriter; the concept of an “Internet” was totally foreign to average human being. Until a year prior, the most popular personal computer in the world had been the Apple II; its killer application? VisiCalc - the spreadsheet. It was into this context that Apple Computer introduced the Macintosh, a “computer for the rest of us”.

Let’s talk about VisiCalc for a second, because I think it’s very revelatory about the direction personal computers were taking at the time. Until VisiCalc, personal computers like the Apple II were mostly looked at as toys; a hobby for computer enthusiasts; most of the programs written for them were games. Until VisiCalc, spreadsheets were massive handwritten paper documents; updating a cell required humans to re-calculate every other cell that depended on its value; and that meant remembering where they were and what their formula was.

All of these calculations could be expressed, it turns out, as computations; a document like a spreadsheet could be serialized into a binary “file” that could be stored on hardware like a floppy disk; and a computer program could be made to work with these documents and present an interface to the human that, running on the computer, could greatly simplify the task of using a spreadsheet.

And so it came to be that the personal computer turned useful.

Now, fast-forward back to 1984, and the Macintosh. The core user interface of the Macintosh when it’s introduced is the “Finder”, and the objects manipulated are storage devices like disks, and the folder inside them, and the files inside those. Some of those files are applications; most of them are documents.

As a reminder, there’s no “internet” or “world wide web” at this time. So any content that was on your Macintosh was on a floppy disk; these disks were 3.5 inches in size, you could only have one in your computer at a time, and they could store a whopping 400 kilobytes each.

So using personal computers as a content distribution mechanism would sound pretty ridiculous at the time. Instead, the primary use for a Macintosh would be the creation and manipulation of your own personal documents, or within an office setting, collaboration on documents stored on floppy disks.

The paradigms introduced in the Macintosh System Software reflect this, as do the applications that defined it. Apple’s own focus was on applications like MacPaint and MacWrite, and they got Microsoft to write Word and Excel for the Mac; the introduction of Aldus PageMaker, taking advantage of the Mac’s graphical interface, kicked off the desktop publishing revolution, like VisiCalc with the spreadsheet on the Apple II before it; and Adobe’s Photoshop and Illustrator brought user-friendly graphics manipulation to the personal computer.

All these applications used the menu bar, and all of them had a few basic menus that were about the same. For example, the “File” menu contained commands related to the manipulation of, well, files - the units in which the documents users work with are stored. These include items like “Open…”, “New”, and “Save” - which I think should all be pretty self-explanatory to anybody who’s used a desktop computer in the last 40 years. The “Edit” menu tended to include commands related to the manipulation of items within the currently opened document, such as “Undo”, “Copy”, “Cut”, and “Paste”.

When outside of any applications, the graphical shell of the Macintosh, Finder, was an interface to explore all these files you create and edit in your applications. The Finder let you move them into folders, rename them, delete them, open them, and more.

Now, the Macintosh was and is indeed an application-centric system. But this was out of necessity. The design of the system reveals that the unit that its creators thought users would and should think in terms of were their files - documents - the actual content they were focused on creating. The use of applications was purely driven by the fact that applications are what computers understand.

What really is an application, to the user? It’s the tool they use to manipulate the document they’re working on. But in real life, documents don’t live within their tools; you don’t open your notebook inside your pen to write on a page, do you? The rough equivalent on a computer is a Word document, which you open inside the application called “Microsoft Word” to edit. When Apple created

As computers got more advanced, numerous experiments tried to re-orient the user experience around documents even further - radical reimaginings that tried to eliminate the concept of applications from users’ system image entirely, and less radical ones that simply tried to change the role of applications within the user experience.

Roads not taken

Jef Raskin, the originator of the Macintosh project within Apple, was ousted from the project after Steve Jobs took over after having himself being ousted from the Lisa project. The final version of the Macintosh which shipped in 1984 was very far from Raskin’s original vision; he thought Apple got it all wrong. So after leaving Apple, he decided to pursue his own original vision of what a humane personal computer should actually work like.

The result was the Canon Cat, a computer that did away entirely with what Raskin considered the inhumane interfaces of past computers marked by siloed apps and even filesystems where users had to create and remember a complex hierarchy of names.

Everything lived in one giant workspace and could be leaped to within its context; no remembering where you’ve saved a document, everything just continuously updated in your workspace, and to find anything, you just “leap” to whatever content you remember.

It’s a very utopian vision of computing. It’s also a vision that didn’t sell. Some roads go nowhere and reach dead ends.

I take it you may be wondering where exactly I’m going with all this. Don’t worry. So am I. The answers will reveal themselves in due time.

The Cat tried to free you from the app and the document itself, throwing everything into one giant workspace; that may have been too radical a leap for many computer users to bear. In our own physical world, the intuitions we’ve developed are still too accustomed to working on our documents as individual units; we manipulate distinct physical objects in our real world.

So when Apple took a bite at similar ideas, they didn’t do away with the document; instead, they reified it - even the name of the framework they created, OpenDoc, heavily centered the idea of the document. Let’s talk about OpenDoc and what it did.

When Apple created the Mac, they were never much in love with the “application” concept; for the reasons discussed above, Apple viewed these applications as a middleman between the user and their documents.

Let’s take a look at the Mac before OpenDoc. Bruce “Tog” Tognazzini was Human Interface Evangelist at Apple in 1990, when the company was first prototyping OpenDoc. Previously, he’d written the first version of Apple’s Human Interface Guidelines in 1978; in 1992 he published a book, Tog on Interface, that in his words “explored the central issues of human-computer interaction”, while “focusing on the Macintosh”. It’s in the final chapter, when discussing Apple’s visions for the future of the Mac, where he identified the fundamental frustration with the app metaphor; Apple’s ultimate goal with OpenDoc was a transition to a “plain-paper” metaphor that reflects how we, as humans, actually think about our work.

In his words (pages 282-284): “The current Macintosh environment had at its heart the application. Documents are created within an application and reflect the capabilities of that application. Some applications allow the importation … of pieces of other documents [from] other applications … Nevertheless, creation of complex documents on the Macintosh typically requires the use of several applications and many documents.”

Why is this bad? Well, “the context in which a computer user performs [their] work has historically been dictated by the needs of the machine. As we approach the era of widespread multitasking and multiprocessing, we have the luxury of rethinking decisions made in the era of low-power computers. Application-centered design is one such area of decision. Documents were typically created within tools called applications. Applications were able to stand alone. From the early machines’ point of view, this was ideal. Since applications didn’t need to interact, memory requirements were kept at a minimum and no complex memory management needed to take place — just the sort of scheme you want when you’ve built your computer out of several thousand vacuum tubes or a microwave oven control processor.”

That’s why we have application-centric design; so what does application-centric design impose on documents and humans? Alright, let’s hear Tog again: “Documents-within-tools can be likened to having to place your house inside a giant hammer so you can nail in a picture hook in the living room. Nevertheless, it has survived a surprisingly long time. The document-within-tool metaphor is for the sake of the computer, not the user.”

OpenDoc wanted to reverse the relationship between application and document; rather than documents that live inside applications, documents would be the main unit that users worked with, and applications would simply be tools within the documents that enable capabilities within them.

At its core was essentially a file format for compound documents assembled out of “parts” which were enabled by software components that were like the tools used to edit that part. What does Tog have to say about this? Let’s ask him. Oh, nice, there’s an answer on page 285: “Compound documents, in the supporting plain paper metaphor, do away with the application as the primary object and replace it with the document. Users need create only a single document to get their work done. Applications are replaced by (or simply relabeled as) tool kits, and tool kits can be called upon from within any document. With plain paper, most of the problems of application-centered context disappear: With all tools available within the document, suddenly the user can do his or her project ‘without ever leaving home’”.

That’s a radical vision, but an obvious extension of the original Mac’s principles; applications were incidental to your actual work, your documents, and existed only because the Mac was a computer. OpenDoc was one of the few big projects the flailing Apple of the 1990s actually shipped; unfortunately, due to Apple’s awful condition at the time, it gained essentially no traction outside of Apple.

OpenDoc died with Steve Jobs’ return, during that very famed 90s near-bankruptcy; at such a troubled period in its history, Jobs decided to refocus the company’s focus on a few core products instead, cutting projects like OpenDoc he viewed as extraneous. Focusing on building Mac OS X and replacing their aging operating system arguably saved Apple.

Mac OS X and Jobs’ return to Apple would lead Apple to the iPhone 10 years later; a revolutionary device, to be sure, but one that has lead Apple towards a very different paradigm than the Mac, and the radical vision they pursued with OpenDoc.

iPhones

iPhones are a rather different kind of device. They live in your pocket and you carry them around; they fit in your hand, and you also manipulate everything directly with your hands. It’s fairly small, and thus not particularly suited towards document manipulation or even multitasking. There simply isn’t enough screen space, and fingers are just too imprecise of a tool for that kind of usage.

So instead, modal apps make the most sense in this paradigm — when you want to use your iPhone to accomplish a different task, you enter a different “mode” of usage — something actually roughly analogous to the user-facing “application” concept created to wrap executables.

The iPhone was unveiled to the world for the first time in 2007. This was quite a different world than the one the Macintosh entered in 1984. For one, information was now much cheaper, and continued to become cheaper, to transmit at high speeds - no longer did it move in bulky floppy disks with miniscule storage; the internet changed all that, and the advent of the iPhone marked the dawn of the mobile internet, and the mobile web.

Can you see where I’m going with this? A device centered around modal apps that can cheaply and quickly recieve information and media, but not easily create it; a form factor almost perfect for the consumption of that content; and a software paradigm that almost entirely puts different content in its own independent contexts. The iPhone is the ultimate content consumption device; possibly the only form of media it’s actually good for creating are photographs and videos.

It’s also easily, by far, the most profitable device in Apple’s hardware lineup, and unfortunately, the direct ancestor of every other one since.

Back to the iPad

In 2010, when Apple released their first tablet computer, the iPad, they had a choice; they could have taken the software paradigm of Mac OS X, and adapted it to a touchscreen computer; or they could have taken the touchscreen-first software they already had - the iPhone OS - and simply given it a larger screen to work with.

They chose the latter option.

Modern day iPads are, hardware-wise, every bit as capable as their Mac counterparts. They have keyboards and trackpads, allowing the precision that touchscreens can’t; styluses add a form of creation neither Mac nor iPhone can accomplish; they can connect to external displays to give them a decent screen size, and the Pro models feature the same M4 chips that inhabit the MacBook Air.

But they’re crippled devices. Crippled by what? Crippled by conscious software choices made by Apple; choices that, if they could, they would apparently like to spread to their whole lineup, eventually consuming its oldest surviving member, the Mac itself.

Let’s talk about these choices. Easily the number one frustration for me with these devices is Apple’s insistence on making the App Store the only way normal people can install software on their devices, and thus making it the only possible avenue for developers to distribute their software. This is the kind of thing we should consider downright insane, but we don’t; ostensibly, it’s a security measure, but also one that conveniently gives Apple complete control over what software you use on a device that you own. And even more conveniently, it also creates an effective monopoly over software distribution; that means if you’re a developer who wants to get paid for your app, you have to go through Apple to sell it to users. The famed 30% cut Apple takes from App Store sales is really just extortion; there’s no other way to frame it.

A capitalist might try to defend Apple here, saying that Apple has a right to use a platform they own to make a profit in this way; this is bullshit. Your device is a device you own, and your decision to install software on it written by someone else, some developer, is an entirely consensual transaction between two parties - you and that developer; what right does Apple have to impose a payment fee on it? Apple takes on the same role of a tax-collecting government that these very capitalists claim to hate. Unlike a government, Apple has no need or even right to collect these; there’s no social contract between Apple, its users, and developers, and they make more than enough money from hardware sales to fund themselves.

Consider, too, that in the year 1984 when the Mac was introduced, you would have been laughed out of the room for proposing a personal computer that did not allow the user to perform the computation they desired without permission.

Next, I think we need to talk about the app paradigm used by the software that Apple does allow onto the iPad. It’s extremely far from document-centric. Now, sure, on the iPhone that makes sense; it is a real computer, but it’s not one with a form factor suited to creation. But on the iPad, it’s far more confusing. For starters, you have more screen space here; it’s actually kind of ideal for certain creative tasks like digital painting. With modern-day iPads, you even have keyboards and trackpads like traditional laptop computers; an Apple Pencil adds stylus capabilities that allow for precision. You can even connect them to external displays to add a big screen with high resolution.

Whatever’s crippling these devices, it’s not the hardware. It’s the software.

The iPad stupidly follows roughly the same paradigm as the iPhone. Since its birth till now, it’s essentially been single-window; instead of a “Desktop” on which these windows reside together, you get a “SpringBoard” (homescreen) which launches you into apps and lets you switch between them, and exists in basically a separate context from the app windows themselves. I mean, even the items on the homescreen give the game away; the SpringBoard is full of app icons and widgets, while the Mac desktop is full of folders and files. In a minute or two we’ll get to Apple’s apparent preference for the former over the latter.

The original Mac philosophy — one which Apple tried to make reality against the constraints of computing — was one in which you live in your own work. Documents were first-class citizens — you could open them in any number of tools, shuffle them between folders, duplicate them, copy a chunk from one into another. You weren’t trapped in a particular mode of working.

In a time when Apple didn’t wholly embrace the app paradigm they were trapped in by limited computing resources, they actually tried to free the document from the tools even further; instead of just copying chunks from one tool into another, they tried to integrate the tools into the documents themselves with OpenDoc.

Now contrast this with the iPad philosophy; here in Apple’s dark ages, we see a wholesale embrace of an app paradigm that keeps you trapped in siloes; more often than not these siloes are feeds and storefronts rather than an entrypoint into creativity. On the iPad, you’re meant to live in someone else’s sandbox. Apps are silos, by design. They wall off your thinking, your making, your output, and they insist that you only interact with it through their interface, their menu structure, their “share sheet.”

Instead of your work being the anchor and the app being the tool, the app is the anchor and your work is incidental. That is the fundamental difference between the humane vision of the original Mac and the consumption-driven iPad world Apple has embraced. This is the fundamental flaw in the iPad philosophy. The hardware is extraordinary — M-series chips, gorgeous displays, Apple Pencil, trackpads, external monitors. Everything about the physical machine screams potential. But the software treats it like a glorified content vending machine. No matter how much silicon they pack in, no matter how close they inch the iPad to Mac-level power, the app-trap paradigm drags it down into passivity.

Especially recently, the process of this paradigm tainting macOS itself has rapidly accelerated. Apps like “TV”, “Stocks”, “Podcasts”, and “News” feel out-of-place here; they literally still feel like iPad apps but on the Mac. They are pure consumption; they’re designed to trap you in the context of the app in a world where everything within them could just be browsed in, well, a web browser.

Apple apparently has no direction for macOS, other than “towards iOS”.

So. Where were we? Oh, right, the state of macOS.

System Settings

In macOS Ventura, Apple replaced System Preferences, the program used to adjust various system preferences on the Mac since Mac OS X 10.0 in 2001, with a revamped app they called System Settings.

Why? Well, there really wasn’t any good reason for it — it’s a pretty stupid change, and we’ll get into that in a second. But Apple did it in order to bring the Mac interface closer to the iPhone/iPad interface, so that those more familiar with the iPhone/iPad could adjust to the Mac quicker.

A noble goal — except, of course, when you consider the point I’ve been trying to hammer in since the beginning — consistency across platforms breaks the consistency of each individual platform, and mixes conventions from paradigms that were never meant to mix!

So what did this rewrite do exactly? Ah, wait, yes, I forgot to talk about something else earlier when I was going into Catalyst. In 2019, in macOS Catalina and their other operating systems, Apple also introduced a new framework for building user interfaces: SwiftUI.

SwiftUI is cross-platform — an app using SwiftUI can be compiled for all of Apple’s platforms, from watchOS to macOS to visionOS, and “naturally adapt” to each platform’s native conventions… yeah, right. It follows iOS conventions everywhere, which is mostly fine on pretty much every other one of Apple’s platforms, seeing as Apple has basically embraced the iOS philosophy for everything else… but is not fine on the Mac. It’s also mind-numbingly slow on macOS compared to UIs written with the “old” AppKit framework that the Mac has been using since NeXTSTEP.

Apple also clearly views SwiftUI as their “modern” framework for building UIs. It’s what they want you to use everywhere if you’re building a new app — and they want you to make the same app run across all their platforms, iPhone to Mac. So, naturally, they write a lot of their own apps in SwiftUI. And boy, it shows.

The System Settings from macOS Ventura onwards have been rewritten using SwiftUI. This has led to the strange phenomenon of one of the most core apps on the platform — the System Settings themselves — feeling like a non-native app. Among other things, checkboxes, a hallmark of Mac UI, have been replaced by weird iOS-style slider toggles that look fine on a touchscreen but wildly out of place on a desktop computer.

I really do not want to repeat a load of criticisms which are already well-written up elsewhere, so here’s Ars Technica’s take. It’s solid, and hits most of the key frustrations. The seemingly arbitrary burying of settings several layers deep is pretty irritating, for one. The sidebar-operated navigation also bugs me. But the worst sin of the rewrite is in its very intentions. Making the Mac more friendly to iPhone & iPad users is a noble goal, yes; sacrificing the Mac itself on the altar of iOS is not.

So, System Settings. One more “little thing” that makes the Mac just that much more unpleasant. Not a big deal on its own, but another little cut.

I mean, okay then. What else did Apple get up to in that update?

Stage Manager

The state of macOS window management is… not great. Basically, every single window management feature has at least two — sometimes three or even four — competing implementations that all work slightly differently and do not interact with each other.

Apple has been trying things — a lot of things. The trouble is, they haven’t found a willingness within themselves to commit to any of them. The last time they truly made a serious change to the way window management works on the Mac was back in 2011 with Mac OS X 10.7 Lion.

In Lion, they merged Exposé — the mode that provides a bird’s-eye view of all the windows on your desktop — with Spaces — the Mac’s virtual desktop implementation — into one interface they called Mission Control. Mission Control is a very strong and pleasant interface to use. It’s not very customizable or flexible, but it uses that as a strength in order to enable high consistency. The trackpad gestures implemented for Mission Control feel super smooth and make it feel like a completely natural way to multitask.

Mission Control traded away a lot of the power and flexibility of the preceding implementation of its multitasking features — such as the “grid” Spaces used to be arranged in, replacing them with one horizontal strip — in order to enable a simplicity that makes it feel natural. And in that case, it worked great. Mission Control is good. It articulated a clear philosophy of where Apple wanted to take multi-window multitasking on the Mac desktop. Each desktop is its own dedicated workspace with its own windows — minimized or active — and they inhabit a fluid, easily switchable and expandable strip of workspaces.

That wasn’t the only piece of Apple’s multitasking vision introduced in Lion. Since Mac OS X’s introduction in 2001, Mac windows have had three “traffic light” icons in the upper left corner. Of these traffic light icons, the green-colored one is the only one to ever have changed its function. From 2001 to 2011, clicking that button instructed a window to “Zoom” its contents to fit. This Zoom function was implemented by various apps in different ways — Finder windows, for example, changed the size of the window to fit its contents. Actually, that’s what its meaning was generally intended to be by Apple. In practice, it largely was implemented as window maximization, where the window expanded to fill the space available to it on the desktop.

In Mac OS X Lion, a different approach to having windows fill the screen was introduced while retaining the existing Zoom function — an experiment. This new approach was called “full-screen mode”, and was largely inspired by the way apps take over the screen on your iPad. Rather than simply maximizing its size to fill your desktop, the app gets its own dedicated Space in Mission Control where it completely fills the screen and takes over.

This fit right into the new multitasking model introduced in Lion, which both tried to simplify switching between lots of concurrent workspaces and the contexts within them through its consolidation of Exposé and Spaces, and to make it easier to focus on a dedicated task with a dedicated workspace through its full-screen mode that creates a separate context, free of the clutter of your desktop, for each of its full-screened applications.

In OS X Yosemite, in 2014, the green traffic light’s function switched from zooming to full-screen, which had originally had its button placed far away in the upper-right-hand corner. The zoom functionality remains within macOS and can be accessed from the Window menu, and if you have it configured this way, by double-clicking window titlebars.

And the next year, in OS X El Capitan, Apple made the full-screen mode more useful by adding Split View: the ability to have two apps take up half the screen each in a space together, enabling the same focus as full-screen mode with a limited bit of multitasking.

It is not a perfect philosophy, of course, and it may not fit everyone’s use case, but it’s brave and committed to itself. It tries something and is willing to say “this is a model for multitasking that is both simple and adaptable to various usecases”. And so Mac window management existed for many, many years, and it was good.

For the past few years, Apple has been experimenting again. Let’s see how that’s been going, shall we?

In macOS Ventura, Apple introduced a new window management feature called “Stage Manager”. Stage Manager groups your open windows into “stages”, and then lets you switch between active stages through a kind of vertical dock-like apparition. It’s a rather interesting model for window management, honestly.

Stage Manager articulates its own distinct model for multitasking: visible window groups that collapse into a sidebar where your most recent ones are easily accessible, essentially combining both the concept of workspaces and minimizing windows into one interface. When introducing Stage Manager on the Mac, Apple also added the feature to the iPad as its first form of multi-window multitasking ever. The weirdness of that aside — we’ll get into iPads again in a later installment — the Mac implementation of the feature is hopeless due to its inability to commit to its own metaphor.

You see, the “stages” metaphor has a lot of potential: it’s clearly an idea that Apple thinks deserves a shot as a model for multitasking. Its main trouble is that it’s shoehorned into an existing multitasking model that it doesn’t interact well with, and thus breaks both its own metaphor and the existing one.

What’s rather interesting is that on the iPad, Stage Manager superceded no existing multi-window system; it simply became a toggle for whether you want to keep using the existing single-app paradigm, or switch to a new stage-based multitasking one. There is no “Mission Control” or “minimized windows” for the iPad version to clash with. It’s free.

The Mac version, on the other hand, is not so. Its “stages” are extra multitasking features within the existing “spaces” metaphor, which they don’t replace; instead they just kind of sit side-by-side, stages-within-spaces. They’re not integrated particularly well; it’s not like Mission Control shows your windows grouped by stage or anything. Instead, they’re just two totally separate multitasking models which feel like they sit side-by-side.

Normally, Mac windows minimize to the Dock. When Stage Manager is on, your existing Dock-minimized windows remain in the Dock; but if you try to minimize any new ones, they simply collapse into their own stage. Except it only looks like that; if you click on the minimized window stage, instead of switching to a different stage like it always would elsewhere, it simply gets restored into the stage it came from, despite looking like a distinct one in the sidebar. If you restore a minimized window from the Dock, you can’t put it in the Dock again until you turn off Stage Manager; instead, it becomes part of the stage-based system. The difference between a minimized window and a separate stage is totally invisible to the user. The result is a tangle of metaphors: Dock windows, minimized windows, “stages” that sometimes act like spaces and sometimes don’t. It’s hopelessly muddled and confused.

So that’s Stage Manager’s deal. Apple has no courage; if they did they would simply turn Stage Manager into a totally separate mode that replaces existing multitasking features, instead of its current awkward coexistence and non-collaboration. It would still be a toggle between that and existing methods; but just don’t force them to coexist! Show some commitment to a new metaphor if you’re going to try it.

Jump ahead to macOS Sequioa; in 2024, Apple introduced some cool new window management features, inching closer to feature parity with Windows by introducing window tiling features. They’re honestly pretty good, if rather finicky. Apple did the right thing by introducing them.

Why am I complaining, then? Well, remember the earlier existing features we talked about? For maximizing an application, we had Zoom, which technically isn’t the same thing as maximizing but was basically implemented as such, and full-screen, which worked within the Mission Control multitasking paradigm. Split-screen tiling was also possible through the full-screen mode.

Now, we have “Fill”, which works almost like Zoom except by default it leaves a little border around the window. For those keeping track, that’s three different ways to maximize a window which all have nothing to do with each other and work differently. We now also have an additional method of split-screening with the tiling and snapping features introduced in Sequioa.

This is a state of decay. Languages left behind from eras past try to share sentences with half-bakes ones of today; to use the computer becomes archaeology, layer after layer of abandoned metaphors still half-alive under the glass.

Next Up

Alright. We’re 7802 words in. I think this is a good place to stop this one. We’ve gotten a good look at where macOS was a bit over a month ago before Tahoe’s release. You’ve seen a lot of the disparate pieces of this malaise; you’ve gotten the context of the iPad’s influence on the Mac; now it’s time we see where this is all going.

Next time we’ll be looking at Apple Intelligence and the Vision Pro before jumping back into an examination of macOS Tahoe. Don’t quote me on that, though. My plans change all the time. That’s it for today.

Jef Raskin’s fundamental goal with the Macintosh was one of computing that was humane. How would he look on the Mac, and on the Apple, of today?

On Bookmark Counts

Mon, 15 Sep 2025 10:13:35 -0800

I’m worried. The current implementation of Bluesky bookmarks is fine, in theory, but it has some implications for the future of atproto private data I’m not sure I love.

The main issue for me is the choice to implement public bookmark counts, where despite the bookmarks themselves being private to you, the AppView uses all the private bookmarks it’s aware of in order to aggregate counts of how many bookmarks a post has. Unfortunately, this is a totally opaque count for which you just have to trust the AppView. Because bookmarks are private state between you and the AppView, nobody else can verify this count. This is very different from basically everything else in atproto.

Private state used by the AppView is fine; mutes, list subscriptions, etc, all do that, and it’s fine. The thing about all of those is that they only affect your view of the network. And bookmarks could work that way too, and it would be fine.

The trouble with having private state that affects others’ view of the network is that, in the manner that Bluesky is doing it, it neccessitates centralization. If you have multiple AppViews, their bookmark counts will naturally diverge because they can only count their own users’ bookmarks. If we want to have accurate bookmark counts, we’re conceding that everyone will just be using one AppView. This is centralization.

And the sad thing is, it’s for a feature which nobody even wants to have. The point of bookmarks is that they’re a private way to save posts for future reference. They’re intrinsically not “social”, so we shouldn’t make them into social indicators.

Anyways, thanks for reading. I kept this one short.

Mon, 30 Jun 2025 13:30:37 -0800

Stuff I’ve been reading lately, in case you’re wondering where my head is right now:

arstechnica.com/gadgets/2… arstechnica.com/informati… www.theverge.com/22684730/…

macOS Tahoe

Thu, 19 Jun 2025 23:02:33 -0800

Trying out the developer preview of macOS Tahoe gave me thoughts I wanted to post. This is a short post, if you want me to do a more in-depth post let me know and I’ll do a proper review when the OS ships.

My first impression is decidedly unimpressed. I think I need to start with Liquid Glass.

Liquid Glass

I like skeuomorphism, and as a result I think Liquid Glass looks pretty nice in some places. On the other hand, it also seems to make the interface functionally worse, everywhere.

Let’s start with some positives. The Dock with clear icons can look pretty slick. A nice set of desktop widgets can also look really nice.

Dragging sliders on brightness and volume is also slick.

Here come the problems, which are largely the same as the ones on iOS. I’ll focus on my own personal nitpicks. First off is readability.

Do you find that readable? Neither do I. Transparency doesn’t add anything to the UI for Notification Center, it just makes it feel less usable.

Control Center suffers similarly and just feels worse in general. I don’t like having to guess where it begins and ends! This is actually worse on desktop than iOS.

Also, elements that can expand should be expanded in place, so going back is easy. Navigating the Control Center has always been confusing and doesn’t get any better in Tahoe.

Perhaps the most confounding thing about Control Center in Tahoe is customization. For starters, several tiles behave completely differently in “small” mode vs any larger size. Why are Bluetooth and AirDrop only toggles in small mode, but expandable into a useful menu from any other mode? There’s no good reason for this and it only serves to make the experience worse. This gets worse when you consider that it’s not even a consistent behavior. Both the Display and Sound tiles behave like they should in small mode; that is, expandable.

Control Center’s editing UI is basically unusable, too. It’s all well and fine to show me a gallery of tiles I can add with previews and a name shown next to them; but how good is any of that if I can’t even see the name of the tiles I already have? I mean this - as far as I can tell, there is no way to see what the heck the tiles you already have in the Control Center actually are. With ambiguous icons like these, this becomes genuinely troublesome. These icons are both in the Control Center by default and I have a strong feeling most users will not know what they do just by looking at them. The first one is for Stage Manager, by the way, a more-or-less useless feature that has no reason to exist on the Mac at all, let alone be a default tile in the Control Center.

Finally, the editor lets me create the following arrangement, and saving it works and leaves that tile floating there with a bunch of transparent but nonfunctional clear space in between. It’s pretty bad. The transparency is so bad Control Center as a whole no longer looks like a distinct UI element, despite the fact that it is one. At the very least, when editing it, I should simply not be allowed to create the arrangement below.

Another UI element that is significantly more confusing are sidebars. Here is a Finder window in Tahoe:

The sidebar looks like it is floating above some other content within the window. It is not. Can someone tell me why it looks like it does?

Compare this to how you probably expect a sidebar to look:

This sidebar does not appear to be floating on top of any other content within the window and does not confuse you. I think this is a pretty glaring mistake in Liquid Glass.

The transparent menu bar is another mistake. For starters, it makes the “Show Desktop” function look really strange:

Something doesn’t just look right. I think just giving the menu bar some cleaner visual separation from the desktop would fix that. But it gets uglier when actually trying to use the menubar itself:

I don’t know about you, but that pill menu selection indicator is not doing it for me.

The new look inside applications, at least on macOS, also seems completely disconnected from the rest of the Liquid Glass design. Take a look at the Preview application:

Do those widgets look glassy to you? No, they just look… weird. Combined with the crazy amount of rounding on the window (which, by the way, is impossible to predict for any application you open; some have it, some don’t), Mac apps look like Gnome apps now. As a Gnome disliker, I am not pleased.

Actually, speaking of the window corners:

I want to like the look of Liquid Glass, but actually using it is a marked downgrade from the user interface in Sequoia and past macOS versions. As a UI overhaul, it’s not very big and definitely not nearly as big as Apple claims. The overhauls from Mavericks to Yosemite or even Tiger to Leopard were far larger and much more visually striking. The only time you’ll notice Liquid Glass is when you’re irritated at being unable to read a newly translucent UI element.

Spotlight

…you’re gonna wanna stick to Raycast. Annoyingly, keyboard navigation of the new UI isn’t really intuitive.

I’m pretty annoyed by the removal of Launchpad in favor of a new Applications category in Spotlight. It’s a pointless change which is actually a step down from Launchpad. Until macOS Tahoe, I didn’t realize how much I actually used the Launchpad. Apparently, this whole time, when opening applications, my muscle memory has been bottom-left-hot-corner -> move mouse to app icon -> click. I did not know this was how I did things until it disappeared, which honestly shows it was good UI that got out of the way. Seriously, spatial memory works. The Spotlight UI just doesn’t have that speed or convenience (even the quick apps that show up change order based on recency of usage and you can’t make folders). Without Launchpad, there’s no longer even a way to browse all the applications installed on your computer.

The Actions search using Apple Shortcuts isn’t very powerful or very useful yet. I really am struggling to find a way to make it useful to things I do at all. Raycast is still the way to go for now. Most of the software I use doesn’t actually use App Intents in meaningful ways.

Clipboard history being a part of Spotlight is honestly pretty annoying. It should have been implemented as a standalone feature. As of right now, the easiest way to access clipboard history is ⌘+Space+4. This isn’t a very obvious keyboard shortcut, in my opinion. Something like ⌘+⌥+V would’ve made more sense to me.

Other

I’m going to try Apple Intelligence in Shortcuts at some point. Sounds neat, and I could potentially imagine using it.

Most of the other updates in Tahoe are related to Continuity. Since I don’t have an iPhone, I can’t really do much with these updates, but I’m sure they’re cool.

I think the most interesting new feature will be the new Foundation Models framework accessible to developers in macOS 26. If you haven’t heard, this will basically allow app developers to access the on-device LLM that Apple says is “at the core of Apple Intelligence”.

This is an extremely obvious thing for Apple to do and probably represents the future of where generative AI is going. LLMs are now a service provided by the OS, along with the various existing AI APIs accessible to macOS and iOS developers. This is pretty sensible, and I think deserves its own longer blog post… eventually. I’m bad about these. It’ll be very interesting to see how this new API trickles up through Mac apps.

Those are my thoughts for now. I think I might write a wider post about WWDC eventually, but I’m really not very plugged into the Apple world at all, so my thoughts are unlikely to add much context beyond what you already know. If you want me to make that post, let me know.

Nostr and ATProto

Fri, 05 Jul 2024 14:57:30 -0800

This post could’ve been titled “Nostr vs ATProto”, but that really isn’t what I wanted to do here. While I will be comparing and contrasting them a lot, and that’s kind of even the point of writing this, I didn’t want to really pit the two against each other at all, and especially not with the title. I also want to try avoiding commenting on the differences between the communities that have formed on the protocols and their apps, although I definitely will be looking at the philosophical differences between the two a lot - also kind of the point of writing this. This also isn’t a super deep technical post, though it assumes familiarity with technical concepts. I also might come back to edit parts of it and add more later.

You can read and leave comments on this post here on Bluesky, or here on Nostr, or even here on Mastodon.

So I wrote a paragraph mostly about what this post isn’t about, with a little bit about what I will talk about in it, but I haven’t really explained what this post is, or why I’m writing it. Honestly, I’m not completely sure of the first one yet either; I’m figuring that out as I write it. The paragraph at the top are really serving as guidelines for myself as I write this.

However, I can explain how this post came to be. It started with a showerthought (I was literally in the shower) about how similar ATProto and Nostr really are. This thought came to me after ruminating on ATProto Relays and Nostr Relays, and thinking about how my favorite feature of Nostr Relays (spoiler: it’s filtering) could be added to ATProto Relays, and why you would want to do that. More broadly, this made me think that the two protocols are similar enough that they are likely to slowly converge over time as they learn from each other.

A direct result of those thoughts (after getting out of the shower, of course) was to search the internet for a good comparison of Nostr and ATProto. A direct result of my failure to find any was this Bluesky skoot (There’s a lot of good replies and thoughts in that thread as well—you probably want to read it before continuing with this post). A direct result of my skooting that was this reply. Before, I’d been tentatively considering writing a purely technical comparison after not finding any, but that reply really set the stage for deciding what I wanted to do in this post.

So, to start, let’s look at…

How we got here

A Caged Bird

or, Twitter

Twitter here could, in theory, be replaced here by just “Centralized Social Media”, but really it was Twitter that got us here. Both ATProto and Nostr exist because of Twitter - the AT Protocol very directly so, Nostr as a response to “censorship” (real or perceived) on Twitter. ATProto is the result of Bluesky’s original mission - to build a decentralized protocol Twitter could adopt. Post-Elon, who knows if that will ever happen, but, well, that is how it started.

Twitter sprang into existence in 2007, as a small, SMS-based service that allowed people to post short status updates - tweets, as they became known. Who knows if it was the first of its kind? Well, it certainly became the most popular. It really was the service that was able to popularize the concept of microblogging. It developed a multitude of subcultures, each with their own unique characteristics, often intersecting with each other in fascinating, unpredictable places and ways. And while Twitter certainly never became as popular as some of its big tech companions, it may have had the greatest cultural impact - it was one of the only places in existence where an average person (you!!) could, say, ratio a presidential candidate or give interesting new details on a story to some famous journalist (I don’t know, I just made those up). Some have said it was the first “global town square”.

Over the years of Twitter’s existence, lots of things happened to Twitter. Moderation issues including Donald Trump, authoritarian governments around the world, all sorts of mini community wars and harassment, etc. Twitter, as beautiful as it was, well… kind of sucked, and people drew many different (not mutually exclusive and often overlapping!!) conclusions about why. Some, like Christopher Bouzy of Spoutible, concluded that the platform’s moderation simply wasn’t enough for what the platform had become, and people needed a smaller, more closed space with stricter moderation policies. Others concluded that a global-scale social network is simply an inherently bad idea and people should stick to smaller, more tight-knit communities. But one of the most popular conclusions was that something as important as Twitter - whether you considered it a “global town square” or a place to make connections with your community or Whatever Else - simply could not and should not be controlled by a single corporation. Indeed, this was the conclusion that Twitter themselves came to! This is the conclusion that both ATProto and Nostr are founded upon - the idea of a move from closed, centralized, corporate-owned social platforms to a world of open, decentralized social protocols.

But ATProto and Nostr don’t exist in a vacuum. They weren’t the only ones to come to this conclusion. They weren’t even the first. And that brings us to…

The Mastodon in the Room

or, ActivityPub and the Fediverse

⚠️ I am not an expert on ActivityPub. Take everything in this section with a grain of salt. If I get something wrong, please correct me. ⚠️

ActivityPub is kind of a big deal in the decentralized social protocols world. It’s not the first, either - it would be extremely hard to really find a first. But it is, at least for now, the largest, and realistically is about to become a lot larger, at least if Meta Threads federates with it.

It’s also got an entirely different philosophy to either Nostr or ATProto - while both of the latter are based on a more individualistic approach to decentralization, ActivityPub opted for a more collectivist approach, one that favors tight-knit communities over a global network (that hasn’t stopped people from trying to build global networks with it, though.)

(Side-note: I should also mention that whether the Fediverse should focus on smaller communities or mass-interconnection has been a debate even within the Fediverse since right about the beginning, which a lot of the differing viewpoints around this topic explained brilliantly by Evan Podromou. Since Small Fedi seems to be the dominant philosophy shaping the current Fediverse, I’ve mostly focused on Small Fedi when talking about ActivityPub here.)

There are many different server implementations of the ActivityPub Spec, each adding their own unique flair to the ecosystem. The most popular of these implementations is Mastodon. ActivityPub is also, like I said above, kind of a big deal in the decentralized social protocols world. Almost everyone working on decentralized protocols after ActivityPub has been forced to acknowledge its existence, draw comparisons to it, and often been bridged to it. In fact, when Jack Dorsey fired off his famous tweet thread announcing Bluesky, he was definitely aware of ActivityPub, given that in a reply to a reply to that thread, he stated “ActivityPub is great.”

Because ActivityPub uses a federation model centered around small community servers, it has a lot of the benefits of centralized social media. For example, it makes it relatively easy to support private content, since it’s a push-based protocol - only those whose inboxes you push content to can view it (there’s also an “Everyone” option that makes your content fetchable, I think). This is also why the Fediverse has things like Follow Requests, server-to-server DMs (though your instance admin can view them - ActivityPub kind of assumes you trust them), and real blocks that mostly work.

However, many of the more collectivist choices made in ActivityPub were concluded to not be conductive to a “decentralized Twitter”, and both ATProto and Nostr exist in large part because of this. In fact, both ATProto and Nostr strayed from ActivityPub for the same reasons - identity is extremely tied to your initial server. There are good reasons for this, given that ActivityPub is largely used by smaller communities who federate with each other, but it does have an important consequence:

Your data is not really portable. You can move accounts to another server, and if your old server is well-behaved it can add a redirect to your new account, which will help automatically transfer your old social connections over to your new account, but this doesn’t include any of your data except your follows and followers, and falls apart if your old server goes offline, is adversarial to you or your current server, or in basically any situation where you can’t get that redirect.

There are many other philosophical differences between the ActivityPub camp and the Nostr and ATProto camp, but this one is the most important one, at least in my opinion - both ATProto and Nostr have sections explaining “Why not just go with ActivityPub?” that state this as their primary reason. Both ATProto and Nostr have real account portability by design.

Both of these protocols don’t have much in common with ActivityPub, so I won’t talk about ActivityPub too much here. But there is one older protocol that both of them extensively draw inspiration from…

Secure Scuttlebutt

This is where things start to get pretty interesting. In 2014, a New Zealand programmer named Dominic Tarr was living on a sailboat. As you might assume, such a life includes little internet, and when it comes, in sporadic bursts. Centralized social media, like Twitter, wants you to be connected at all times, scrolling your feed and looking at ads. Tarr didn’t want that. The result? He designed a protocol designed for offline-first, intentional, slow communication, free from Big Tech. Its name? Secure Scuttlebutt.

Scuttlebutt uses an append-only log of cryptographically signed messages. Your identity is an Ed25519 keypair and is pretty much tied to a single device. One consequence of this is that, as the Scuttlebutt developer docs themselves acknowledge, “If a user loses their secret key or has it stolen, they will need to generate a new identity, and tell people to use their new one instead.”

Because it’s an append-only log, every message must contain a reference to the previous message - a bit like a blockchain. That also means that deletes are straight-up impossible. This is also not necessarily a bad thing, just a trade-off.

Scuttlebutt started as a purely peer-to-peer protocol, using a gossip model - in fact, that’s where its name comes from; in sailor-slang, scuttlebutt means “water-cooler gossip”. The first popular Scuttlebutt client was an app called Patchwork, authored by Paul Frazee (keep this guy in mind, he’s gonna be important later), and initially the protocol and client often evolved together, adapting to each other’s needs.

By default, when you add to your append-only log, that addition only exists on your device; but the next time you connect to a peer running a Scuttlebutt client, your two clients will sync with each others’ logs, and then verify them against each others’ public keys. And to verify the newest part of a Scuttlebutt log, you need the whole log - this ensures that if someone gets part of your content, they get all of it.

But you don’t just sync each others’ content - your clients sync all the logs they have locally. That’s why it’s called the gossip model - once you put out a post, as long as you’re connected to a few peers every once in a while, your post will spread as fast as gossip to the friends of your friends. It usually takes time for that information to spread to everywhere, which keeps the pace of Scuttlebutt life somewhat slow and relaxed, with the most active communities being, again, small and tight-knit. Scuttlebutt is definitely not a global social network. The gossip model was driven by the social graph, allowing users to sync with others based on who they follow and who their connections follow. This mechanism relied on cloud bot users, known as “pubs,” acting as connectors and community hubs.

Scuttlebutt syncing took time due to the necessity of syncing all activity. Pubs played a crucial role in facilitating connectivity within the network, ensuring that users could discover others either by sharing a pub or by following users who were connected to them.

Scuttlebutt’s evolution was influenced by the desire for decentralized communication, distinct from the centralized nature of platforms like Twitter. It offered an alternative for those seeking intentional, offline-first communication free from the constraints of Big Tech. While initially designed for smaller, tight-knit communities, the ideas and learnings from Scuttlebutt inspired later attempts to build decentralized networks suitable for global networking.

So, now the stage is mostly set. Twitter was the first “global town square”, a social network connecting people and ideas worldwide - but not without a myriad of problems, which many concluded were due to its centralized nature. ActivityPub and Scuttlebutt (and others) experimented with decentralizing the social world, mostly with a focus on smaller communities, though as they evolved people tried to make them more suitable for global networking. Neither of them would prove viable for global social networks, but the learnings from them would help develop the next generation of social protocols.

Freeing the Bird

or, where ATProto and Nostr came from

All of this is important background for understanding the motivation behind these two protocols. Twitter started it all by showing us what microblogging at scale - a “global town square” - looks like. It showed us how many problems there are with it, and to some, that the only way to fix them is to remove corporate control. ActivityPub and Scuttlebutt showed us two very different ways of doing so, each with their own major benefits and major drawbacks. But there’s still a long way to go from these experiments, which were largely paving the way in the late 2010s, to where we are now, almost halfway into the third decade of the 21st century. To fill in these gaps, we can start towards the end of the second decade of the 21st century.

It wasn’t just people outside Twitter who were aware of the multitude of issues with Twitter - of course Twitter noticed them too. Twitter had started as a much more open company than it was at this point in December of 2019 - over the years, they’d taken, for a variety of reasons, a more centralized path, facing investor pressure for returns, and other such things. Twitter knew that, in the words of founder then-CEO Jack Dorsey, “centralized enforcement of global policy to address abuse and misleading information is unlikely to scale over the long-term without placing far too much burden on people.” Jack and the rest of Twitter drew the same conclusion as ActivityPub and Scuttlebutt had before - corporate control of social media was simply bad for everyone. Twitter was a company full of people who realized the service was just in a shitty position no matter how you looked at it, and who were doing everything in their power to keep things healthy despite it all - and they saw a way out: to build on, or build, an open protocol for a global social network. And for all the reasons we talked about before, about ActivityPub and Scuttlebutt, neither of those protocols were up to the task.

So the Bluesky initiative began. The early history of the project is much better documented elsewhere, but one of the most interesting things to come out of it at this early stage was an ecosystem review of existing decentralized protocols. It was authored by a Zcash developer named Jay Graber, who would go on to become CEO of Bluesky. It included contributions from several notable people in the decentralization space, including Christine Lemmer-Webber, co-author of the ActivityPub spec, Paul Frazee of Patchwork (and at the time now working on Beaker Browser and Dat), Whyrusleeping from IPFS, and Rabble of early Twitter (at the time working on planetary.social, a Scuttlebutt client). It lays out the state of numerous decentralized protocols, including ActivityPub and Scuttlebutt, and explains how user discovery, moderation, etc works in each of them.

At the end of all this ecosystem review, Bluesky concluded that none of these existing protocols was really suitable for their goal - a decentralized protocol Twitter, a global social network, could run on. So they decided to create their own - ATProto - and incorporated into a Public Benefit LLC to help achieve this goal. And when their initial team was hired, it included none other than Paul Frazee of Patchwork, in addition to Aaron Goldman, a former security engineer at Twitter, and Daniel Holmgren, an engineer with experience building on IPFS.

Now, while all of this was happening, a Bitcoin enthusiast under the pseudonym Fiatjaf was working on his own little thing. His idea was a non-peer-to-peer reimagining of Scuttlebutt and what it would take to make a similar protocol usable on a global scale. And on November 7th, 2020, the first basic working code for his idea of “Relays” quietly slipped onto the scene. Nostr’s initial description even cites Scuttlebutt as an inspiration - the main design differences between the two (at a high level) are that Nostr moves from a p2p network, with pubs as an afterthought, to a purely client-relay model, and that Nostr events are all separate units that do not form a chain.

His motivation for creating this protocol was, somewhat similarly to Bluesky, problems with Twitter. Bluesky was motivated by the idea that content moderation at scale is impossible to do well, and centralizing it in the hands of a single company was a bad idea. Nostr, meanwhile, views moderation itself as an enemy - as censorship that the protocol should be resistant to. While in reality, even Nostr has ultimately ended up exploring different forms of communal moderation, the primary motivation behind Nostr’s design choices is an idea of extremely high censorship resistance. This implies that the design, rather than optimizing for consistency, should optimize for availability - if someone wants to see your content, they should be guaranteed to be able to get it from somewhere. The protocol design is pretty conducive to this.

Both of these efforts were toiling away in the darkness, waiting for their moment in order to replace centralized social media with a decentralized future. Then in late 2022, something remarkable happened. Centralized social media fell prey to one of its prime weaknesses, right where everyone could see, thanks to one very famous billionaire. Elon Musk payed 44 billion dollars for Twitter, released the so-called “Twitter Files”, and Jack Dorsey, who had earlier kicked off the Bluesky initiative with 13 million dollars, put out a little manifesto in response, titled a native internet protocol for social media. Within a few hours, someone responded pointing him to the Nostr protocol, and he grew very interested, soon giving fiatjaf 14 Bitcoin to help fund Nostr development. A few months later, Bluesky launched their reference app for the AT Protocol. About a year later, Jack Dorsey left the Bluesky board, having chosen to focus on Nostr instead, as it aligned with his “free-speech-Bitcoin-vibes” ethos better. This was despite the fact that ATProto basically does everything he wants in a decentralized social protocol, but he prefers the more Bitcoin-y community of Nostr.

Okay, so that’s how we got here. Now we’ve arrived, back in the present. Let’s look at…

Where we are

Both Nostr and ATProto follow a similar pattern: adapting peer-to-peer data models to work in a client-server model (that isn’t quite federation). The peer-to-peer world had to deal with a unique problem: because there were no servers, there was no canonical source for data where you could go to verify its integrity. Thanks to the wonders of modern cryptography, efforts like Scuttlebutt, IPFS, and Dat all were able to use self-certifying data structures that could be verified independently of any third-party authority. A good example of this is a Merkle Tree, which is a data structure that ATProto also uses (be sure to watch that video, it’s very good and explains well why peer-to-peer networks need this).

As it turned out, these data structures and their benefits would help solve many of the problems the federated world faces. Specifically, the federated world, while no longer reliant on a single central server, often ends up simply shifting this reliance to smaller centralized servers that are the only canonical source for user data. When done correctly, applying peer-to-peer data models to the server would reduce this reliance and make data more independent of servers, while also allowing the big-world networking that only servers can achieve.

This sounds like a perfect solution, but it’s worth mentioning that it does have some important tradeoffs compared to a pure federation approach like ActivityPub’s. For example, while deletes are still possible on both protocols (though rather difficult on Nostr, which you might be able to piece together why), if someone has your data saved from before your deletion, it is much easier to prove that you said it and hold it up as yours than it is on a protocol that doesn’t have you cryptographically sign everything. And since both protocols heavily optimize for public content, things like Direct Messaging become much more difficult - in fact, on Nostr, DMs are public like everything else (their content is encrypted so no one else can read them). In general, trying to keep data private becomes extremely difficult; these protocols have delivery models which both center around the same self-certifying data being replicated in many places so anyone who wants it can get at it. With this, things like blocking other users become basically impossible, since there’s no canonical source to restrict content from.

Now let’s look at a few different protocol building blocks and how each protocol handles them.

Identity

Identity in networks is a difficult problem. Ideally, you want identifiers to be human-meaningful - for example, a Twitter handle. If I see the Twitter handle @jack, I can be fairly sure that that’s Jack Dorsey. You also want them to be secure - only @jack should be able to create a post that says it’s from @jack, and I shouldn’t easily be able to take over the account @jack without gaining access to some kind of key. And you probably also want them to be decentralized, so that @jack isn’t beholden to anyone else to hold his identity, and can move around.

Unfortunately, it’s not easy to have all three of these nice properties - Secure, Human-Meaningful, and Decentralized - at once. Almost every system which tries to have all three has to end up compromising on one of them. This trilemna is known as Zooko’s Triangle. As examples:

Twitter usernames are secure - I can’t just put out a tweet that looks like it’s from @jack - and human-meaningful - a guy with the handle @jack is probably named Jack. But they’re obviously not decentralized - they are all reliant on Twitter’s servers, and it’s Twitter who decides that @jack points to Jack Dorsey’s account. If they, say, wanted to rebrand to X, and someone was using the @x handle, Twitter could easily take it from them and make their own handle @X.

Scuttlebutt, meanwhile, has identity that’s decentralized - it’s just your private key, essentially a random number - and your public key, the part other people can see. It’s also secure - I need to actually have your private key to pretend to be you. But a public key, which is also just a number (derived from your private key), is not very human meaningful.

If you’re familiar with ActivityPub, you might argue that ActivityPub usernames are all three. This isn’t really true - ActivityPub usernames behave like Twitter usernames, except instead of just one big central Twitter server deciding what username points to what, this is handled in smaller centralized servers which federate with each other.

Nostr and ATProto also experience this problem, and they both share a few views around identity, listed out here so each one corresponds to a side of Zooko’s Triangle:

Your identity should not be permanently tied to a single server - Decentralization
Your data should be cryptographically verifiable as coming from your identity - Security
There are two “layers” of identity - a permanent computer-oriented one and a changeable human-friendly one - Human-Meaningful.

Even with these similarities, how that really plays out in both protocols looks extremely different. The idea that your data is cryptographically verifiable as yours implies a keypair somewhere. In Nostr, that’s exactly it - your identity is just a secp256k1 keypair. Nothing more, nothing less.

That sounds very much like the permanent computer-oriented layer of identity. So the human-friendly identity is handled by a Nostr event of the profile type - this contains stuff like your bio, display name, and avatar. There’s also NIP-05, which allows using the .well-known/nostr.json path on a domain to get email-style usernames, like jack@cash.app - and this includes a special case, _@domain, that gets treated by clients as just @domain. When you @mention someone in a Nostr note, it’s just @<their public key>, which clients then simply display as their display names. Notably, having either a display name or even a real NIP-05 username is completely optional under Nostr, and your public key really is your identity.

This looks like mostly a success, at least in terms of taking those views and treating them as criteria. Nostr actually takes the first point - identity should not be permanently tied to a single server - and goes slightly further: in Nostr’s model, where your identity really is just your keypair, no servers are involved in identity at all. Why would you want that? A major benefit of this approach is that if any of the servers involved in the system goes down or is no longer friendly with you, your identity doesn’t even need to be “recovered” - it’s just there, the same as before. This works well with the Nostr Relay model, which we’ll discuss in the next section.

The drawbacks of this approach are the same as Scuttlebutt. Thanks to the relay model, your identity is no longer tied to a single client on a single device - you can easily move around, between relays, between clients, between devices. This, by itself, for most people, is a good thing, but it comes with an entirely different kind of problem:

Managing a cryptographic keypair is simply not very user-friendly. You simply can’t expect most people to write it down and keep it in a safe place or even take the time to understand what it means. People expect username-password systems, and sure, newer technology like passkeys is actually more secure and potentially easier - but that comes with actual benefits over username-password for most people! Managing a keypair is not only unfriendly, it’s incredibly risky. Since the entirety of your identity is your keypair, and to sign in to Nostr clients is to give them your private key - well, you can probably see where this is going. And again, since your identity is just your keypair, just like with Scuttlebutt, if an attacker gets a hold of your private key, that identity is gone. No longer yours. There’s no-one you can go to for help, no-one who can recover that account, no password reset link.

That sounds very negative, but it is worth noting that at least for web Nostr clients, there is a (relatively) good solution to the sign-in problem - NIP-07. In the NIP-07 world, you don’t give every client your private key - you give it once to a browser extension, and then every time a web client wants to do something on your behalf, instead of directly using your private key to sign messages etc, it delegates that to your trusted extension. This is a lot better than giving your private key out to every client that has some cool new feature you want to try. Of course, this doesn’t help with recoverability - if you lose your private key, whether to your memory or to an attacker, it’s still gone. There are attempts to solve this, too, which I’ll talk about in “Where we’re going” because it has interesting future implications.

ATProto looks at things a little differently. Because of the aforementioned difficulties involved with users managing their own private keys, Bluesky chose to have your signing keypair live on a server - your Personal Data Server, or PDS. Your PDS is responsible for serving your Data Repository to other services on the network, and serves as more-or-less the canonical source for your content. However, your Repository is fully self-certifiable (that means someone can check whether or not you created the content in a copy of your Repo without needing a third party to verify), and so is not permanently tied to your PDS. This is because your PDS is not the canonical source for your identity - but your identity is also not something as small as a keypair here, and does not live entirely client side.

Instead, ATProto uses their own homegrown DID (Decentralized IDentifiers, W3C spec with the aim of helping, well, decentralize identity) method called did:plc, for PLaCeholder. Why is it named “placeholder”? Well, because as of now, it’s centralized. That’s right, the supposedly “Decentralized” Identifier is centralized - and Bluesky actively doesn’t want it to be that way. did:plc was initially intended to be a placeholder until a decentralized method was able to meet their requirements - “a strongly consistent, highly available, recoverable, and cryptographically secure method with fast and cheap propagation of updates”. did:plc has all of these at one major cost - it’s centralized. However, the data in a did:plc is self-certifying (you don’t need to trust/rely on plc.directory to verify the information), so it’s conceivable for it to become more decentralized in the future. (You can also use a did:web, which removes this centralization but forces you to manage everything yourself and relies permanently on your control of a web host on a domain, thus removing most of PLC’s benefits. This is pretty niche, so I won’t talk about it in detail here.)

A did:plc: contains two public keys - your rotation key and your signing key. This signing key is the aforementioned key that the PDS uses to sign your data. The rotation key is important because it manages your did:plc: and thus is needed to sign updates to your DID document, such as when migrating PDSes. The canonical source for your current PDS, valid signing key, handle, and rotation keys (which can also be rotated) are all your DID document. In this way, a DID serves as a “Theseus Identity”, an idea Aaron Goldman laid out well in this YouTube video.

The canonical source of your identity is your DID doc, and all the information in it, i.e. your handle and current PDS must be a two-way connection - your handle is a domain with a dns txt record or ./well-known/atproto-did that must point to your DID, providing two way verification, and whatever PDS your DID document points to must actually have your account on it. Meanwhile, the PDS handles data, and implements a standard, user-friendly login system, and signs your updates with your key on the server side.

Here, there was a trade-off between principles of security, recoverability, and user-friendliness, and a principle of max-decentralization - low-friction identity, with no centralizing points of control at all, extreme takeover resistance. Notice that

Where ATProto chooses user-friendliness, Nostr chooses max-decentralization. This is a trend that repeats in many other parts of each protocol’s design, as we’ll see.

Data

In the traditional federated world of protocols like ActivityPub, there had never been much of an emphasis on data, and the formats and structures it’s stored in. The federated world thought much more about how servers should communicate messages rather than how they should store data - this difference is laid out well by Bryan Newbold, who incidentally now works on protocol design at Bluesky. This emphasis on communication standards rather than data standards is a big part of why there’s no standard “fediverse repo” that you can transfer between servers, and other such problems in the federated world.

The peer-to-peer world, as we looked at earlier, couldn’t afford to define pure transport protocols - they had to design standardized data structures that were self-certifying and self-contained. An example of such a data structure is a blockchain, and indeed, the peer-to-peer community and the blockchain community learned much more from each other than either of them and federation did from each other.

This was the status quo until ATProto and Nostr came along and broke the mold by bringing these self-certifying data structures into the client-server world. They both use asymmetric cryptography to make this data self-certifying, but the similarities basically end there.

In the Nostr model, servers are dumb. They have basically one job - transmit data. There’s only one kind of server in Nostr - a Relay, and a Relay does only three things:

Receive data to store
Return that data when asked for it
Provide a continuous stream of the data being placed on that Relay

Notably, Relays store data. Data is placed on Relays. All this data is created on the client-side. Relays don’t manage identity or any of that. Your keys live with your client, and it’s your client who signs your events (a piece of data in Nostr terminology.) When you fetch data from a Relay, it comes back with signatures and all - which, guess what, your client verifies. Your client almost operates under the assumption that Relays will try to do weird stuff, people will submit fake events, etc - and so Nostr removed the requirement of trust, by making clients verify everything themselves. A trade-off!

Nostr, by optimizing for censorship resistance, needs to remove as much rigidity from its design as possible. Data needs to be cheap to create and transmit and store. So Nostr events all exist as individual units following a fixed JSON format with a strict signing convention. Unlike Scuttlebutt, these events don’t need to form a chain - they are purely self-contained. Like your identity, there’s no canonical source for them either - by design, you’re supposed to be able to get them from pretty much any relay that has them. When you create the event, your client signs it and then just publishes it to as many relays as possible, from where it will circulate into other Relays, consuming clients will republish them, etc. Because they are signed against your public and are fully self-contained, it’s trivial to verify them too, removing the necessity of trust in the Relay you get the event from.

ATProto data is also very portable, but it is slightly more rigid than Nostr data is. Instead of using these one-off events which are fully self-certifying, ATProto stores your data as records in what it calls a repo. These records live under a collection like app.bsky.feed.post and are given an rkey (record key). Together, this forms a URI for any given record that looks like at://did/collection/rkey. Importantly, records are mutable, unlike nostr events, and the contents an at:// uri points to may change. However, all the commits to your repo, which contain changes like record creation, editing, and deletion, are content-addressed using a CID, and these are immutable, and are all signed using your repo’s signing key (the one from your DID doc, remember?) Your commits can also optionally form a chain if you want, but when they don’t, deletes are easier. (If all of that flew over your head, don’t worry. All you need to know is that ATProto allows deletes and edits, while Nostr can’t.) Because your data all lives in this repo, unlike Nostr, ATProto actually has a canonical source for your data.

There’s also a single place where your repo lives, instead of being scattered as a bunch of events across Relays like in Nostr. Your repo lives in your Personal Data Server - as the name implies, a PDS is designed to store your personal data. While Nostr Relays are dumb pipes, PDSes are more like a user agent, which really performs almost all actions on the user’s behalf. It’s responsible for signing and storing commits to your repo and wrapping them in a nice API that’s easy for clients to use.

Actually, we should probably take a minute just to talk about deletes and edits. When I said Nostr can’t allow deletes and edits, that wasn’t completely true: Nostr does have a way to request deletes from Relays, which most but not all Relays support, but the real trouble is figuring out what a delete even means (and edits are straight-up impossible since Nostr event IDs are fully content-addressed). Nostr’s model is fundamentally based on an idea of events flowing from the creator into Relays, which then flow into other people’s clients, which cache them and republish them to other Relays, and so on. An event doesn’t have a location to be deleted from - it could be (and in Nostr’s model, should be!) anywhere and everywhere.

In ATProto, your repo actually has a place where it lived - your PDS, as specified in your DID doc. And at:// uris are mutable, so a commit can actually change the content it points to. Deletes remove content from your repo - although anybody who has a copy of your content pre-delete will still have it and can very easily cryptographically prove that it’s your content.

Trust

Nostr and ATProto have relatively similar approaches to trust, though with some important differences. Nostr trusts nobody, and is built accordingly, with clients verifying everything themselves. ATProto assumes you trust somebody, but lets you choose whom you trust, and provides the mechanisms needed to verify that trust is placed correctly (although this could be improved).

Nostr, as mentioned earlier, was designed to basically eliminate the necessity of trust in the first place. Because everything is verified client-side, and essentially functions as a bunch of self-authenticated units of data traveling between relays and clients, there really is no one to trust. Relays can choose not to carry content, but other relays might have them instead. However, the fact that all data moves as individual units means that it would be harder to spot if only certain events are available.

Since every user is assumed to be pointing their client at more than one relay, it doesn’t really matter if one relay chooses not to carry someone’s content; there’s a high likelihood another one is. If many relays agree to hide something from the network, then it won’t show up, but that’s pretty unlikely to happen. As for trusting the authenticity of the content delivered by the relay, because it’s cryptographically verifiable as coming from the attached pubkey, any shenanigans will be spotted quickly. And verifying a pubkey’s identity is done by attaching it to a trusted NIP-05, i.e. @jack@cash.app or @jb55.com.

ATProto isn’t that different, all things considered, but there’s multiple other hops between the source of data and the client you view it in. Each ATProto PDS puts out a cryptographically verifiable stream of commits being pushed to repos on the PDS, carrying every bit of data to the subscribers, called the firehose. Because there are a lot of PDSes, an optimization also called a Relay was introduced, which basically aggregates PDS firehoses into its own giant firehose. In a way, this Relay could be considered its own centralization point where bad untrustworthy things could happen, but once more than one Relay exists this should be less of a problem. At the Relay and PDS, everything is cryptographically verifiable, and as a bonus because of ATProto’s repo structure, you can tell if you’re not getting the whole picture.

After the Relay, things get a bit murkier, because as an optimization ATProto applications use something called the AppView. The AppView reads in the firehose from the Relay constantly and pieces it together into fully hydrated and speedy APIs which make clients’ lives much easier. The thing about the AppView is that it’s basically centralized, and though it’s not super difficult to spot inconsistencies between what the AppView gives you and the true state of the network, the AppView doesn’t even provide the cryptographic signatures that were passed into it, making its trustworthiness a bit murky at some unknown time in the future, at which point other contenders will hopefully exist to replace it, based on analysis of which one is more trustworthy by comparing the data each AppView gives you with what actually exists on the Relay and PDSes.

Privacy

Everything is completely public on both protocols and in fact being actively broadcasted to loads of consumers, not just sitting around waiting to be stepped on and found. Nothing you do is really hideable from anyone.

However, at least on ATProto, there have been attempts to add some semblance of privacy to the network. For example, there are AppView-enforced blocks, but they can be bypassed very easily. There is also a setting which asks the client to not show your posts to logged-out users, but this is superficial at best, since only some clients really follow it anyways, and the “official” popular client does so it does kind of work. But overall these measures both run a risk of making people feel like their posts and other activity are hidden and safe, lulling them into acting with less precaution than they should, especially since there is a lack of user awareness around the all-public nature of data on the network.

No such attempts have been made on Nostr. This is on the one hand unfortunate, but on the other hand possibly better since it is more honest about the true nature of how public everything is on the network.

Development

Due to the Bluesky devs’ past experiences with developing on peer-to-peer and federated protocols, many of them felt burnt by a Scuttlebutt-and-Nostr-style approach to development, where specifications were loose and implementations varied wildly. Because of these past experiences, Bluesky chose to go with a slightly more slow, intentional, and centralized development model. The protocol is mostly developed within Bluesky the company, though often adapts to the needs and feedback from the wider ATProto developer community, and community members often contribute to both the protocol and the clients. The rollout of core features like federation and stackable moderation has also been much more slow on ATProto than similar features in Nostr implementations, because in general Bluesky prefers to take their time and “get it right” and standardized before letting things out into the wild. Also, despite the existence of third-party clients, the “official” Bluesky app and service is still the most popular one by a huge margin, due to its being the default (and basically only) inroad into the protocol and ecosystem. There are other up-and-coming AT Protocol projects that aren’t just Twitter clones, like WhiteWind for blogging, but overall the ecosystem remains sparse compared to Nostr.

Nostr, meanwhile, takes the same approach as these previous projects - the protocol itself just exists, very small, letting anyone expand on it. When an extension wants to become standardized, it’s reviewed by a small team including fiatjaf and a few others, and becomes part of the NIPs repository (Nostr Implementation Possibilities). This is basically classic BDFL open-source. However, clients and relays are free to try their own wild things without being “official” NIPs, and any NIP proposal must be adopted by a few clients and relays before it can be considered for “official” status. So it’s a much wilder, freer ecosystem so far.

Applications

One of the places where ATProto and Nostr differ greatly is their model for building applications.

ATProto takes the AppView approach. An AppView is basically a service that reads in the firehose of all the public data on the network, and indexes it into hydrated “views” as an API which clients then use. AppViews are pretty resource-intensive to run and functionally centralized in nature. If you want to make a new ATProto app, you first design your schemas for content in a DSL called Lexicon. Then you make a client that can start publishing your record type, and retrieving and displaying it. For the retrieval and displaying, you create an AppView which monitors the firehose for your record types and indexes them into hydrated views, which your client can then fetch from and display nicely and neatly. This is, for example, how the Bluesky app can show a list of users who liked a post; because instead of the client having to crawl the entire network itself and figure out which likes are for the post you just viewed and then get the DID and fetch each of that user’s profiles and whether or not you’re following them by checking your own repo, and whether or not they’re following you by looking all over their follow lists, the client just makes one HTTP request and makes the result human-readable. Nice and fast. Of course, the relief that comes to the client means a lot of responsibility is thrusted onto the AppView, which becomes very resource-intensive to run.

The first steps to the Nostr model look similar at first, but rapidly diverge. With Nostr, you also start with defining event kinds, and then creating a client which can publish them, and then adding fetching and displaying. The key difference is in how events are fetched. With ATProto, you write an AppView to do the heavy lifting; with Nostr, the heavy lifting is shared between the Relay and the Client. When defining your event kinds, you make sure to also define how to use the “tags” field for that event kind, which is an array of key-value pairs with single letter keys which are indexed by the relays the events are sent to. Basically, if you want to do any kind of linking between events, or inserting any kind of indexable data, that’s where you want to do it.

Then for the fetching of the data, we use Nostr’s filtering system. With Nostr, there are two kinds of communication between the client and the relays; publishing events, which pushes the signed client-created event into the relay’s data store, and subscription. Subscription is the interesting part we’re looking at here.

Nostr clients can request a subscription to a stream of events from the relays they’re connected to, and this stream subscription can have filters attached. A filter is fully specified using the following attributes, all optional:

{
  "ids": <a list of event ids>,
  "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
  "kinds": <a list of a kind numbers>,
  "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
  "since": <an integer unix timestamp in seconds, events must be newer than this to pass>,
  "until": <an integer unix timestamp in seconds, events must be older than this to pass>,
  "limit": <maximum number of events relays SHOULD return in the initial query>
}

By adding multiple filters, you can get all the events matching any of the filters. By adding multiple attributes to a single filter, you add multiple conditions that all have to be fulfilled for events to make it through that filter. Filters are expressly the mechanism for fetching content, since subscriptions are supposed to start by backfilling everything that meets the criteria, and then pushing any new events that meet the filters’ requirements to the client.

By studying the filter specification, it’s clear that basically every behavior of ATProto AppViews can be recreated through filters on the client-side, knowing how tags allow extensibility as well. There’s an obvious cost though: clients must be very complex and do a lot of work themselves, and for big events duplicating a lot of effort that could be handled by something akin to an AppView. The benefit of this is that it is very generic and means that any relay can generally be used for any functionality since everything you need is baked into the core protocol, and the speed of development is basically only constrained by the client, and not an AppView. And by not spending any resources on building a giant indexer yourself, you basically shift the cost onto the Relays instead. It’s another example of the more “bazaar” philosophy of Nostr compared to a more “cathedral” approach from ATProto.

So, all in all, this gives a pretty good picture of where the two protocols are now. But exciting things are on the horizon for both. We’re heading into uncharted territory…

Where we’re going

When Jack Dorsey wrote a native internet protocol for social media, he wrote that “As far as the free and open social media protocol goes, there are many competing projects: @bluesky is one with the AT Protocol, nostr another, Mastodon yet another, Matrix yet another…and there will be many more. One will have a chance at becoming a standard like HTTP or SMTP.”

That’s one way of thinking about it, as a competition for the final spot of “the standard for social”. But as you’ve probably noticed from reading this post up to here, I don’t really agree with this viewpoint. ATProto, Nostr, ActivityPub, Scuttlebutt, Matrix, IPFS, Dat, Holepunch, and others all share similar goals, yet have vastly different perspectives about how to accomplish them. Maybe these different perspectives will all lose! Maybe, as Jack says, one of them will win, becoming a standard that everyone adopts. Or maybe they will all learn from each other and slowly begin to converge. And it’s not hard to make the case that that last possibility will happen for at least two of these protocols - of course, Nostr and ATProto. In fact, that’s already happening.

Convergence

Because a lot of core ideas in the protocols were already very similar, they can quite easily borrow ideas from each other in order to improve themselves. By making nearly opposite compromises, they now face roughly opposite problems as well - but often, the other protocol already has a solution waiting for them. So first let’s look at some of the ways Nostr is becoming more like ATProto.

First, the idea of keys in a server, instead of purely client-side. As mentioned earlier, one of the dangers of Nostr keys is that by giving them to lots of random clients you try, they might accidentally end up in the hands of bad actors. One of the solutions to this was NIP-07 browser extensions; another one is the idea of an NSecBunker, for Nostr Secret Key Bunker. The idea is that this is a server, similar to a PDS, which holds your Nostr private key, and when your client wants to sign an event, it makes a request to your NSecBunker to sign that event using your private key, which stays safe in your Bunker. These requests usually are authenticated using measures like OAuth. It allows Nostr to bring back at least one part of the user experience people are familiar with.

Another idea that Nostr is ending up trying is something similar to AppViews. This is particularly divisive within the community, with many feeling that only the relay-based filtering mechanisms should be used to build clients. But because this is often inefficient, clients like Primal have begun doing their own pre-indexing of many users and posts in order to improve their UX. Unfortunately, Primal’s is proprietary, and only Primal can interact with it, due to the lack of any built-in support for AppView-style services in the Nostr protocol, vs. ATProto’s numerous mechanisms to provide explicit support for this use case.

Meanwhile, some Nostr ideas are naturally going to the ATProto world as well. The idea of keys directly owned by the users has long been floated, and at this point developers can get control of their did:plc and its rotationKeys (fun fact: I set one of my plc rotationKeys to my Nostr pubkey). Unfortunately no nice UI exists for this yet. And as for signing keys, with commits that could be pushed to a PDS instead of made there, that would rely on a PDS supporting this use case. No PDS implementation currently supports this, but there is one in development which hopes to at some point ;)

Another idea which I hope to see adopted in the ATProto world is something similar to Nostr’s filters model. While the AppView model is nice for production apps, something like Nostr filters could help a lot early in development to just play with an idea and try it out. And it could help those with concerns about the trustworthiness of AppViews quickly verify it against certain queries. You can do a shocking amount with backlinks alone.

Of course, the slow convergence of both protocols isn’t the only way the divide between them is being bridged…

Bridging

Recently, Bridgy Fed started bridging the Fediverse and the ATmospherewith each other. For a while, services like Mostrhave been bridging the Fediverse and Nostr with each other. Now, if you visit the Mostr homepage and scroll down, you can probably see where this is going…

Soon after Bridgy Fed started bridging the Fediverse and the ATmosphere, Nostr users experimented with this to bridge between Nostr and Bluesky. Very much an indirect hack, but also a glimpse at the future.

One of the most important promises of decentralized social media was that no matter what service you signed up on and post on, you would be able to see content from and interact with anyone, no matter which service they used either. Now, all this would work, if every service signed on to the same decentralized social protocol. However, instead, we have many, and none of them show much of a sign of becoming the singular standard for social media. Instead of Jack’s vision of one winner, bridges offer a vision of a world where every protocol can win, and it truly won’t matter which protocol your service uses, either.

While the bridging I talked about above was very indirect, Bridgy Fed itself may soon have native Nostr support. Soon all three major decentralized protocols may be able to talk to each other, and easily too.

So. Let’s recap what we’ve been through in this post so far. In the beginning, there was Twitter. Twitter’s problems caused them to look to decentralization as a way to make social media more fair. This caused many new decentralized protocols to emerge, taking inspiration from older ones. Of these new protocols, two of them, Nostr and ATProto, evolved in similar directions, yet unaware of each other made many opposite compromises. And now they are evolving back towards each other, converging in potentially very interesting ways, with bridging offering to make social media not just platform- but protocol-agnostic.

The future is looking good for decentralized social media.

You can join the conversation on Bluesky here.

Comments from Bluesky:

Or on Nostr:

Comments from Nostr:

Sun, 31 Mar 2024 07:41:03 -0800

Test! Please reply to this :)

Why HIPSTER is the best stack for your new application in 2024

Sat, 02 Mar 2024 10:32:56 -0800

Alright, so you’ve been screwed over by whatever trendy new tech stack the JS devs have been pushing one-too-many-times, and you’re looking for a truly reliable, tried-and-tested, production-grade stack that will carry your application from first lines of code to IPO. Well, in that case HIPSTER is probably not the right stack for you (unless you happen to be Discord, which happens to be one of the most hipster companies around) - HIPSTER is for the true hipsters of the programming world. If that’s you, read on to find out how HIPSTER can benefit your application.

So I’ll keep this simple (just give a short paragraph to each letter of the acronym and what it does and how it helps):

(And because why not, let’s go backwards? Because that’s HIPSTER.)

R - Rust

Well it sort of goes without saying that if you’re writing, well, anything in 2024, it has to have some Rust in it. You know, Rewrite-It-In-Rust and all the memory safety and sorta functional programming and hipster-ness you get from writing your code in it. Plus, especially if you’re based in the US, this is essential for legal reasons, given that the White House recently started mandating Rust. (See https://bsky.app/profile/ovna.dev/post/3kmel3b5cig2s). By including Rust in your HIPSTER-based project, you can ensure the US Department of Memory Safety will find no flaws in your code, as long as you satisfy the Borrow Checker and all that.
E - Elixir

Safety is good. Memory safety is good. Rust gave you memory safety. What does Elixir give you? The time when programs ran sequentially from top-to-bottom is long-gone. If you’re not running things concurrently in 2024, you’re missing out on… well… I don’t know, being hipster. Also, more importantly than any of that, Elixir has a really cute aesthetic! You get to feel like you’re mixing little code potions. Very hipster.
T - Terrible ideas

Okay, this one might sound counterproductive, but hear me out. Good ideas have been failing in practice for years. You have a great idea, but then you start implementing it and find that it fails in real life. At least, that’s the conventional way of doing it. Maybe you need to try some terrible ideas since the good ones never seem to work! And it’s hipster to be different.
S - SQLite

Why would you use literally any other database when SQLite exists?? It’s easy, fast enough, and you can track its version history by putting it in Git.
P - PDS

You know, an AT Protocol Personal Data Server? Almost an essential component of the stack. Certainly THE essential component for its flagship application… and also just kind of a cool thing to have…
I - Irony

This one is a lie. There is nothing ironic about this stack or this article. It is a purely serious look at the HIPSTER stack and its benefits. The HIPSTER stack is not ironic.
H - HIPSTER

There are two ways to read this, and they’re both correct. The most important component of the HIPSTER stack is, of course, you!!! And of course, especially the Hipster spirit within you. The other most important component of the HIPSTER stack is the HIPSTER stack itself, for obvious reasons.

Well, that’s it! I hope you enjoyed the article and can see all the glorious benefits the HIPSTER stack can bring you. Thanks for your time!

Sun, 04 Feb 2024 21:14:39 -0800

I’m not quite sure how to describe it, but my issues with AI and VR seem to come from the same place

Wed, 24 Jan 2024 16:04:04 -0800

40 years ago today, this little creature was introduced to the world - a dogcow. The case she came in became affectionately known, famously, as the “Macintosh”, and the dogcow became known as “Clarus”…

Sun, 14 Jan 2024 11:38:45 -0800

I have somehow made the cursed decision of using my Raspberry Pi 4 as both a desktop computer and my home server

On Spatial, Zoomable UIs

Sat, 16 Dec 2023 22:43:00 -0800

I recently installed a neat little piece of software called Eagle Mode on my Linux desktop (a Raspberry Pi 4). It uses a concept of a “Zoomable UI”, in which instead of double-clicking files and folders to open them, you just zoom in and out and pan around. It created a really neat, cohesive and overall plain fun environment to use. In fact I’ve almost switched to it entirely for day-to-day file management. It’s incredibly convenient to have a comprehensive at-a-glance view of everything. Its power becomes much more clear when applied beyond just file management; if you zoom around and look at some of the other included modules, like the Clock and the Chess game, it feels like it really could replace our current WIMP desktops one day. It’s the type of environment you can really only get a feel for by exploring it yourself.

The other kind of UI that I find really exciting is the spatial UI in Smalltalk. My experience has primarily been with Squeak, so I’ll speak to that specifically. The part I found intriguing was not the regular windowing UI - that was pretty standard. But almost everything else about Smalltalk fascinated me. The object model and message-passing stuff is less relevant to this post, so I won’t dive into that here. What caught my attention was the GUI objects, that were fully composable, you could make other objects out of, and place anywhere on the desktop, resize, rotate, and overall treat like actual objects, not windows. It was a fully spatial environment, a bit like the old Mac OS Finder but working with objects instead of files.

I think the future of the GUI is going to be some sort of combination of the two. Some kind of GUI where you have an infinite, spatial, zoomable desktop made of objects which can contain other objects.

This post was an overview, I’ll do a more detailed deep-dive soon.

Mon, 04 Dec 2023 19:08:59 -0800

test poast, somebody please reply

Fri, 10 Nov 2023 10:17:39 -0800

Trying out the Sparkles Micropub client! Very nice and minimal. This should go through Micro.blog, and if I have syndication set up properly, to Mastodon, Nostr, and Bluesky as well…

Sun, 08 Oct 2023 12:05:24 -0800

checked out a bit of Ruby’s DRb

getting me more and more curious about distributed programming or whatever it’s called. probably time to check out cwebber’s goblins next

Thu, 10 Aug 2023 16:08:59 -0800

Migrating my blog to micro.blog so I can free up the server it was on for some cool stuff :P

Wed, 09 Aug 2023 20:34:18 -0800

okay this is great. micro.blog mac app is awesome. and with crossposting I may never again have to touch a web ui for social media

Wed, 09 Aug 2023 17:03:25 -0800

hmm

Wed, 09 Aug 2023 12:14:21 -0800

just settin up my micro.blog