Specifying Spring '83From: Robin Sloan
To: the lab
Sent: June 2022

Specifying Spring ‘83

Provocation

Near the end of last year, I asked myself:

What do you want from the inter­net, anyway?

Somewhat to my surprise, I found an answer waiting.

• I want to fol­low peo­ple who are inter­est­ing to me, in a way that’s sim­ple, expres­sive, and predictable.

• I want this to work, furthermore, whether those peo­ple are shar­ing a ran­dom 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 fol­low writers, musicians, programmers, theorists, troublemakers … 

Pretty basic! And yet, noth­ing on the inter­net presently allows me to do this — not in a way that’s suf­fi­ciently sim­ple, expres­sive, and predictable.

“Surely,” you say, “either Twit­ter, 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 fol­lower, you mostly encounter the users who are speak­ing nonstop. In my mem­ory, Twitter was once a gen­er­ous router of attention, with an ecol­ogy friendly to links; as the years have ticked by, the cir­cle has tightened, and today, Twit­ter points mostly into itself.

There are other problems. As I wrote earlier:

There are so many ways peo­ple might relate to one another online, so many ways exchange and con­vivi­al­ity might be organized. Look at these screens, this wash of pixels, the liq­uid potential! What a colos­sal bum­mer that Twit­ter eked out a local max­i­mum; that its net­work effect still (!) con­sumes the fuel for other pos­si­bil­i­ties, other explorations.

This means I’m unin­ter­ested in the projects that accept Twit­ter’s design as sen­si­ble and try to imple­ment it “better”. (I’m think­ing of Mastodon, Scuttlebutt, and Bluesky.) A decen­tral­ized or fed­er­ated timeline is still a timeline, and for me, the time­line is the problem.

RSS is too stark. I fol­low a lot of RSS feeds, and I appreciate them, and I almost want to leave it at that; noth­ing’s more bor­ing than re-litigating RSS. I will just observe that there is some­thing about this tech­nol­ogy 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 pre­sen­ta­tion is a form of con­tent; so RSS can­not be the end of the story.

Email is a retreat. You prob­a­bly reached this web page through an email. Whew! It worked! The thing is, email inboxes have been algo­rith­mic for a long time, and pub­lish­ers strug­gle with Gmail’s caprice almost as much as they do Instagram’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 newslet­ter feels not much like a renaissance, and more like a mass­ing of exhausted refugees in the last reli­able shelter. I’m glad we have it; but email can­not be the end of the story, either.

I’m dis­sem­bling a bit. The truth is, I reject Twit­ter, RSS, and email also because … I am hyped up to invent things!

So it came to pass that I found myself dream­ing about designs that might sat­isfy my require­ments, while also sup­port­ing new inter­ac­tions, new ways of relating, new aesthetics. At the same time, I read a ton about the early days of the inter­net. I devoured oral histories; I dug into old pro­to­cols.

The cru­cial spark was RFC 865, pub­lished by the great Jon Pos­tel in May 1983. The mod­ern TCP/IP inter­net had only just come online that January, can you believe it? RFC 865 describes a Quote of the Day Pro­to­col:

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

That’s it. That’s the pro­to­col.

I read RFC 865, and I thought about May 1983. How the internet might have felt at that moment. Jon Pos­tel main­tained its sim­ple DNS by hand. There was a time when, you wanted a com­puter to have a name on the inter­net, you emailed Jon.

There’s a way of think­ing about, and with, the inter­net of that era that isn’t mere nostalgia, but rather a con­jur­ing of the deep oppor­tu­ni­ties and excite­ments of this global machine. I’ll say it again. There are so many ways peo­ple might relate to one another online, so many ways exchange and con­vivi­al­ity might be organized.

Spring ‘83 isn’t over yet.

Flowers of a Hundred Worlds: Seven Herbs of Early Spring, 1868-1912, Kamisaka Sekka

Protocol

From my lab notebook:

FIRST LIGHT: suc­cess­ful 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­to­col for the trans­mis­sion and dis­play of some­thing I am call­ing a “board”, which is an HTML fragment, lim­ited to 2217 bytes, unable to exe­cute JavaScript or load exter­nal resources, but oth­er­wise unrestricted. Boards invite pub­lish­ers to use all the rich­ness of mod­ern HTML and CSS. Plain text and blue links are also enthusiastically sup­ported.

The trans­mis­sion side of the pro­to­col is a tiny HTTP/1.1 API; the dis­play side is a simple set of rules. Put together, they help users fol­low pub­lish­ers — who might be peo­ple, com­puter programs, or any­thing else — in a way that is (you guessed it) sim­ple, expres­sive, and predictable.

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

