Specifying Spring ‘83
What follows is a narrative description of a protocol that I believe might open up some interesting new possibilities on the internet. My goal here isn’t to “sell you” on its design; rather, I just want to lay out my thinking as clearly as I can.
It’s okay to share this link, but I want to underscore that I am sending it specifically to you with the hope that you will … really think about it! At such a primordial stage, a proposal like this doesn’t need diffuse, drive-by attention. It needs, instead, close consideration and generous imagination.
If you are returning to this newsletter after reading it once before, don’t miss the growing discussion.
Since mid-June, a ton of great work has percolated; you’ll find much of it linked in the GitHub project.
Near the end of last year, I asked myself:
What do you want from the internet, anyway?
Somewhat to my surprise, I found an answer waiting.
I want to follow people who are interesting to me, in a way that’s simple, expressive, and predictable.
I want this to work, furthermore, whether those people are sharing a random thought every day, a blog post every week, or an art project every two years.
And I want it to work, of course, across media, so I can follow writers, musicians, programmers, theorists, troublemakers …
Pretty basic! And yet, nothing on the internet presently allows me to do this —
“Surely,” you say, “either Twitter, RSS, or email must suffice.”
Well, let’s go through them, quickly.
Twitter’s timeline is a muddle. It’s too uneven; when a user stops speaking, they disappear, and, by corollary, as a follower, you mostly encounter the users who are speaking nonstop. In my memory, Twitter was once a generous router of attention, with an ecology friendly to links; as the years have ticked by, the circle has tightened, and today, Twitter points mostly into itself.
There are other problems. As I wrote earlier:
There are so many ways people might relate to one another online, so many ways exchange and conviviality might be organized. Look at these screens, this wash of pixels, the liquid potential! What a colossal bummer that Twitter eked out a local maximum; that its network effect still (!) consumes the fuel for other possibilities, other explorations.
This means I’m uninterested in the projects that accept Twitter’s design as sensible and try to implement it “better”. (I’m thinking of Mastodon, Scuttlebutt, and Bluesky.) A decentralized or federated timeline is still a timeline, and for me, the timeline is the problem.
RSS is too stark. I follow a lot of RSS feeds, and I appreciate them, and I almost want to leave it at that; nothing’s more boring than re-litigating RSS. I will just observe that there is something about this technology that has seemed, over the years, to scold rather than invite; enclose rather than expand; and strip away rather than layer upon.
For my part, I believe presentation is fused to content; I believe presentation is a form of content; so RSS cannot be the end of the story.
Email is a retreat. You probably reached this web page through an email. Whew! It worked! The thing is, email inboxes have been algorithmic for a long time, and publishers struggle with Gmail’s caprice almost as much as they do Instagram’s. Furthermore, email’s crusty underpinnings, though they are precisely what make it so sturdy, really pinch at a moment when the web’s expressive power is waxing strong.
For me, the recent resurgence of the email newsletter feels not much like a renaissance, and more like a massing of exhausted refugees in the last reliable shelter. I’m glad we have it; but email cannot be the end of the story, either.
I’m dissembling a bit. The truth is, I reject Twitter, RSS, and email also because … I am hyped up to invent things!
So it came to pass that I found myself dreaming about designs that might satisfy my requirements, while also supporting new interactions, new ways of relating, new aesthetics. At the same time, I read a ton about the early days of the internet. I devoured oral histories; I dug into old protocols.
The crucial spark was RFC 865, published by the great Jon Postel in May 1983. The modern TCP/IP internet had only just come online that January, can you believe it? RFC 865 describes a Quote of the Day Protocol:
A server listens for TCP connections on TCP port 17. Once a connection is established a short message is sent out the connection (and any data received is thrown away). The service closes the connection after sending the quote.
That’s it. That’s the protocol.
I read RFC 865, and I thought about May 1983. How the internet might have felt at that moment. Jon Postel maintained its simple DNS by hand. There was a time when, you wanted a computer to have a name on the internet, you emailed Jon.
There’s a way of thinking about, and with, the internet of that era that isn’t mere nostalgia, but rather a conjuring of the deep opportunities and excitements of this global machine. I’ll say it again. There are so many ways people might relate to one another online, so many ways exchange and conviviality might be organized.
Spring ‘83 isn’t over yet.
From my lab notebook:
FIRST LIGHT: successful request to server, cryptographic verification in browser, and display, on Sun April 24 at 3:42 pm.
The transmission side of the protocol is a tiny HTTP/1.1 API; the display side is a simple set of rules. Put together, they help users follow publishers —
Here’s the current draft specification. I hope it is legible to the spec-readers among you; this is, I have discovered, a really difficult kind of writing!
I am not sharing, at this time, code for a client or server, although I have reference implementations of both that I’m testing with a couple of friends. I’ll post them on GitHub eventually … but I think there’s something interesting, maybe useful, about approaching this first as a discussion. Perhaps it leaves a little more space, here at the start, for imagination.
Also gives me a chance to avoid the really ruinous errors.
Update: I’ve now posted a simple demo client. There are a few server implementations brewing, too! The ones I know about are listed here.
Before I go further, I want to say: I recommend this kind of project, this flavor of puzzle, to anyone who feels tangled up by the present state of the internet. Protocol design is a form of investigation and critique. Even if what I describe below goes nowhere, I’ll be very glad to have done this thinking and writing. I found it challenging and energizing.
On the client side, Spring ‘83 rejects the timeline and the inbox, aspiring instead to the logic of newspaper classifieds —
—and vintage comic books ads —
—and magazine racks:
A touch of chaos? Yes. More importantly, every board holds its place, regardless of when it was last updated. Each publisher maintains just one; there is no concept of a history. Think instead of a whiteboard that is amended or erased, or a magazine replaced with the new edition.
Client applications display all the boards you are following together, laying them out on a 2D canvas, producing unplanned juxtapositions, just like the newsstand above. Boards might be:
- mini home pages, updated regularly with new work
- lists of links to web pages recently read, perhaps with brief notes
- daily logs, wiped clean each morning
- yawlps to the universe
Some boards will be baroque CSS confections, others a sentence and a link in the system font, still others blaring
<h1>s. Some publishers will be friends, others anonymous geniuses, still others robots. You’ll follow and unfollow publishers with a simple interface defined by the client, not the protocol.
Spring ‘83 clients combine following and publishing. A board isn’t a project you manage separately; it’s a chunk of HTML you edit right there alongside the others, perhaps assisted by a simple template.
You might react to a book with a board like this:
Just finished Ways of Being, the new Bridle book. What a kaleidoscope. The material on alternative approaches to computing, including liquid computers (!), was fascinating.
- The Mountain in the Sea
- Frankenstein audiobook
- A truckload of Edgar Allan Poe
💌 Recs welcome!
Or with one like this:
This book is so good it's making me mad
Hmm, nice gradient. I could use one of those. No problem: clients always support View Source.
You might update your board twice an hour or twice a month; you might amend one sentence or reboot the whole thing. Publishing a new version is instantaneous, as easy as tapping a button. You don’t have to manage a server to publish a board; you don’t even have to establish an account on a server.
Spring ‘83 doesn’t formalize interactions and relationships. The protocol doesn’t provide any mechanism for replies, likes, favorites, or, indeed, feedback of any kind. Publishers are encouraged to use the full flexibility of HTML to develop their own approaches, inviting readers to respond via email, join a live chat, send a postcard … whatever!
This is a “pull-only” protocol. As a user, you don’t see anything you didn’t specifically ask to see; no notifications, no recommendations, no unsolicited messages.
There are no analytics, obviously. Nothing is counted. Boards can’t load tracking pixels, and they can’t ping remote analytics APIs. Sorry, folks … you’ve got to let go of the numbers. In 2022, they are not helpful feedback, but rather a clear warning you are in the wrong place.
This raises the question, how can a network that abjures all these dark patterns possibly grow? The only possible answer is: I don’t know! Maybe we’ll figure it out together.
Let’s turn to the server side. The transmission protocol, a tiny HTTP/1.1 API, is outlined in the spec. There are two things to know:
In operation, a Spring ‘83 server is mostly a “plain old web” server.
Boards are cryptographically signed in such a way that they can be passed from server to server and, no matter where your client gets a copy of a publisher’s board, you can be assured it is valid.
The underlying cryptography is simple, totally off the rack, but still, every time I think about it, I’m astonished it works. Because publishers are identified by public keys, and because their boards are signed using those same public keys, the publisher/board link is “self-certifying”, a term gleaned from David Mazières’s 2000 Ph.D thesis.
In a self-certifying system, content carries its own durable provenance, allowing a network of servers to share it between them, and if one or two or a hundred are malefactors bent on deception, who cares? They can’t fool us.
So … who runs these servers?
A large fraction of my thinking about this protocol has consisted of me squirming out of actually operating infrastructure. I squirm still. My appetite for maintaining a server is infinitesimal. I whine to myself: can’t I just propose something? Do I really have to operate it?
Then, I remember a conversation with Hannu Rajaniemi about Frankenstein, one in which Hannu lamented the novel’s common portrayal as a cautionary tale about scientific hubris. In fact, Hannu argued, Frankenstein’s tragic mistake was not creating the monster. Mary Shelley makes this very, very clear: the great mistake was abandoning him.
Fine, okay, I get it! And yet: the last thing I want to do is start an internet business, even a cute, “sustainable” one. Databases terrify me. I’m offline for long stretches of the year. How is this possibly going to work?
Well, here’s an argument for you. Protocols aren’t only for using; they are for implementing. That’s part of their value in the world. They support negotations between devices, yes —
Spring ‘83 is very simple, so I hope it might invite implementation, just for fun, in your favorite programming language, on your weirdest device, with plenty of elbow room for experimentation and innovation.
And one of the interesting things about Spring ‘83 is that when you operate a server, you get a universe for free.
With any kind of federated protocol, the question arises, where is stuff stored? How do you know what’s where? Spring ‘83 adopts a gonzo strategy cribbed from the blockchains: everything is everywhere.
For the blockchains, this strategy is a creeping vexation, as their ledgers grow without bound. Spring ‘83 makes a different choice from the get-go, adopting a “deflationary publishing policy”, capping the size of the network at 10,000,000 boards. (Remember that a board can be edited over and over, so this is like saying there can be, at most, 10 million magazines on the rack. There’s more nuance to this limit, which you can find in the spec.)
Ten million boards gives us a maximum disk space requirement of 22.17 gigabytes, easily stored on a commodity hard drive or a cheap-enough cloud volume. A capable computer could even hold that in RAM. Turns out, when you don’t store every user’s entire history, plus a record of every advertisement they’ve ever seen, your database can stay pretty slim!
A Spring ‘83 server isn’t just one kind of thing. In fact, the only requirement for servers is that, when they receive new boards, they must forward them along to their peers using a gossip algorithm described in the spec. Even this requirement isn’t exacting; Spring ‘83 tolerates downtime. Servers can conk out and return. They can take Mondays off.
Beyond the requirement to share? A server might support one or more client applications, providing boards for display; that would be a reasonable thing to do. A server might, alternatively, pursue its own projects. Maybe it wants to scan boards and produce a report of top links across the whole network. Maybe it wants to monitor the behavior of its peers, ensuring they’re following the rules. Maybe it wants to calculate algorithmic “who to follow” recommendations and offer them to anyone who might be interested.
My hope is that “all the boards” could become an interesting, tractable subject for experimentation.
So that’s the idea. On the client side, a lightweight HTML magazine rack offered as an alternative to the timeline; on the server side, a federated network that tries to be more than just a burden to its operators, with an invitation to invent and explore.
I’m distributing this to you as an RRFFCC, which of course stands for Robin’s Request For Friendly Critique and Comment. For my part, I’ll continue to test my reference implementation with a very small group of people. I’m in no great rush with this —
It was the experience of drafting the spec that changed my view, and my pace. Writing! Gets you every time! It also helped me understand the appeal of the crypto white papers, honestly. Documents like these give you an opportunity to boot something up in your head, examine it in a way that’s technical, sure, but also literary, imaginative, maybe even dreamlike … I don’t know; I like it!
Anyway … I wonder if you might want some of the same things from the internet that I do. I wonder if you, too, might be hyped up to invent things. If so, I invite discussion all up and down the ladder of abstraction, from the protocol’s broad aims to its specific strategies. Send me a note,
email@example.com, or publish your thoughts and pass along the link. I’ll add it here.
In another year it will be Spring 2023, the modern internet’s fortieth birthday. Four decades is nothing —
I have received a ton of terrific email correspondence —
Here’s a public consideration from Darius Kazemi, who has
some experience reviewing RFCs, as I did a yearlong blog project where I wrote about each of the first 365 RFC documents.
What amazing context. As I mentioned above, I found the particular genre of the RFC, or RFC-alike, extremely challenging (not in a bad way); so, feedback from someone who “knows from RFC” couldn’t be more welcome or useful. As you’ll see, Darius’s notes have a lot to do with clarity, the “why” alongside the “how”.
Here are some musings from Tracy Durnell, focused on design, which is fantastic. It’s helpful to see her think through a few ways that Spring ‘83 might connect to existing web technologies.
Here are some notes and questions (fronted by a very kind meme) from Louis Potok, who traces the spec’s logic into a few interesting corners and edges. I feel like Louis’s post is perfectly in the spirit of this document; it’s like, “RFC? OK! C!”
Here’s a wide-ranging consideration from Maya, who maintains one of the great modern home pages; I am a longtime admirer and reader. It’s so useful —
Here are some thoughts from makeworld, complete with suggestions and (very welcome) nitpicks.
June 2022, Oakland