Specifying Spring '83

(What fol­lows is a nar­ra­tive descrip­tion of a new pro­tocol. I circulated it in June 2022, and it received a warm, engaged response. Fol­lowing sev­eral months of devel­op­ment and exploration, I wrote some reflections, appended below, in the sec­tion recounting the summer of Spring ’83.)

Provocation

Near the end of last year, I asked myself:

What do you want from the internet, anyway?

Some­what 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 suf­fi­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 time­line 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 gen­erous 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 con­vivi­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 net­work effect still (!) con­sumes the fuel for other possibilities, other explorations.

This means I’m unin­ter­ested in the projects that accept Twitter’s design as sen­sible and try to imple­ment it “better”. (I’m thinking of Mastodon, Scuttlebutt, and Bluesky.) A decen­tral­ized or fed­er­ated time­line is still a time­line, and for me, the time­line 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 some­thing 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 pre­sen­ta­tion is fused to con­tent; I believe pre­sen­ta­tion is a kind of con­tent; 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 pub­lishers struggle with Gmail’s caprice almost as much as they do Insta­gram’s. Furthermore, email’s crusty underpinnings, though they are pre­cisely 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 reli­able shelter. I’m glad we have it; but email cannot be the end of the story, either.

I’m dis­sem­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 sat­isfy my requirements, while also sup­porting 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 pro­tocols.

The cru­cial spark was RFC 865, pub­lished 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 Pro­tocol:

A server lis­tens for TCP con­nec­tions on TCP port 17. Once a con­nec­tion is estab­lished a short mes­sage is sent out the con­nec­tion (and any data received is thrown away). The ser­vice closes the con­nec­tion after sending the quote.

That’s it. That’s the pro­tocol.

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 com­puter 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 con­juring 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 con­vivi­ality might be organized.

Spring ’83 isn’t over yet.

Protocol

From my lab notebook:

FIRST LIGHT: suc­cessful request to server, cryp­to­graphic ver­i­fi­ca­tion in browser, and dis­play, on Sun April 24 at 3:42 pm.

Spring ’83 is a pro­tocol for the trans­mis­sion and dis­play of some­thing I am calling a “board”, which is an HTML fragment, lim­ited to 2217 bytes, unable to exe­cute JavaScript or load external resources, but oth­er­wise unrestricted. Boards invite pub­lishers to use all the rich­ness of modern HTML and CSS. Plain text and blue links are also enthusiastically sup­ported.

The trans­mis­sion side of the pro­tocol is a tiny HTTP API; the dis­play side is a simple set of rules. Put together, they help users follow pub­lishers — who might be people, com­puter programs, or any­thing else — in a way that is (you guessed it) simple, expres­sive, and predictable.

Here’s the cur­rent draft spe­cification. I hope it is leg­ible to the spec-readers among you; this is, I have discovered, a really dif­fi­cult kind of writing!

I want to say: I rec­om­mend this kind of project, this flavor of puzzle, to anyone who feels tan­gled up by the present state of the internet. Pro­tocol 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 time­line and the inbox, aspiring instead to the logic of news­paper classifieds — 

—and vin­tage comic books ads — 

—and mag­a­zine racks:

A touch of chaos? Yes. More impor­tantly, every board holds its place, regard­less of when it was last updated. Each pub­lisher main­tains just one; there is no con­cept of a history. Think instead of a white­board that is amended or erased, or a mag­a­zine replaced with the new edition.

Client appli­ca­tions dis­play all the boards you are fol­lowing together, laying them out on a 2D canvas, pro­ducing unplanned juxtapositions, just like the news­stand 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 sen­tence and a link in the system font, still others blaring <h1>s. Some pub­lishers will be friends, others anony­mous geniuses, still others robots. You’ll follow and unfollow pub­lishers with a simple inter­face defined by the client, not the pro­tocol.

Spring ’83 clients com­bine fol­lowing and pub­lishing. A board isn’t a project you manage sep­a­rately; it’s a chunk of HTML you edit right there along­side the others, per­haps 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 sup­port View Source.

You might update your board twice an hour or twice a month; you might amend one sen­tence or reboot the whole thing. Pub­lishing a new ver­sion is instantaneous, as easy as tap­ping a button. You don’t have to manage a server to pub­lish a board; you don’t even have to estab­lish an account on a server.

Spring ’83 doesn’t for­malize inter­ac­tions and rela­tion­ships. The pro­tocol doesn’t pro­vide any mech­a­nism for replies, likes, favorites, or, indeed, feed­back of any kind. Pub­lishers 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 … what­ever!

This is a “pull-only” pro­tocol. As a user, you don’t see any­thing you didn’t specif­i­cally ask to see; no notifications, no rec­om­mendations, no unsolicited mes­sages.

There are no ana­lytics, obviously. Nothing is counted. Boards can’t load tracking pixels, and they can’t ping remote ana­lytics APIs. Sorry, folks … you’ve got to let go of the num­bers. In 2022, they are not helpful feed­back, but rather a clear warning you are in the wrong place.

