Robin Sloan
the lab
November 2022

Specifying Spring ’83

What fol­lows is a nar­ra­tive descrip­tion of a new pro­to­col. I circulated it in June 2022, and it received a warm, engaged response.

Following sev­eral months of devel­op­ment and exploration, I wrote some reflections, which are appended below, in the sec­tion recount­ing the sum­mer of 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 wait­ing.

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.

That’s not the only prob­lem. 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 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 Twit­ter’s design as sen­si­ble and try to imple­ment it “bet­ter”. (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 prob­lem.

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 kind of con­tent; so RSS can­not 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­rith­mic for a long time, and pub­lish­ers strug­gle 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 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 requirements, while also sup­port­ing new inter­ac­tions, new ways of relat­ing, 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 connection (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.

A line of green herbs that seem to grow out of a fold in the ground, or the paper; they are simple and tender and very appealing.
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 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 cur­rent 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 writ­ing!

I want to say: I rec­om­mend 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 writ­ing. 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 — 

Classifieds

—and vin­tage comic books ads — 

Comic book ads

—and mag­a­zine racks:

Newsstand

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, lay­ing them out on a 2D canvas, pro­duc­ing unplanned juxtapositions, just like the news­stand above. Boards might be:

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 sep­a­rately; 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:

💌 Recs welcome!

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 prob­lem: 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 rela­tion­ships. 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 … what­ever!

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­mendations, 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 num­bers. In 2022, they are not help­ful feed­back, but rather a clear warn­ing you are in the wrong place.

This raises the question, 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.

Three figures in elaborate patterned outfits, dancing merrily, each kinda doing their own thing.
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 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 operate 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.

A simple figure walking peacefully along the raised border between two fairly abstracted fields; one is yellow, another green, the third pink.
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, robin@robinsloan.com, 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 inter­net’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 a net­work that can take us hap­pily into the 2020s and beyond.

A jovial figure wearing a tall hat, using a broom to sweep away dry red leaves.
Flowers of a Hundred Worlds: Court Guard, 1868-1912, Kamisaka Sekka

Discussion

After cir­cu­lat­ing this newslet­ter, I received a ton of ter­rific email correspondence, and sev­eral folks pub­lished their thoughts online.

Here’s a pub­lic 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­est­ing cor­ners and edges.

Here’s a wide-ranging consideration from Maya, who main­tains one of the great mod­ern 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 sea­son of actu­ally using this pro­to­col. 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. Bet­ter yet, they inspired imple­mentation. You’ll find some great work linked in the GitHub project.

(Of par­tic­u­lar note is Ryan Murphy’s <spring-board> element, 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 cus­tom 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 hand­ful of servers oper­ated by dif­fer­ent people. And people crafted those boards! Some were blog posts by another name, oth­ers glit­ter­ing CSS confections. Peo­ple wrote poems for their boards; peo­ple probed the lim­its of what’s pos­si­ble with 2217 bytes.

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

Comic book ads

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

By any measure: we stood up a pro­to­col.

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

This is fine!

Indeed, I want to make a case for pro­to­cols — for whole lit­tle 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­est­ing and impor­tant things: about the pro­to­cols them­selves, about new ways of relat­ing online, about peo­ple in all their glorious weirdness.

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

First, though, I want to repeat something from above: I really strongly rec­om­mend this exer­cise to any­one who feels dis­sat­is­fied with their options on the inter­net today. Give it a few evenings. Imag­ine something 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­in­ing and the describing, the chal­leng­ing work of express­ing your dreams and desires clearly, that turns out to be use­ful and bracing … and fun!

Now, here are a few jot­ted findings, left as notes along the path for future protocol-spec­i­fiers. This is all writ­ten in the past tense, which isn’t totally correct; some peo­ple, includ­ing me, are still using my demo client! But the present tense would feel too much like the forced cheer of a fal­ter­ing startup. More to the point, it’s going to be a while before I, per­sonally, do any more devel­op­ment on this pro­to­col, or another one like it.

So, for me, the past tense is appropriate — but that’s not to say some­one 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 sim­ple enough: in the months fol­lowing its pub­lication, most of my revi­sions were deletions.

Protocol spe­cification plays into two key weak­nessess of many technical peo­ple:

  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 fla­vors, and it’s pre­cisely that mate­r­ial that’s now been blasted away.

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

People really want to mention each other

A core part of this pro­to­col’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 Twit­ter and Insta­gram, doesn’t exist in Spring ‘83. And yet! Peo­ple 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 read­ing 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.

Mentions seem sim­ple, but I think they’re hugely fraught, and not only when they become a vec­tor 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 noth­ing but nice! Like ring­ing 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 wait­ing to be discovered … 

Public keys are a demon’s bargain

Spring ‘83 uses pub­lic key cryp­tog­ra­phy for user iden­ti­fi­ca­tion and ver­i­fi­ca­tion. Even as the spec­i­fier of this pro­to­col, the per­son who brought those tech­niques into it … these keys were totally excruciatingly annoying.

It’s like a bar­gain out of a fable. Pub­lic key iden­ti­fiers give you all these incred­i­ble 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­to­col.

Three cheers for HTML and CSS

You would not BELIEVE the boards peo­ple made. Not all were gonzo; many were sober, very clear and “designer-y”, in the best pos­si­ble way. But some were gonzo, too, and this, more than any­thing, was the tri­umph of the sum­mer of Spring ‘83: a cho­rus of cheers for mod­ern HTML and CSS, and all the ways you can express your­self with them, and in them.

The weak­ness of the pro­to­col, as pre­sented in my demo client, was that you could only design your board by writ­ing raw HTML and CSS. That’s fine for the nerdi­est among us, but still a bit for­bid­ding for every­one else. A bet­ter client would pro­vide built-in templates, maybe a lit­tle WYSI­WIG editor — you can imag­ine this easily.

For my part, I settled on a sim­ple design: a blood-red head­line in 72-pixel italic Bodoni over an acid green background. Some­one said to me, not a lit­tle 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 protocol with a slower cadence. Indeed, after the summer’s flurry of activity, I’m now updat­ing 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 strug­gled with this myself. Even dur­ing the sum­mer, in the pro­to­col’s fullest bloom, I would for­get about my demo client for days! A week! It just did not — could not — set up that sense of twitchy com­pul­sion.

Platform design seems to me now like a sharp hill­top with steep slopes descend­ing in both directions. A platform built around twitchy com­pul­sion will trend towards addiction; a plat­form built around stolid patience will trend towards … for­getting about it.

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

The prob­lem is that even when patience “wins”, it loses, because patience retreats, while compulsion compounds. What do I mean? Over the years, I’ve bro­ken many of my twitchi­est com­pul­sions, and I’m much bet­ter 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 read­ing 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 claim­ing space on screens — asserting the exis­tence of our alter­na­tives — without con­ced­ing an inch to the twitchosphere. Email works, of course; it’s likely you’re read­ing this newslet­ter because of an email. I just think there ought to be more than one (1) crusty dig­i­tal dis­tri­b­u­tion chan­nel we can depend on.

This is totally doable; these new tricks need only to be invented. Per­haps repurposed!

Who wants to host content? Nobody normal

My lit­tle Spring ‘83 server has hosted, in total, prob­a­bly 40 or 50 peo­ple’s boards: a minis­cule bur­den, by any standard. But I report to you truth­fully that this was, for me, a source of incred­i­ble stress, all sum­mer long. My reac­tion made me realize some­thing:

It takes a weird kind of per­son to want to host other peo­ple’s con­tent.

Like, it’s kind of insane! Host con­tent for peo­ple who you don’t KNOW? And take on, perforce, either (a) the oblig­a­tion to mod­er­ate it upfront, “read­ing every­thing”—impos­si­ble — or (b) the bur­den of know­ing you didn’t, so those weirdos could be out there post­ing any­thing, right now?

Digital spaces are some­times analo­gized to homes or restaurants, with the impli­ca­tion that of course you’re free to kick some­one out, just as you would in your home or restaurant. Back before I’d ever hosted any­thing for any­one, I nodded along to this anal­ogy, but now I see that it’s incom­plete, because peo­ple only visit your home or restau­rant while you’re there. These real spaces are, by the stan­dards of dig­i­tal spaces, almost impos­si­bly well-mod­er­ated.

That’s what made my stom­ach churn: the real­ity that I’m not always, or even usually, at my com­puter.

Obviously, many peo­ple are not so con­cerned about this. The pol­icy of react­ing 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 truly 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 hun­gry for scale, peo­ple who can sep­a­rate them­selves from the sys­tems they’re oper­at­ing. I’m try­ing not to be too dire and judg­men­tal 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­to­col that truly makes people respon­si­ble for their own content, elim­i­nat­ing or at least blunt­ing 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 peo­ple have been say­ing is nec­es­sary 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 anal­ogy avail­able, some repro­duc­tion of that arrange­ment on a dif­fer­ent level, that could begin to address this challenge.

It’s ironic: in the devel­op­ment of this protocol, I spent more time think­ing about abuse than any­thing else, by far. Dur­ing the sum­mer of Spring ‘83, largely by dint of the size (very small) and qual­ity (very high) of the pro­to­col’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 per­son 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­ish­ing places it hasn’t reached in ages.

But we, as users of the global inter­net, can­not just ride the same roller­coaster again. It’s too embar­rass­ing to be trapped inside these hun­gry 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. Anybody can make a movie. Any­body can try.

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

Does this pro­to­col recre­ate 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 Twit­ter or Tum­blr or Insta­gram again, just “in a bet­ter way” this time. Repeat­ing myself from above: a decen­tral­ized or fed­er­ated timeline is still a timeline, and for me, the time­line is the prob­lem.

This dig­i­tal medium remains liq­uid, protean, full of potential. Even after a decade of stasis, these pixels, and the ways of relat­ing behind them, will eagerly become what­ever you imag­ine.

So: imag­ine!

November 2022, Oakland