Note: this is a first draft specification published in June 2022. You can find a narrative description of the protocol, and my contact information, in this newsletter.
Note also: this draft has been superceded by the June 16 version, which will be superceded in turn. But we are winding our way towards something final-ish...
Spring '83 is a protocol that allows users to follow publishers on the internet -- who might be people, computer programs, or anything else -- in a way that's simple, expressive, and predictable.
The basic unit of the protocol is the board, which is an HTML fragment, limited to 2217 bytes, unable to execute JavaScript or load external resources, but otherwise unrestricted.
Each publisher maintains just one board. There is no concept of a history; think instead of a whiteboard that is amended or erased.
Spring '83 aspires to be:
Simple. This means the protocol is easy to understand and implement, even for a non-expert programmer.
Expressive. This means protocol embraces the richness, flexibility, and chaos of modern HTML and CSS. It does not formalize interactions and relationships into database schemas.
(It also means the protocol 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, inviting readers to respond via email, join a live chat, send a postcard... whatever!)
Predictable. This means boards holds their place, maintaing a steady presence. It means also that clients only receive the boards they request, when they request them; there is no mechanism by which a server can "push" an unsolicited board.
In addition, Spring '83 is
Federated. This means it spans a network of servers operated by different people. The protocol is not, however, "trustless"; in Spring '83, connection requires conversation.
Although the transmission portion of the protocol operates over HTTP/1.1, its approach to HTML storage is very different. Rather than store different boards on different servers, Spring '83 stores ALL the boards on EVERY server. The network converges to a consistent global state -- eventually; maybe -- using a simple gossip algorithm.
Spring '83 draws inspiration from many existing protocols and technologies; you can read about these in Discussion 1.
The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC 2119.
https://www.ietf.org/rfc/rfc2119.txt
board: a fragment of HTML -- not necessarily a valid HTML5 document -- not more than 2217 bytes long, encoded in UTF-8.
publisher: the entity responsible for specifying a board's content.
key: a public key on the Ed25519 curve, formatted as 64 hex characters.
signature: a public key signature, formatted as 128 hex characters.
client: an application, web or standalone, that publishes, retrieves, and displays boards.
server: an application, reachable on the public internet using a domain name, that receives, stores, and provides boards.
peer: another server.
difficulty factor: a server's current requirement for new keys
realm: a set of peers, listed together in a YAML document reachable on the public internet. The default realm is defined at TKTK.
Publishers (who might be people, computer programs, or anything else) are identified and authorized by keypairs on the Ed25519 curve. The public part of the keypair, formatted as 64 hex characters, is the publisher's identifier, used to request their board from any available server. The secret part of the keypair allows the publisher alone to edit their board.
Each keypair corresponds to exactly one board. Again, there is no concept of a history; think instead of a whiteboard that is amended or erased.
Because a publisher is identified by their public key, boards are easy to verify. When a client requests a board for a particular key, the server might send an incorrect or modified response -- appending an advertisement, perhaps -- but the client will detect the invalid signature, drop the board, and mark the server as untrustworthy.
See Discussion 2 for a consideration of the benefits (substantial) and drawbacks (likewise) of keypair identity schemes.
Keys are generated randomly, but they must fit a particular format; this functions as a simple Hashcash variation, providing a rudimentary form of abuse mitigation. Concocting a compatible key isn't instantaneous; it takes between a few seconds and a few minutes on modern hardware.
To be used in Spring '83, a key's final six hex characters must match this regex:
/ed[0-9]{4}$/
Furthermore, the final four characters, interpreted as a decimal number, must fall in the range 2022 .. 2099.
That number has teeth. Keys are only valid in two calendar years: the year specified in their final four digits, and the year previous. For example, the key
1c6ffef2825b294274478bad8c80a7a610d38245a9fded18cd004c4a67ed2023
is valid between 2022-01-01T00:00:00:00Z and 2023-12-31T23:59:59Z.
In this way, a key's final four characters represent its "expiration date".
This requirement makes key rotation mandatory over the long term. Clients may implement features that make the process more convenient, but the recurring "stress test" on the publisher-follower link is a feature, not a bug. The goal is to keep Spring '83 relationships "live" and engaged, rather than weigh publishers down with zombie followers.
(TKTK is this too much? I like it, but...)
Much of the burden of the protocol falls on the client: to make requests on the user's behalf, store keypairs securely, and display boards safely.
The client must:
- limit incoming boards to 2217 bytes
- validate each board's cryptographic signature
- situate each board inside its own Shadow DOM
The client must not:
- execute any JavaScript included in the board
- load any images, media, or fonts linked by the board
These two requirements should be satisfied with a Content Security Policy.
The client should:
- allow users to manage a collection of followed keys
- display each board in a region with an aspect ratio of either 1:sqrt(2) or sqrt(2):1
- make available to boards the Spring '83 suite of CSS variables, listed in TKTK
- open links in new windows or tabs
Other than the byte-size threshold and a timestamp requirement discussed below, Spring '83 places no limitations on the HTML content of a board. Knowing that the client will not execute JavaScript, publishers will probably not want to spend their precious bytes on inert code... but they are free to do so.
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
Beyond the standards described above, Spring '83 doesn't specify how the client should display boards. For example, the client may:
- allow users to explore overflowing boards by scrolling
- apply post-processing effects to boards (e.g., a limited color palette)
- organize boards according to an abstruse algorithm
- handle links to Spring '83 keys in a helpful way
Publishers should expect their boards to be placed on a 2D canvas alongside many others.
Spring '83 servers are, in operation, very similar to "plain old web" servers, with a few additional behaviors.
The server must
- maintain a persistent store of boards
- enforce a TTL, dropping boards over 28 days old
- share newly-received boards with peers
The transmission portion of Spring '83 operates over HTTP/1.1, using TLS, so it can be implemented easily using existing tools.
A Spring '83 server must respond at the following HTTP endpoints:
PUT /<key>
GET /
GET /<key>
A server that provides boards to browsers will also need an appropriate OPTIONS endpoint to satisfy CORS, but that's not part of this specification.
It's a pretty small API surface! We'll go through the endpoints one by one.
To publish a board, a client must send a request of this form:
PUT /<key> HTTP/1.1
Content-Type: text/html;charset=utf-8
Spring-Version: 83
If-Unmodified-Since: <date and time in HTTP format>
Authorization: Spring-83 Signature=<signature>
<board>
Upon receipt, servers should validate the non-cryptographic part of the PUT request immediately, and, if necessary, respond with an error code.
If the board is larger than 2217 bytes, the server must reject the request with 413 Payload Too Large.
The client must include the publishing timestamp in the If-Unmodified-Since header. If this value is older or equal to the timestamp of the server's version of the board, the server must reject the request with 409 Conflict.
The If-Unmodified-Since header is transmitted as a convenience, to allow the server to "fail fast" if the request is out of date. However, because it's not cryptographically signed, the server can't rely on it entirely.
The client must also include a last-modified meta tag in the board's HTML:
<meta http-equiv="last-modified" content="<date and time in HTTP format>">
It's important that the timestamp is transmitted this way, because it needs to be signed along with the rest of the board's HTML. The client may add the meta tag automatically, just before signing and transmitting the board.
The server must reject the PUT request, returning 400 Bad Request, if
- the board is transmitted without a last-modified meta tag; or
- it is transmitted with more than one last-modified meta tag; or
- its last-modified meta tag isn't parsable as an HTTP-format date and time; or
- its last-modified meta tag is set to a date in the future.
These criteria are EXTREMELY important. The last-modified meta tag modulates a board's change over time; if it gets screwed up, the publisher could lose the ability to update their board.
The server must verify that <signature> is a valid signature for the entire request body, exactly as transmitted. If the board isn't signed properly, the server should reject it, returning 401 Unauthorized.
If the current four-digit year is YYYY, and the previous four-digit year is YYYX, the server must only accept PUTs for keys that end with the four digits YYYY or YYYX, preceded in turn by the two hex digits "ed". This is the years-of-use requirement.
The server must reject other keys with 400 Bad Request.
Additionally, if the server doesn't have any board stored for <key>, then it must apply another check. The key, interpreted as a 256-bit number, must be less than a threshold defined by the server's difficulty factor:
MAX_SIG = (2**256 - 1)
key_threshold = MAX_SIG * ( 1.0 - difficulty_factor)
This check is not applied to keys for which the server already has a board stored. You can read more about the difficulty factor later in this document.
Spring '83 specifies a test keypair:
public: fad415fbaa0339c4fd372d8287e50f67905321ccfd9c43fa4c20ac40afed1983
secret: a7e4d1c8be858d683ab9cb15574bd0bc3a87e6c846cdaf848da498909cb574f7
Servers must not accept PUTs for this key, returning 401 Unauthorized. (See the section detailing GET /<key>, below, for more guidance.)
The server may also use a denylist to block certain keys, rejecting all PUTs for those keys.
If all the preceding checks are met, the server must store the board and share it with peers.
A realm is a set of Spring '83 servers, specified by a YAML document reachable on the public internet. (The format of this document is TKTK.) There is no automatic or "trustless" way to join a realm; as with BGP, the foundational routing protocol of the internet, you gotta talk to somebody!
Within a realm, Spring '83 servers communicate directly with each other, sharing new boards using a simple gossip algorithm. Their aim is to converge on a shared state of the realm, each server's copy exactly the same. In the froth of real activity, that will never actually happen -- but we can get pretty close.
After receiving and verifying a new board from a client, the server must share it with N peers selected randomly from the realm. N is
min(round(total_peer_count * 0.5), 5)
New boards should be transmitted to peers asynchronously. The server must wait at least five minutes before sharing, but it may wait longer. In this way, the server acts as a buffer, absorbing and "compacting" rapid PUTs.
To share a board with a peer, the server must transmit a PUT request similar to the one described above. Note the addition of the Prefer: respond-async header:
PUT /<key> HTTP/1.1
Content-Type: text/html;charset=utf-8
Spring-Version: 83
Prefer: respond-async
If-Unmodified-Since: <timestamp>
Authorization: Spring-83 Signature=<signature>
<board>
When the server receives a PUT with the respond-async preference, it should respond immediately with 202 Accepted and place the board into a queue for asynchronous validation. (If the server doesn't have a task queue, it may respond synchronously.)
If a peer is not reachable or responds with an error code, the server must wait for a minimum timeout of 5 minutes before attempting to contact that peer again. If the peer is still not reachable, the server must apply jittered exponential backoff, calculating each new timeout in this way:
new_timeout = current_timeout + current_timeout * random(0.0 .. 1.0)
The server should cap this timeout at some maximum; 7 days is recommended.
The server must store boards with a TTL. One week is recommended; the maximum TTL is 28 days.
The server must provide identical responses to requests for
<key A>, for which it once stored a board, now deleted, and<key B>, for which it never stored any board.
Finally, the server must not enumerate keys or boards for any requester; the server must only respond to requests for specific keys.
Disk space is a concern for a protocol that allows anyone on the internet with a trivially-concocted cryptographic key to store a chunk of data, "for free", on a network of servers. Accordingly, a Spring '83 realm is limited to 10 million boards, for a maximum possible disk size of 22.17 gigabytes. (Ambitious servers might keep the whole thing in RAM!)
This limit is enforced through a difficulty factor that draws inspiration from the mining difficulty factor used in many cryptocurrencies.
Spring '83's difficulty factor ranges from 0.0 to 1.0, calculated in this way:
difficulty_factor = ( num_boards_stored / 10_000_000 )**4
(TKTK is that the right exponent? Explain it, I suppose.)
In normal operation, the server's difficulty factor is very close to 0.0, and boards for new keys are freely accepted. As the difficulty factor rises, the concoction of a suitable key becomes more time-consuming for prospective publishers. This has the effect of both (1) slowing the introduction of new keys, and (2) dissuading some publishers entirely.
When the server's database maxes out at 10 million boards, the difficulty factor is 1.0, and the server does not accept any boards for keys it doesn't already know.
Let's consider the example of a server that is already storing 8.5 million boards.
difficulty_factor = ( 8_500_000 / 10_000_000 )**4 = 0.52
Using that difficulty factor, we can calculate the key threshold:
MAX_KEY = (2**256 - 1)
key_threshold = MAX_KEY * ( 1.0 - 0.52 ) = <an inscrutable gigantic number>
The server must reject PUT requests for new keys that are not less than <an inscrutable gigantic number>.
A client should determine a server's current difficulty factor using a request of this form:
GET / HTTP/1.1
Spring-Version: 83
The server's response must take the form:
HTTP/1.1 200 OK
Content-Length: <length>
Content-Type: text/html;charset=utf-8
Spring-Version: 83
Spring-Difficulty: <difficulty factor>
<arbitrary HTML greeting>
Using that information, the client can choose either to spend the time required to concoct a suitable key... or give up, and perhaps try another time.
Servers are not obligated to provide this endpoint for all requesters; they might provide it only to users of a particular client, or only to users who have paid for access, or according to any other scheme. Such schemes are beyond the scope of this specification, which describes the behavior of a publicly-available server.
To retrieve the board for <key>, a client must choose one or more servers to which it has access and transmit a request of this form:
GET /<key> HTTP/1.1
Spring-Version: 83
If-Modified-Since: <HTTP formatted timestamp>
If the server has a board for <key> but it is not newer than the timestamp specified in If-Modified-Since, it must respond with 304 Not Modified.
If the client omits If-Modified-Since, the server should return whatever board it has for <key>, if it has one.
The server's response must take the form:
HTTP/1.1 200 OK
Content-Length: <length>
Content-Type: text/html;charset=utf-8
Spring-Version: 83
Authorization: Spring-83 Signature=<signature>
<board>
The client must verify that the <signature> is valid for <key> and <board> before processing or displaying the board. If the signature is not valid, the client must drop the response and remove the server from its list of trustworthy peers.
(TKTK clients should assist servers with out-of-date boards.)
Spring '83 specifies a test keypair:
public: fad415fbaa0339c4fd372d8287e50f67905321ccfd9c43fa4c20ac40afed1983
secret: a7e4d1c8be858d683ab9cb15574bd0bc3a87e6c846cdaf848da498909cb574f7
Servers should respond to GETs for this key with an ever-changing board, generated internally, with a timestamp set to the time of the request. This board is provided to help client developers understand and troubleshoot their applications.
- 400: Board was submitted with impromper meta timestamp tags.
- 401: Board was submitted without a valid signature.
- 404: No board for this key found on this server.
- 403: Board was submitted for a key that does not meet the difficulty factor.
- 409: Board was submitted with a timestamp older than the server's timestamp for this key.
- 513: Board is larger than 2217 bytes.
This protocol draws inspiration
- from Secure Scuttlebutt: the power of cryptographic keypairs as identities
- from Hashcash: the notion of guarding server resources with client puzzles
- from Ethereum: the gonzo strategy of storing the whole universe in one place
- from ZeroTier: the spirit of "decentralize until it hurts, then centralize until it works".
and, most of all,
- from the Quote of the Day Protocol, defined by Jon Postel in May 1983: the vision of simplicity
For those not familiar: QOTD operates over both TCP and UDP; the server responds to a TCP connection or a UDP datagram with a single brief message.
In fact, I very badly wanted Spring '83 to operate over UDP -- responding to a request with, in some cases, a single datagram packet: beautiful -- but the architecture of the modern internet makes that much more difficult today than it was in 1983, and, anyway, there's a universe of capable tooling for HTTP.
So, not without regret, Spring '83 goes with the flow.
There are a lot of reasons NOT to use cryptographic keypairs as identities, not least of which: the certainty that a user will eventually lose their secret key.
But the profound magic trick of the signature: that it allows a piece of content to flow around the internet, handed from peer to peer, impossible to tamper with... it's too good to pass up.
And the way public key cryptography allows anyone to "join" the system, without registering anywhere, simply by generating an appropriate keypair -- again, it's a trick so good it seems like it shouldn't work.
The trapdoor function at the heart of public key cryptography is mirrored in the trapdoor of its user experience: once a secret key is lost or compromised, the identity is done. Game over. The system offers no customer support, because the system is math, and all the angels are busy assisting other callers.
It's one of the harshest if/thens in all of computing, and a steep price to pay for the magic trick. Spring '83, given its other priorities and constraints, is willing to pay that price -- but only barely.
The compromise is mandatory key rotation, enforced with the years-of-use requirement. This policy suggests, "you're going to lose your private key eventually... why not lose it now?" and uses that loss as a mechanism to strengthen, rather than weaken, the network.
Beyond that, there is plenty of space for Spring '83 clients to offer hosted ("custodial") private keys, abstracting the keypair behind a more traditional username/password.