Spring83

A protocol invented by Robin Sloan.

I appreciated Hallie Bateman’s reflections on the challenges of sharing art on Instagram circa 2022:... a fundamental property of digital media is slipperiness. Different platforms are different kinds of slippery at different times. Instagram is presently: extremely slippery — squirming its way out of all its old contracts and expectations, struggling to become something basically unrecognizable to its longtime users. Bummer

Here is my proposal for a new protocol, one that might open up some interesting new possibilities on the internet

Whether or not my proposal goes anywhere, I want to report that I found writing in this way — imagining in this way — both challenging and energizing, and I’d recommend it to anyone

Specifying Spring '83

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

Near the end of last year, I asked myself: What do you want from the internet, anyway?

• I want to follow people who are interesting to me
• whether those people are sharing a random thought every day, a blog post every week, or an art project every two years.
• across media

Hrm, I think his solution

• takes on other requirements not noted above, some of which aren't explicit
• which otherwise could have been solved by a FriendFeed-like model
• reducing the likelihood of adoption (because a person/publisher would need to update their Board separately from their other process, and there's a whole critical-mass issue).

“Surely,” you say, “either Twitter, RSS, or email must suffice.”

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.

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

RSS is too stark

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

• this reminds me of (2021-08-20) Sloan Whomst Styles

Email is a retreat. You probably reached this web page through an email. Whew! It worked! The thing is, email inboxes have been algorithmic for a long time, and publishers struggle with Gmail’s caprice almost as much as they do Instagram’s

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 dissembling a bit. The truth is, I reject Twitter, RSS, and email also because … I am hyped up to invent things!

The crucial spark was RFC 865, published by the great Jon Postel in May 1983

RFC 865 describes a Quote of the Day Protocol

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 opportunities and excitements of this global machine

Spring ‘83 is a protocol for the transmission 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

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

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 update your board twice an hour or twice a month; you might amend one sentence or reboot the whole thing

This is a “pull-only” protocol

Boards can’t load tracking pixels, and they can’t ping remote analytics APIs.

how can a network that abjures all these dark patterns possibly grow? The only possible answer is: I don’t know

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

Boards are cryptographically signed

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 Mazières’s 2000 Ph.D thesis.

So … who runs these servers?

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.

Spring '83

This is a draft protocol

A demo server is operating at https://bogbody.biz,

A demo client, The Oakland Follower-Sentinel, is also available for inspection.

Here are the implementations I know about currently:

Spring '83

Each publisher maintains just one board. There is no concept of a history; think instead of a whiteboard that is amended or erased.

Publishers -- who might be people, computer programs, or anything else -- are identified and authorized by keypairs on the Ed25519 curve

Keys are globally unique, and they act as "coordination-free" identifiers, similar to UUIDs. Publishers don't need to register with any central authority

The use of keys for identification and authorization is, like many features of this protocol, motivated by a desire to keep implementation easy and stateless. Who wants to manage a complete login system?

Spring '83 is an HTTP API over TLS

The protocol imposes a format requirement on keys. The content of Ed25519 keypairs is mostly random, so conforming keys can only be generated by trial and error.

Using a single thread in an Apple M1 chip, this is accomplished in tens of minutes. Using many threads, it is accomplished in minutes, not seconds.

The date "encoded" in those final four characters has teeth: the key is only valid in the two years preceding it, and expires at the end of the last day of the month specified

Much of the burden of the protocol falls on the client: to store a user's keypair securely, allow them to manage a collection of followed board URLs, and display boards safely.

The prohibition against images and other external resources is a matter of privacy, safety, and charisma.

*The client must:

reject boards larger than 2217 bytes verify each board's cryptographic signature situate each board inside its own Shadow DOM*

Discussions

1: Inspirations

*most of all,

from the Quote of the Day Protocol, defined by Jon Postel in May 1983: the vision of simplicity*

2: The agony and ecstasy of public key cryptography

the certainty that a user will eventually lose their secret key.

The compromise is mandatory key rotation, enforced with the expiration policy.

Spring Memo: Realms

Here's a dream: to be able to summon a board not with a URL, but merely with a key, conjuring its bytes from -- where? From abstract boardspace!

Spring '83 clients and servers are not required to implement this, or any other, Memo. The Memos should be considered a toolkit of ideas and extensions; many will be published and never implemented.

This Memo defines the realm, a set of servers whose operators have agreed to (1) circulate new boards, and (2) honor a shared denylist.

A server participating in a realm must retrieve the JSON document and cache it, updating it weekly.

Within a realm, servers share new boards using a gossip algorithm.

When a board is published to a server participating in a realm, the board is circulated throughout the realm. Subsequently, the board can be requested from any server in the realm, and it can, within the context of that realm, be identified with a key alone.

GitHub - robinsloan/the-oakland-follower-sentinel: A demo Spring '83 client.

The Oakland Follower-Sentinel is a demo Spring '83 client that you can try on the web at followersentinel.com or run locally on your computer

If you press Esc, an editor will appear. It's here that you can add, remove, and re-arrange Spring '83 URLs and RSS feed URLs. The client will save these changes to your browser's localStorage, so there is a fair chance your changes will still be there when you return. There you go: a super simple way to follow a collection of boards and feeds.

Perhaps you'd like to publish a board of your own. To "unlock" the client's publishing panel, you'll need a keypair that conforms to the Spring '83 specification. In the client, you'll find a link to a page where you can generate one.

Running the client locally You can totally do this, too. Just clone the repository and run: ruby serve.rb

Then, visit http://localhost:8000/ and things should work normally.

In additional to HTML, you can compose your board in Markdown.