https://www.robinsloan.com/lab/specifying-spring-83/

Home About New: Shadow Planet From: Robin Sloan
To: the lab
Sent: June 2022

Specifying Spring '83

What follows is a narrative description of a protocol that I believe
might open up some interesting new possibilities on the internet. My
goal here isn't to "sell you" on its design; rather, I just want to
lay out my thinking as clearly as I can.

It's okay to share this link, but I want to underscore that I am send
ing it specifically to you with the hope that you will ... really think
about it! At such a primordial stage, a proposal like this doesn't
need diffuse, drive-by attention. It needs, instead, close considera
tion and generous imagination.

If you are returning to this newsletter after reading it once before,
don't miss the growing discussion.

Since mid-June, a ton of great work has percolated; you'll find much
of it linked in the GitHub project.

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 interesting to me, in a way
    that's simple, expressive, and predictable.

  * I want this to work, furthermore, whether those people are shar
    ing 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 sufficiently simple, expressive,
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 conviviality might be organized. Look
    at these screens, this wash of pixels, the liquid potential! What
    a colossal bummer that Twitter eked out a local maximum; that its
    network effect still (!) consumes the fuel for other possibili
    ties, other explorations.

This means I'm uninterested in the projects that accept Twitter's
design as sensible and try to implement it "better". (I'm thinking of
Mastodon, Scuttlebutt, and Bluesky.) A decentralized or federated
timeline is still a timeline, and for me, the timeline is
the problem.

RSS is too stark. I follow a lot of RSS feeds, and I appreciate them,
and I almost want to leave it at that; nothing's more boring than
re-litigating RSS. I will just observe that there is something about
this technology that has seemed, over the years, to scold rather than
invite; enclose rather than expand; and strip away rather than
layer upon.

For my part, I believe presentation is fused to content; I believe
presentation is a kind of content; so RSS cannot be the end of
the story.

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

For me, the recent resurgence of the email newsletter feels not much
like a renaissance, and more like a massing of exhausted refugees in
the last reliable shelter. I'm glad we have it; but email cannot be
the end of the story, either.

I'm dissembling a bit. The truth is, I reject Twitter, RSS, and email
also because ... I am hyped up to invent things!

So it came to pass that I found myself dreaming about designs that
might satisfy my requirements, while also supporting new interac
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 Pro
tocol:

    A server listens for TCP connections on TCP port 17. Once a
    connection is established a short message is sent out the con
    nection (and any data received is thrown away). The service
    closes the connection after sending the quote.

That's it. That's the protocol.

I read RFC 865, and I thought about May 1983. How the internet might
have felt at that moment. Jon Postel maintained its simple DNS by
hand. There was a time when, you wanted a computer to have a name on
the internet, you emailed Jon.

There's a way of thinking about, and with, the internet of that era
that isn't mere nostalgia, but rather a conjuring of the deep opportu
nities and excitements of this global machine. I'll say it again.
There are so many ways people might relate to one another online, so
many ways exchange and conviviality might be organized.

Spring '83 isn't over yet.

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: successful request to server, cryptographic verifica
    tion in browser, and display, on Sun April 24 at 3:42 pm.

Spring '83 is a protocol for the transmission and display of some
thing 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 transmission 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, expressive,
and predictable.

Here's the current draft specification. I hope it is legible to the
spec-readers among you; this is, I have discovered, a really diffi
cult kind of writing!

I am not sharing, at this time, code for a client or server, although
I have reference implementations of both that I'm testing with a cou
ple of friends. I'll post them on GitHub eventually ... but I think
there's something interesting, maybe useful, about approaching this
first as a discussion. Perhaps it leaves a little more space, here at
the start, for imagination.

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

Update: I've now posted a simple demo client. There are a few server
implementations brewing, too! The ones I know about are listed here.

Before I go further, I want to say: I recommend this kind of project,
this flavor of puzzle, to anyone who feels tangled up by the present
state of the internet. Protocol design is a form of investigation and
critique. Even if what I describe below goes nowhere, I'll be very
glad to have done this thinking and writing. I found it challenging
and energizing.

Display

On the client side, Spring '83 rejects the timeline and the inbox,
aspiring instead to the logic of newspaper classifieds -- 

Classifieds

--and vintage comic books ads -- 

Comic book ads

--and magazine racks:

Newsstand

A touch of chaos? Yes. More importantly, every board holds its place,
regardless of when it was last updated. Each publisher maintains just
one; there is no concept of a history. Think instead of a whiteboard
that is amended or erased, or a magazine replaced with the
new edition.

Client applications display all the boards you are following
together, laying them out on a 2D canvas, producing unplanned
juxtapositions, just like the newsstand above. Boards might be:

  * mini home pages, updated regularly with new work
  * lists of links to web pages recently read, perhaps with brief
    notes
  * daily logs, wiped clean each morning
  * yawlps to the universe

Some boards will be baroque CSS confections, others a sentence and a
link in the system font, still others blaring <h1>s. Some publishers
will be friends, others anonymous geniuses, still others robots.
You'll follow and unfollow publishers with a simple interface defined
by the client, not the protocol.

Spring '83 clients combine following and publishing. A board isn't a
project you manage separately; it's a chunk of HTML you edit right
there alongside the others, perhaps assisted by a simple template.

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

Just finished Ways of Being, the new Bridle book. What a
kaleidoscope. The material on alternative approaches to computing,
including liquid computers (!), was fascinating.