This raises the question, how can a net­work that abjures all these dark pat­terns pos­sibly grow? The only pos­sible 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 pro­tocol, a tiny HTTP API, is out­lined 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 pub­lisher’s board, you can be assured it is valid.

The under­lying cryp­tog­raphy is simple, totally off the rack, but still, every time I think about it, I’m aston­ished it works. Because pub­lishers are iden­ti­fied by public keys, and because their boards are signed using those same public keys, the pub­lisher/board link is “self-certifying”, a term gleaned from David Mazières’s 2000 Ph.D thesis.

In a self-certifying system, con­tent car­ries its own durable provenance, allowing a net­work of servers to share it between them, and if one or two or a hun­dred are male­fac­tors bent on deception, who cares? They can’t fool us.

So … who runs these servers?

A large frac­tion of my thinking about this pro­tocol has con­sisted of me squirming out of actu­ally oper­ating infrastructure. I squirm still. My appetite for main­taining a server is infinitesimal. I whine to myself: can’t I just propose some­thing? Do I really have to operate it?

Then, I remember a con­ver­sa­tion with Hannu Rajaniemi about Frankenstein, one in which Hannu lamented the novel’s common por­trayal as a cau­tionary tale about sci­en­tific hubris. In fact, Hannu argued, Frankenstein’s tragic mis­take was not cre­ating the monster. Mary Shelley makes this very, very clear: the great mis­take 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. Data­bases ter­rify me. I’m offline for long stretches of the year. How is this pos­sibly going to work?

Well, here’s an argu­ment for you. Pro­tocols aren’t only for using; they are for imple­menting. That’s part of their value in the world. They sup­port nego­ta­tions between devices, yes — and also con­ver­sa­tions, even games, between people. This has been for­gotten as pro­tocols have gotten more complicated, but when I read the early RFCs, I get it so clearly: pro­tocol as puzzle, argu­ment, joke!

Spring ’83 is very simple, so I hope it might invite imple­mentation, just for fun, in your favorite pro­gram­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 mag­a­zine rack offered as an alter­na­tive to the time­line; on the server side, a fed­er­ated net­work that tries to be more than just a burden to its operators, with an invi­ta­tion to invent and explore.

I’m dis­trib­uting this to you as an RRFFCC, which of course stands for Robin’s Request For Friendly Cri­tique and Comment. For my part, I’ll con­tinue to test my ref­er­ence imple­mentation 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. Doc­u­ments like these give you an oppor­tu­nity to boot some­thing 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 dis­cus­sion all up and down the ladder of abstraction, from the pro­tocol’s broad aims to its spe­cific strategies. Send me a note, [email protected], or pub­lish your thoughts and pass along the link. I’ll add it here.

In another year it will be Spring 2023, the modern internet’s for­tieth birthday. Four decades is nothing — the kind of interval that rolls up neatly for storage, like a pro­jector screen. Spring ’83 is still graspable, in memory and in spirit, and time remains to build a net­work that can take us hap­pily into the 2020s and beyond.

Discussion

After cir­cu­lating this newsletter, I received a ton of ter­rific email correspondence, and sev­eral folks pub­lished 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 cor­ners and edges.

Here’s a wide-ranging consideration from Maya, who main­tains one of the great modern home pages; I am a long­time admirer and reader.

Here are some thoughts from makeworld, com­plete with sug­ges­tions and (very welcome) nitpicks.

And then, what fol­lowed was a season of actu­ally using this pro­tocol. Amazing! I’ll now reflect on … 

The summer of Spring ’83

The first thing to say is, it worked! This doc­u­ment and the related spe­cification inspired a ton of dis­cus­sion. Better yet, they inspired imple­mentation. You’ll find some great work linked in the GitHub project.

