Specifying Spring ’83

Provocation

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 inter­esting to me, in a way that’s simple, expres­sive, 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 — not in a way that’s suffi­ciently simple, expres­sive, and predictable.

“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.

That’s not the only problem. As I wrote earlier:

There are so many ways people might relate to one another online, so many ways exchange and convivi­ality 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 unin­ter­ested 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 decen­tral­ized 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 tech­nology 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 presen­ta­tion is a kind of content; so RSS cannot be the end of the story.

Email is a retreat. You might have reached this web page through an email. Whew! It worked! The thing is, email inboxes have been algo­rithmic 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 expres­sive power is waxing strong.

For me, the recent resur­gence 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 dissem­bling 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 inter­ac­tions, 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 connec­tions on TCP port 17. Once a connection is estab­lished a short message is sent out the connection (and any data received is thrown away). The service closes the connec­tion 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 main­tained 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 oppor­tu­ni­ties and excite­ments 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 convivi­ality might be organized.

Spring ’83 isn’t over yet.

Protocol

From my lab notebook:

FIRST LIGHT: successful request to server, cryp­to­graphic veri­fi­ca­tion in browser, and display, on Sun April 24 at 3:42 pm.

Spring ’83 is a protocol for the trans­mis­sion and display of something I am calling a “board”, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted. Boards invite publishers to use all the richness of modern HTML and CSS. Plain text and blue links are also enthusiastically supported.

The trans­mis­sion side of the protocol is a tiny HTTP API; the display side is a simple set of rules. Put together, they help users follow publishers — who might be people, computer programs, or anything else — in a way that is (you guessed it) simple, expres­sive, and predictable.

Here’s the current draft spec­i­fi­ca­tion. I hope it is legible to the spec-readers among you; this is, I have discovered, a really difficult kind of writing!

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 inves­ti­ga­tion 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 chal­lenging and energizing.

Display

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, regard­less of when it was last updated. Each publisher maintains just one; there is no concept of a history. Think instead of a white­board that is amended or erased, or a magazine replaced with the new edition.

Client appli­ca­tions 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
• yawps 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:

Or with one like this:

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 inter­ac­tions and rela­tion­ships. The protocol doesn’t provide any mechanism for replies, likes, favorites, or, indeed, feedback of any kind. Publishers are encour­aged to use the full flex­i­bility 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 specif­i­cally 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.

Transmission

Let’s turn to the server side. The trans­mis­sion protocol, a tiny HTTP API, is outlined in the spec. There are two things to know:

1. In operation, a Spring ’83 server is mostly a “plain old web” server.

2. Boards are cryp­to­graphically 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 under­lying cryptography is simple, totally off the rack, but still, every time I think about it, I’m aston­ished it works. Because publishers are iden­ti­fied 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 male­fac­tors 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 main­taining 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 conver­sa­tion with Hannu Rajaniemi about Frankenstein, one in which Hannu lamented the novel’s common portrayal as a cautionary tale about scien­tific 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 nego­ta­tions between devices, yes — and also conver­sa­tions, even games, between people. This has been forgotten as protocols have gotten more complicated, but when I read the early RFCs, I get it so clearly: protocol as puzzle, argument, joke!

Spring ’83 is very simple, so I hope it might invite imple­men­ta­tion, just for fun, in your favorite program­ming language, on your weirdest device, with plenty of elbow room for exper­i­men­ta­tion and innovation.

Invitation

So that’s the idea. On the client side, a light­weight HTML magazine rack offered as an alter­na­tive to the timeline; on the server side, a federated network that tries to be more than just a burden to its operators, with an invi­ta­tion to invent and explore.

I’m distrib­uting 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 imple­men­ta­tion with a very small group of people. I’m in no great rush with this — which is a new feeling for me.

It was the expe­ri­ence of drafting the spec that changed my view, and my pace. Writing! Gets you every time! It also helped me under­stand the appeal of the crypto white papers, honestly. Documents like these give you an oppor­tu­nity 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 discus­sion all up and down the ladder of abstraction, from the protocol’s broad aims to its specific strategies. Send me a note, robin@robinsloan.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 — the kind of interval that rolls up neatly for storage, like a projector screen. Spring ’83 is still graspable, in memory and in spirit, and time remains to build a network that can take us happily into the 2020s and beyond.