Previously:

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

 Recs welcome!

Or with one like this:

This book is so good it's making me mad

Hmm, nice gradient. I could use one of those. No problem: clients
always support View Source.

You might update your board twice an hour or twice a month; you might
amend one sentence or reboot the whole thing. Publishing a new ver
sion is instantaneous, as easy as tapping a button. You don't have to
manage a server to publish a board; you don't even have to establish
an account on a server.

Spring '83 doesn't formalize interactions and relationships. The pro
tocol doesn't provide any mechanism for replies, likes, favorites,
or, indeed, feedback of any kind. Publishers are encouraged to use
the full flexibility of HTML to develop their own approaches, invit
ing readers to respond via email, join a live chat, send a
postcard ... whatever!

This is a "pull-only" protocol. As a user, you don't see anything you
didn't specifically ask to see; no notifications, no recommendations,
no unsolicited messages.

There are no analytics, obviously. Nothing is counted. Boards can't
load tracking pixels, and they can't ping remote analytics APIs.
Sorry, folks ... you've got to let go of the numbers. In 2022, they are
not helpful feedback, but rather a clear warning you are in the
wrong place.

This raises the question, how can a network that abjures all these
dark patterns possibly grow? The only possible answer is: I don't
know! Maybe we'll figure it out together.

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 transmission 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 cryptographically signed in such a way that they can
    be passed from server to server and, no matter where your client
    gets a copy of a publisher's board, you can be assured it
    is valid.

The underlying cryptography is simple, totally off the rack, but
still, every time I think about it, I'm astonished it works. Because
publishers are identified by public keys, and because their boards
are signed using those same public keys, the publisher/board link is
"self-certifying", a term gleaned from David Mazieres's 2000 Ph.D
thesis.

In a self-certifying system, content carries its own durable
provenance, allowing a network of servers to share it between them,
and if one or two or a hundred are malefactors bent on deception, who
cares? They can't fool us.

So ... who runs these servers?

A large fraction of my thinking about this protocol has consisted of
me squirming out of actually operating infrastructure. I squirm
still. My appetite for maintaining a server is infinitesimal. I whine
to myself: can't I just propose something? Do I really have to
operate it?

Then, I remember a conversation with Hannu Rajaniemi about
Frankenstein, one in which Hannu lamented the novel's common por
trayal as a cautionary tale about scientific hubris. In fact, Hannu
argued, Frankenstein's tragic mistake was not creating the monster.
Mary Shelley makes this very, very clear: the great mistake was
abandoning him.

Fine, okay, I get it! And yet: the last thing I want to do is start
an internet business, even a cute, "sustainable" one. Databases ter
rify me. I'm offline for long stretches of the year. How is this pos
sibly going to work?

Well, here's an argument for you. Protocols aren't only for using;
they are for implementing. That's part of their value in the world.
They support negotations between devices, yes -- and also conversa
tions, even games, between people. This has been forgotten as proto
cols 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 implementation,
just for fun, in your favorite programming language, on your weirdest
device, with plenty of elbow room for experimentation 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 lightweight HTML magazine
rack offered as an alternative to the timeline; on the server side, a
federated network that tries to be more than just a burden to its
operators, with an invitation to invent and explore.

I'm distributing this to you as an RRFFCC, which of course stands for
Robin's Request For Friendly Critique and Comment. For my part, I'll
continue to test my reference implementation with a very small group
of people. I'm in no great rush with this -- which is a new feeling
for me.

It was the experience of drafting the spec that changed my view, and
my pace. Writing! Gets you every time! It also helped me understand
the appeal of the crypto white papers, honestly. Documents like these
give you an opportunity to boot something up in your head, examine it
in a way that's technical, sure, but also literary, imaginative,
maybe even dreamlike ... I don't know; I like it!

Anyway ... I wonder if you might want some of the same things from the
internet that I do. I wonder if you, too, might be hyped up to invent
things. If so, I invite discussion all up and down the ladder of
abstraction, from the protocol's broad aims to its specific
strategies. Send me a note, 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 forti
eth 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.

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

I have received a ton of terrific email correspondence -- thank you!

Here's a public consideration from Darius Kazemi, who has

    some experience reviewing RFCs, as I did a yearlong blog project
    where I wrote about each of the first 365 RFC documents.

What amazing context. As I mentioned above, I found the particular
genre of the RFC, or RFC-alike, extremely challenging (not in a bad
way); so, feedback from someone who "knows from RFC" couldn't be more
welcome or useful. As you'll see, Darius's notes have a lot to do
with clarity, the "why" alongside the "how".

Here are some musings from Tracy Durnell, focused on design, which is
fantastic. It's helpful to see her think through a few ways that
Spring '83 might connect to existing web technologies.

Here are some notes and questions (fronted by a very kind meme) from
Louis Potok, who traces the spec's logic into a few interesting cor
ners and edges. I feel like Louis's post is perfectly in the spirit
of this document; it's like, "RFC? OK! C!"

Here's a wide-ranging consideration from Maya, who maintains one of
the great modern home pages; I am a longtime admirer and reader. It's
so useful -- and energizing! -- to absorb comments that take the feel
ings of/in a system so seriously.

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

June 2022, Oakland

I'm Robin Sloan, a fiction writer. You can subscribe to my lab
newsletter here:

[                    ] [Subscribe]
This website doesn't collect any information about you -- not even
basic analytics. It aspires to the speed and privacy of the
printed page.

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