I am not shar­ing, at this time, code for a client or server, although I have ref­er­ence imple­mentations of both that I’m test­ing with a cou­ple of friends. I’ll post them on GitHub eventually … but I think there’s some­thing inter­est­ing, maybe useful, about approach­ing this first as a dis­cus­sion. Per­haps it leaves a lit­tle more space, here at the start, for imagination.

Also gives me a chance to avoid the really ruinous errors.

Before I go further, I want to say: I recommend this kind of project, this fla­vor of puzzle, to any­one who feels tan­gled up by the present state of the inter­net. Pro­to­col 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 think­ing and writing. I found it chal­leng­ing and energizing.

Display

On the client side, Spring ‘83 rejects the time­line and the inbox, aspir­ing instead to the logic of news­pa­per classifieds — 

—and vin­tage comic books ads — 

—and mag­a­zine racks:

A touch of chaos? Yes. More importantly, 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, lay­ing them out on a 2D canvas, pro­duc­ing 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
• yawlps to the universe

Some boards will be baroque CSS confections, others a sen­tence and a link in the sys­tem font, still others blar­ing <h1>s. Some pub­lishers will be friends, others anony­mous geniuses, still oth­ers robots. You’ll follow and unfol­low pub­lish­ers with a sim­ple inter­face defined by the client, not the pro­to­col.

Spring ‘83 clients com­bine fol­lowing and pub­lishing. A board isn’t a project you man­age separately; it’s a chunk of HTML you edit right there along­side the oth­ers, per­haps assisted by a sim­ple template.

You might react to a book with a board like this:

Just fin­ished Ways of Being, the new Bri­dle book. What a kaleidoscope. The mate­r­ial on alter­na­tive approaches to computing, includ­ing liq­uid com­puters (!), was fascinating.

Previously:

• The Mountain in the Sea
• Frankenstein audiobook
• A truckload of Edgar Allan Poe

💌 Recs wel­come!

Or with one like this:

This book is so good it's mak­ing me mad

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­lish­ing a new ver­sion is instantaneous, as easy as tap­ping a button. You don’t have to man­age 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­mal­ize inter­ac­tions and relationships. The pro­to­col doesn’t pro­vide any mech­a­nism for replies, likes, favorites, or, indeed, feed­back of any kind. Pub­lish­ers are encour­aged to use the full flex­i­bil­ity of HTML to develop their own approaches, invit­ing read­ers to respond via email, join a live chat, send a postcard … whatever!

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

There are no analytics, obviously. Noth­ing is counted. Boards can’t load track­ing pixels, and they can’t ping remote ana­lyt­ics APIs. Sorry, folks … you’ve got to let go of the numbers. In 2022, they are not help­ful feed­back, but rather a clear warn­ing you are in the wrong place.

This raises the ques­tion, how can a net­work that abjures all these dark pat­terns pos­si­bly grow? The only pos­si­ble answer is: I don’t know! Maybe we’ll fig­ure it out together.

Flowers of a Hundred Worlds: Dancing, 1868-1912, Kamisaka Sekka

Transmission

Let’s turn to the server side. The trans­mis­sion pro­to­col, a tiny HTTP/1.1 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 mat­ter where your client gets a copy of a pub­lisher’s board, you can be assured it is valid.

The under­ly­ing cryptography is sim­ple, totally off the rack, but still, every time I think about it, I’m aston­ished it works. Because pub­lish­ers are iden­ti­fied by public keys, and because their boards are signed using those same pub­lic 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 sys­tem, con­tent car­ries its own durable provenance, allow­ing 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 think­ing about this pro­to­col has con­sisted of me squirm­ing out of actu­ally oper­at­ing infrastructure. I squirm still. My appetite for main­tain­ing a server is infinitesimal. I whine to myself: can’t I just propose some­thing? Do I really have to oper­ate it?

Then, I remember a con­ver­sa­tion with Hannu Rajaniemi about Frankenstein, one in which Hannu lamented the novel’s com­mon por­trayal as a cau­tion­ary tale about sci­en­tific hubris. In fact, Hannu argued, Frankenstein’s tragic mistake was not cre­at­ing the monster. Mary Shel­ley 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 inter­net business, even a cute, “sustainable” one. Data­bases ter­rify me. I’m offline for long stretches of the year. How is this pos­si­bly going to work?

Well, here’s an argument for you. Pro­to­cols 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 peo­ple. This has been for­got­ten as pro­to­cols have got­ten more complicated, but when I read the early RFCs, I get it so clearly: pro­to­col as puzzle, argu­ment, joke!