Discussion

After circu­lating this newsletter, I received a ton of terrific email correspondence, and several folks published their thoughts online.

Here’s a public consideration from Darius Kazemi.

Here are some musings from Tracy Durnell, focused on design.

Here are some notes and questions (fronted by a very kind meme) from Louis Potok, who traces the spec’s logic into a few inter­esting corners and edges.

Here’s a wide-ranging consideration from Maya, who maintains one of the great modern home pages; I am a longtime admirer and reader.

Here are some thoughts from makeworld, complete with sugges­tions and (very welcome) nitpicks.

And then, what followed was a season of actually using this protocol. Amazing! I’ll now reflect on … 

The summer of Spring ’83

The first thing to say is, it worked! This document and the related spec­i­fi­ca­tion inspired a ton of discus­sion. Better yet, they inspired imple­men­ta­tion. You’ll find some great work linked in the GitHub project.

(Of particular note is Ryan Murphy’s <spring-board> element, which encapsulates a whole Spring ’83 “board”, described above, into a reusable HTML5 Web Component. My web programming skill level is still anchored somewhere around 2010, so Ryan’s custom element feels, to me, like magic.)

What else happened? Well, people used — and some are still using — my very basic demo client, pulling in boards from a handful of servers operated by different people. And people crafted those boards! Some were blog posts by another name, others glit­tering CSS confections. People wrote poems for their boards; people probed the limits of what’s possible with 2217 bytes.

My aspi­ra­tional compar­ison with vintage comic books ads — 

—turned out to be pretty apt. It looked eye-poppingly great.

By any measure: we stood up a protocol.

It is, however, very clear that Spring ’83 is not going to be “the next Twitter”, or “the next RSS”, or the next anything, really.

This is fine!

Indeed, I want to make a case for protocols — for whole little social networks — as inves­ti­ga­tions and experiments. It doesn’t take a million users, or a thousand, or even a hundred, to learn genuinely inter­esting and important things: about the protocols themselves, about new ways of relating online, about people in all their glorious weirdness.

I believe I learned a few things this summer, and I’ll jot them down below.

First, though, I want to repeat something from above: I really strongly recommend this exercise to anyone who feels dissat­is­fied with their options on the internet today. Give it a few evenings. Imagine something new; describe it as clearly as you can. You don’t have to actually build your something — you don’t even have to publish your descrip­tion. It’s the imagining and the describing, the chal­lenging work of expressing your dreams and desires clearly, that turns out to be useful and bracing … and fun!

Now, here are a few jotted findings, left as notes along the path for future protocol-specifiers. This is all written in the past tense, which isn’t totally correct; some people, including me, are still using my demo client! But the present tense would feel too much like the forced cheer of a faltering startup. More to the point, it’s going to be a while before I, personally, do any more devel­op­ment on this protocol, or another one like it.

So, for me, the past tense is appropriate — but that’s not to say someone else couldn’t pull Spring ’83, or something like it, back into the present tense at any moment.

Here are my notes for fellow travelers.

Your protocol is too complicated

My initial spec­i­fi­ca­tion of Spring ’83 was, I thought, very simple. Appar­ently not simple enough: in the months following its publication, most of my revisions were deletions.

Protocol spec­i­fi­ca­tion plays into two key weak­nessess of many technical people:

1. The desire to show off

2. The desire to say, “Don’t worry, I already thought of that”

My first draft of the Spring ’83 spec had material of both flavors, and it’s precisely that material that’s now been blasted away.

Keep it simple. It’s okay if you didn’t already think of it. You want people to implement this, don’t you? Keep it simple!

People really want to mention each other