(Of par­tic­ular note is Ryan Murphy’s <spring-board> ele­ment, which encap­su­lates a whole Spring ’83 “board”, described above, into a reusable HTML5 Web Component. My web pro­gram­ming skill level is still anchored some­where around 2010, so Ryan’s custom ele­ment 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 oper­ated by dif­ferent 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 pos­sible with 2217 bytes.

My aspi­ra­tional com­par­ison with vin­tage comic books ads — 

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

By any measure: we stood up a pro­tocol.

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

This is fine!

Indeed, I want to make a case for pro­tocols — for whole little social net­works — as inves­ti­ga­tions and experiments. It doesn’t take a mil­lion users, or a thousand, or even a hun­dred, to learn gen­uinely inter­esting and impor­tant things: about the pro­tocols them­selves, 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 some­thing from above: I really strongly rec­om­mend this exer­cise to anyone who feels dis­sat­is­fied with their options on the internet today. Give it a few evenings. Imagine some­thing new; describe it as clearly as you can. You don’t have to actu­ally build your some­thing — you don’t even have to pub­lish your descrip­tion. It’s the imag­ining 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 pro­tocol-spec­i­fiers. 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 fal­tering startup. More to the point, it’s going to be a while before I, personally, do any more devel­op­ment on this pro­tocol, 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 some­thing like it, back into the present tense at any moment.

Here are my notes for fellow travelers.

Your protocol is too complicated

My ini­tial spe­cification of Spring ’83 was, I thought, very simple. Appar­ently not simple enough: in the months fol­lowing its publication, most of my revi­sions were deletions.

Pro­tocol spe­cification 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 mate­rial of both flavors, and it’s pre­cisely that mate­rial that’s now been blasted away.

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

People really want to mention each other

A core part of this pro­tocol’s design is that no mes­sages are ever pushed; you get only what you ask for. As such, the “mention”, as expe­ri­enced on Twitter and Insta­gram, doesn’t exist in Spring ’83. And yet! People still men­tioned each other! The men­tions were makeshift, inert, but they “worked”, because the uni­verse was so small and we were all reading basi­cally all the boards. And even if they didn’t work, the urge was still so strong! Overwhelming.

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

Men­tions 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 some­thing real and true: names have power, and the invo­ca­tion of a name always car­ries an impact. Even when it’s nothing but nice! Like ringing a bell.

I don’t, however, think the solu­tion is a jet cockpit’s worth of access controls. Rather, I suspect there might be some clever new for­mu­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 ver­i­fi­ca­tion. Even as the spec­i­fier of this pro­tocol, the person who brought those tech­niques into it … these keys were totally excruciatingly annoying.

It’s like a bar­gain 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 avail­able in the uni­verse. The price they exact in return is: utter illegibility. A com­plete abdi­ca­tion of aesthetics.

The more you think about it, the fun­nier 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 num­bers tantalizing, but I do not think I will include them in my next pro­tocol.

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 pos­sible way. But some were gonzo, too, and this, more than any­thing, was the tri­umph of the summer of Spring ’83: a chorus of cheers for modern HTML and CSS, and all the ways you can express your­self with them, and in them.

The weak­ness of the pro­tocol, as pre­sented 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 for­bid­ding for everyone else. A better client would pro­vide 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 head­line 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 con­fess that maybe I did.

On this front, I am an evangelist: arbi­trary HTML and CSS should have a place in our social net­works. They are so expres­sive, and they are avail­able 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 pro­tocol 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 pro­tocol’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 com­pul­sion.

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

If only you could bal­ance per­fectly at the summit. Alas, I don’t think it’s pos­sible.

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

So, the par­ti­sans of patience need some new tricks. We need ways of claiming space on screens — asserting the exis­tence of our alter­na­tives — without con­ceding 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) dig­ital dis­tri­b­u­tion channel we can depend on.

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

Who wants to host content? Nobody normal

My little Spring ’83 server has hosted, in total, prob­ably 40 or 50 people’s boards: a minis­cule 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 reac­tion made me realize some­thing:

It takes a weird kind of person to want to host other people’s con­tent.

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

Dig­ital spaces are some­times analo­gized to homes or restau­rants, with the impli­ca­tion that of course you’re free to kick someone out, just as you would in your home or restau­rant. Back before I’d ever hosted any­thing for anyone, I nodded along to this analogy, but now I see that it’s incom­plete, because people only visit your home or restau­rant while you’re there. These real spaces are, by the stan­dards of dig­ital spaces, almost impos­sibly well-mod­erated.

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

Obviously, many people are not so con­cerned about this. The policy of reacting to harass­ment or abuse or vile­ness 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 some­thing had appeared that was actu­ally vile — whew! I don’t know. I’m not cut out for this.

(Who IS cut out for it? Per­haps only the people truly hungry for scale, who can sep­a­rate them­selves from the sys­tems they’re oper­ating. I’m trying not to be too dire and judg­mental here, but honestly, I think it might be inhuman. I think you might have to make your­self into a kind of machine to be okay with “best effort”.)

This sug­gests a challenge: could you design a pro­tocol that truly makes people respon­sible for their own con­tent, elim­i­nating or at least blunting the peril and stress of hosting? That puts us back in the world of “every­body should just host their own con­tent on their own web­site”, 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 avail­able, some repro­duc­tion of that arrange­ment on a dif­ferent level, that could begin to address this challenge.

It’s ironic: in the devel­op­ment of this pro­tocol, I spent more time thinking about abuse than any­thing else, by far. During the summer of Spring ’83, largely by dint of the size (very small) and quality (very high) of the pro­tocol’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 plat­forms 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 cor­po­rate gambits, these dumb proper nouns. The nouns and verbs of our online rela­tion­ships should be lowercase, the way “mag­a­zine” is lowercase, the way “movie” is lowercase. Any­body can make a movie. Any­body can try.

New pro­tocols abound, and more are on their way. In the months and years ahead, as you explore and eval­uate them, I encourage you to ask this question:

Does this pro­tocol recreate some­thing 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 Insta­gram again, just “in a better way” this time. Repeating myself from above: a decen­tral­ized or fed­er­ated time­line is still a time­line, and for me, the time­line is the problem.

This dig­ital 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 what­ever you imagine.

So: imagine!