Spring ‘83 is very sim­ple, so I hope it might invite imple­mentation, just for fun, in your favorite pro­gram­ming language, on your weird­est device, with plenty of elbow room for exper­i­men­ta­tion and innovation.

And one of the inter­est­ing things about Spring ‘83 is that when you oper­ate a server, you get a uni­verse for free.

With any kind of fed­er­ated pro­to­col, the ques­tion arises, where is stuff stored? How do you know what’s where? Spring ‘83 adopts a gonzo strat­egy cribbed from the blockchains: every­thing is everywhere.

For the blockchains, this strat­egy is a creep­ing vexation, as their ledgers grow with­out bound. Spring ‘83 makes a dif­fer­ent choice from the get-go, adopt­ing a “deflationary pub­lishing policy”, cap­ping the size of the net­work at 10,000,000 boards. (Remember that a board can be edited over and over, so this is like say­ing there can be, at most, 10 mil­lion mag­a­zines on the rack. There’s more nuance to this limit, which you can find in the spec.)

Ten mil­lion boards gives us a max­i­mum disk space require­ment of 22.17 gigabytes, eas­ily stored on a com­mod­ity hard drive or a cheap-enough cloud volume. A capa­ble com­puter could even hold that in RAM. Turns out, when you don’t store every user’s entire history, plus a record of every adver­tise­ment they’ve ever seen, your data­base 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 for­ward them along to their peers using a gos­sip algo­rithm described in the spec. Even this require­ment isn’t exacting; Spring ‘83 tol­er­ates downtime. Servers can conk out and return. They can take Mondays off.

Beyond the require­ment to share? A server might sup­port one or more client appli­ca­tions, pro­vid­ing boards for dis­play; that would be a rea­son­able thing to do. A server might, alter­na­tively, pur­sue its own projects. Maybe it wants to scan boards and pro­duce a report of top links across the whole net­work. Maybe it wants to mon­i­tor the behav­ior of its peers, ensur­ing they’re fol­low­ing the rules. Maybe it wants to cal­cu­late algo­rith­mic “who to fol­low” rec­om­men­da­tions and offer them to any­one who might be interested.

My hope is that “all the boards” could become an inter­est­ing, tractable sub­ject for exper­i­men­ta­tion.

Flowers of a Hundred Worlds: Spring Field, 1868-1912, Kamisaka Sekka

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 bur­den to its operators, with an invi­ta­tion to invent and explore.

I’m dis­trib­ut­ing 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 peo­ple. I’m in no great rush with this — which is a new feel­ing for me.

It was the expe­ri­ence of draft­ing 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, exam­ine 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 inter­net 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 lad­der of abstraction, from the pro­to­col’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 mod­ern internet’s for­ti­eth birthday. Four decades is noth­ing — the kind of inter­val that rolls up neatly for storage, like a pro­jec­tor screen. Spring ‘83 is still graspable, in mem­ory and in spirit, and time remains to build an inter­net that can take us hap­pily into the 2020s and beyond.

Flowers of a Hundred Worlds: Court Guard, 1868-1912, Kamisaka Sekka

Discussion

I have received a ton of ter­rific email correspondence — thank you!

Here’s a pub­lic con­sid­er­a­tion from Dar­ius Kazemi, who has

some expe­ri­ence review­ing RFCs, as I did a year­long blog project where I wrote about each of the first 365 RFC documents.

What amaz­ing context. As I mentioned above, I found the par­tic­u­lar genre of the RFC, or RFC-alike, extremely chal­leng­ing (not in a bad way); so, feed­back from some­one who “knows from RFC” couldn’t be more wel­come or useful. As you’ll see, Dar­ius’s notes have a lot to do with clarity, the “why” along­side the “how”.

Here are some musings from Tracy Durnell, focused on design, which is fantastic. It’s help­ful to see her think through a few ways that Spring ‘83 might con­nect to exist­ing web technologies.

Here are some notes and ques­tions (fronted by a very kind meme) from Louis Potok, who traces the spec’s logic into a few inter­est­ing cor­ners and edges. I feel like Louis’s post is per­fectly in the spirit of this document; it’s like, “RFC? OK! C!”

June 2022, Oakland

I'm Robin Sloan, a fic­tion writer. You can sub­scribe to my lab newslet­ter here:

This web­site doesn’t col­lect any infor­ma­tion about you — not even basic ana­lyt­ics. It aspires to the speed and pri­vacy of the printed page.

Don’t miss the colophon. Hony soyt qui mal pence