A core part of this protocol’s design is that no messages are ever pushed; you get only what you ask for. As such, the “mention”, as expe­ri­enced on Twitter and Instagram, doesn’t exist in Spring ’83. And yet! People still mentioned each other! The mentions were makeshift, inert, but they “worked”, because the universe was so small and we were all reading basically all the boards. And even if they didn’t work, the urge was still so strong! Overwhelming.

I guess you just can’t keep conver­sa­tion out of it, where humans are involved.

Mentions seem simple, but I think they’re hugely fraught, and not only when they become a vector for harass­ment and abuse. I suspect the fairy tales tell us something real and true: names have power, and the invo­ca­tion of a name always carries an impact. Even when it’s nothing but nice! Like ringing a bell.

I don’t, however, think the solution is a jet cockpit’s worth of access controls. Rather, I suspect there might be some clever new formu­la­tion of the “mention” waiting out there, just waiting to be discovered … 

Public keys are a demon’s bargain

Spring ’83 uses public key cryp­tog­raphy for user iden­ti­fi­ca­tion and veri­fi­ca­tion. Even as the specifier of this protocol, the person who brought those tech­niques into it … these keys were totally excruciatingly annoying.

It’s like a bargain out of a fable. Public key iden­ti­fiers give you all these incred­ible powers, and they seem to spring out of nowhere — just spon­ta­neously available in the universe. The price they exact in return is: utter illegibility. A complete abdi­ca­tion of aesthetics.

The more you think about it, the funnier it gets.

DEMON: Human, I shall grant thee a name that none may imitate!

HUMAN: Wow, that’s so cool. What a gift! Okay, what’s my name?

DEMON: Known thee shall be as 1e4bed50500036e8e2 — 

HUMAN: *walks away*

There’s no free lunch. I still find the capa­bil­i­ties of these magic numbers tantalizing, but I do not think I will include them in my next protocol.

Three cheers for HTML and CSS

You would not BELIEVE the boards people made. Not all were gonzo; many were sober, very clear and “designer-y”, in the best possible way. But some were gonzo, too, and this, more than anything, was the triumph of the summer of Spring ’83: a chorus of cheers for modern HTML and CSS, and all the ways you can express yourself with them, and in them.

The weakness of the protocol, as presented in my demo client, was that you could only design your board by writing raw HTML and CSS. That’s fine for the nerdiest among us, but still a bit forbid­ding for everyone else. A better client would provide built-in templates, maybe a little WYSIWIG editor — you can imagine this easily.

For my part, I settled on a simple design: a blood-red headline in 72-pixel italic Bodoni over an acid green background. Someone said to me, not a little bit archly, “So, really, you made all of this because wanted to tweet in a 72-pixel font.”

And I had to confess that maybe I did.

On this front, I am an evangelist: arbitrary HTML and CSS should have a place in our social networks. They are so expres­sive, and they are available everywhere, on every device, essen­tially “for free”.

How do you run a platform slow but steady? Unclear

The whole premise of Spring ’83 was a protocol with a slower cadence. Indeed, after the summer’s flurry of activity, I’m now updating my board about once a month. In many ways, this is great. But … how do you build a habit of “checking in” when not much is changing? I struggled with this myself. Even during the summer, in the protocol’s fullest bloom, I would forget about my demo client for days! A week! It just did not — could not — set up that sense of twitchy compul­sion.

Platform design seems to me now like a sharp hilltop with steep slopes descending in both directions. A platform built around twitchy compul­sion will trend towards addiction; a platform built around stolid patience will trend towards … forgetting about it.

If only you could balance perfectly at the summit. Alas, I don’t think it’s possible.

The problem is that even when patience “wins”, it loses, because patience retreats, while compulsion compounds. What do I mean? Over the years, I’ve broken many of my twitchiest compul­sions, and I’m much better off for it — and yet, I’m aware that my nirvana of patient, non-twitchy engage­ment doesn’t have any gravity. As far as you’re concerned, it doesn’t exist! I’m off reading a book somewhere, sure, but everybody else is still tweeting, and the tweets, they call out to you … 

So, the partisans of patience need some new tricks. We need ways of claiming space on screens — asserting the existence of our alter­na­tives — without conceding an inch to the twitchosphere. Email works, of course; it’s likely you’re reading this newsletter because of an email. I just think there ought to be more than one (1) digital distri­b­u­tion channel we can depend on.

This is totally doable. These new tricks need only to be invented — or perhaps repurposed.

Who wants to host content? Nobody normal

My little Spring ’83 server has hosted, in total, probably 40 or 50 people’s boards: a miniscule burden, by any standard. But I report to you truth­fully that this was, for me, a source of incred­ible stress, all summer long. My reaction made me realize something:

It takes a weird kind of person to want to host other people’s content.

Like, it’s kind of insane! Host content for people who you don’t KNOW? And take on, perforce, either (a) the oblig­a­tion to moderate it upfront, reading every­thing — impossible — or (b) the burden of knowing you didn’t, so those weirdos could be out there posting anything, right now?

Digital spaces are sometimes analo­gized to homes or restaurants, with the impli­ca­tion that of course you’re free to kick someone out, just as you would in your home or restaurant. Back before I’d ever hosted anything for anyone, I nodded along to this analogy, but now I see that it’s incomplete, because people only visit your home or restau­rant while you’re there. These real spaces are, by the standards of digital spaces, almost impos­sibly well-moderated.

That’s what made my stomach churn: the reality that I’m not always, or even usually, at my computer.

Obviously, many people are not so concerned about this. The policy of reacting to harass­ment or abuse or vileness on a “best-effort” basis seems, to them, good enough. “Best effort” is, of course, the most I could aspire to — but it didn’t feel good enough! It felt pretty awful.

Keep in mind, this was while every­thing I hosted was unfail­ingly nice and fun. If something had appeared that was actually vile — whew! I don’t know. I’m not cut out for this.

(Who IS cut out for it? Perhaps only the people truly hungry for scale, who can separate themselves from the systems they’re operating. I’m trying not to be too dire and judgmental here, but honestly, I think it might be inhuman. I think you might have to make yourself into a kind of machine to be okay with “best effort”.)

This suggests a challenge: could you design a protocol that truly makes people respon­sible for their own content, elim­i­nating or at least blunting the peril and stress of hosting? That puts us back in the world of “everybody should just host their own content on their own website”, which is, of course, what some people have been saying for decades. Well, it hasn’t caught on yet, and I don’t see any indi­ca­tion that it will … but maybe there is some analogy available, some repro­duc­tion of that arrange­ment on a different level, that could begin to address this challenge.

It’s ironic: in the devel­op­ment of this protocol, I spent more time thinking about abuse than anything else, by far. During the summer of Spring ’83, largely by dint of the size (very small) and quality (very high) of the protocol’s userbase, abuse was a non-issue. In a way, I wish I had just … chilled out. But, again, I think it might take a weird kind of person to do so.

A new era of protocols is upon us

You feel it, don’t you? They’re all crumbling, the platforms of the last decade. It’s unsettling, but/and also unde­ni­ably exciting. Tall trees fall in the forest, and light streams down, nour­ishing places it hasn’t reached in ages.

But we, as users of the global internet, cannot just ride the same roller­coaster again. It’s too embar­rassing to be trapped inside these hungry corporate gambits, these dumb proper nouns. The nouns and verbs of our online rela­tion­ships should be lowercase, the way “magazine” is lowercase, the way “movie” is lowercase. Anybody can make a movie. Anybody can try.

New protocols abound, and more are on their way. In the months and years ahead, as you explore and evaluate them, I encourage you to ask this question:

Does this protocol recreate something that already exists?

The oppor­tu­nity before us, as inves­ti­ga­tors and exper­i­menters in the 2020s, isn’t to make Twitter or Tumblr or Instagram again, just “in a better way” this time. Repeating myself from above: a decen­tral­ized or federated timeline is still a timeline, and for me, the timeline is the problem.

This digital medium remains liquid, protean, full of potential. Even after a decade of stasis, these pixels, and the ways of relating behind them, will eagerly become whatever you imagine.

So: imagine!

November 2022, Oakland