I've been seeing discussions about a novel proposal for a protocol called Spring '83. It's for sharing 'boards', it's interesting, and I have some commentary, so here goes. But first, a heads-up: I'm no expert on decentralized protocol design. Please read this as impressions from a potential techie user, with a heavy dose of thinking out loud. And if you haven't read the original post on Robin Sloan's blog, it might be better to do that before continuing with this one.^[1]

tl;dr: I really like the idea of the boards and hope it catches on. I dislike the name. And I don't quite get the federated protocol. So here goes.

The boards

I really love the main idea. Everyone getting a board with no history and no external dependencies, potentially viewable separately, or in a 'magazine stand' collage sounds good.

I would maybe prefer if the 'html fragment' was forced to have a single root element. That might make life of anyone handling them much easier, especially if you place multiple boards next to one another.
And I don't get why the boards should have a proscribed aspect ratio, but that's phrased as a recommendation anyway, not a hard rule.

Most of all, I kinda want to build one, and I want to see what other people make even more. So that's always a good sign. I'm on board.^[2]

The name

Let's get the most trivial commentary out of the way first. If I told someone there's this new social/federated thing, and it's called Spring '83, I don't imagine it would arouse much interest. In fact, I have only read any of the related blog posts after stumbling upon the name multiple times. You see, at a first glance, I assumed they would be talking about something that happened in some foreign country 40 years ago. Or about the Java framework, eww. Or maybe reminiscing about the "good" old days of FORTRAN programming.

"A cool idea I might want to use alongside my RSS" decidedly did not cross my mind. (At least when you tell people about RSS for the first time, it registers as "uh-oh, an acronym, sounds like some technical topic is coming up", and not "I haven't even been born back then.").

I don't know what the name should be. Maybe something over-the-top funky. FunkyBoard. Or BoarDOM.^[3][4]

The protocol

This is the part I don't quite get. I do understand the drive to make the BoarDOM Spring '83 network decentralized, federated, distributed. I generally like those things. After all, I'm a big fan of Matrix.^[5] But here it seems like overkill^[6] and I fear requiring a custom server might drive adoption down, especially if you just want to host your own board.

Distributed

I'd say there is a spectrum: On one end, big silos like Facebook, where anyone can easily have an account, as long as they don't mind being in a predatory silo. In the middle are federated services, such as Mastodon and Matrix. And on the other end, things like RSS, which truly are completely distributed, to the point where every site hosts its own feed.

Noteworthy here is the fact that even in distributed services, the network of users is (close to) scale-free. Yes, you can run your own Mastodon, or your own Matrix, but most people don't, and simply create an account on "the default one". It's not as bad as a silo, but it isn't even close to, say, each community running its own instance.

Given the nature of Spring '83, I think it is reasonably possible to get spread on par with RSS. After all, the board itself is a single, tiny HTML file.

Speaking of which...

Tiny

I do agree that having the boards be tiny (and without external resources) is good. However, the 2kB limit seems a bit too stringent. I can hardly imagine the size of the boards being a deciding factor for someone wanting to host their own server; and if it were, they can limit the number of boards they host, right?

On the other hand, it can be quite limiting for someone creating the boards. If I'm a photographer and want my board to be a gallery of thumbnails of my latest 16 photos, I'm out of luck. I think this is a perfectly valid use case, and one conducive to the original post's idea of a newsstand as well. Simply bumping the size limit would enable richer kinds of expression, and I don't think it would be much of a technical issue. Maybe at least 220kB, if we're sticking with the theme of using '22' in all the spec constants. 😁

Alternative distribution channels

I'm getting back to the topic of requiring a federated server network. There might be great reasons for it that I haven't yet understood.

On her blog, Tracy Durnell muses in a similar direction, wondering about the ability to implement the boards as part of the IndieWeb standards. I understand the appeal. But from my perspective, this again might hinder adoption. Overall, I think the IndieWeb is full of great ideas - but the adoption doesn't seem that wide. If you open a Random Joe's blog, chances are it won't be integrated into the IndieWeb. I suspect it's one of those cycles - not many people use it because there isn't widespread support in easily available software; and the support isn't there because not enough people use it/demand it, so the devs don't feel pressured to add those features.

Why not do just what RSS does? You want to expose a board, you host it on your web. Maybe even add a link tag.

Or we could use the .well-known folder. It's a standard place to put site-wide information, so it would match the use-case of having one per person/organization. In case you're not familiar with how that works: you put site-wide data in a folder that you place at your.domain.tld/.well-known, and if some software wants to find out if you support some specific thing, it goes to check to that default location. It's also how federation in Matrix works; if something needs to know where the matrix server for the domain zble.sk is, it goes directly to https://zble.sk/.well-known/matrix/server and checks. It could work exactly the same way for Spring '83.

This, in a way, also circumvents the need for cryptographically verifying the board's provenance: I prove it's the one I mean to share by hosting it on a domain I control.

This, then, might be used by the Spring '83 clients; once you add a list of servers to check, it can go ahead and pull the boards directly.

The specification also says:

[T]he server must not enumerate keys or boards for any requester; the server must only respond to requests for specific keys.

As well as:

The process of discovering a particular publisher's key, or discovering keys to follow generally, is not part of this specification.

However, it is presumed that a home page or profile page might contain a <link> element analogous to the kind used to specify RSS feeds. A client scanning a web page for an associated board should look for <link> elements with the type attribute set to text/board+html.

This basically means that the server won't let me just browse the boards, it only distributes them if I know what to ask for. I still have to go to the publisher's page to get the 'link' to the board, then ask a server to get me that specific board. Why not skip a step and load the board directly from the publisher?

And if we do really insist on using a federated network - why not use an existing one? Again, I'll use Matrix in this scenario - not because I believe it's the right one to use, but simply because it's the one I know the most about. I have played a little with DHT, BitMessage and Scuttlebutt^[7], and the like, but I don't remember enough of them to even try to build an example. So Matrix it is.

From Matrix.org:

Matrix is really a decentralised conversation store rather than a messaging protocol. When you send a message in Matrix, it is replicated over all the servers whose users are participating in a given conversation [...]. There is no single point of control or failure in a Matrix conversation which spans multiple servers: the act of communication with someone elsewhere in Matrix shares ownership of the conversation equally with them. Even if your server goes offline, the conversation can continue uninterrupted elsewhere until it returns.

I think it would be technically feasible to just have one chatroom called "boards," where every user would be allowed to post just one message, with the board attached. To update the board, the user would update the message. The Matrix would then take care of replicating the boards to all other servers that joined the room.

Using Matrix would also let the admins use its tools for moderation and policing. There are some interesting thoughts on that topic and others over at Darius Kazemi's web.

I'm spitballing here, but I think it might work. I'd still prefer the simpler, no-dedicated-server-needed, RSS-like solution though.

Expiration and longevity

Along with the need for dedicated server software, this is one of those parts where I suspect I must've missed something obvious.

The original blog post says:

I want this to work, furthermore, whether those people are sharing a random thought every day, a blog post every week, or an art project every two years.

Then the spec says:

The server must

• enforce a TTL, dropping boards over 22 days old

I'm not sure what the end goal here is. I often enjoy finding some ancient webpage, not updated in years, and going through its archives. What would the harm be in just letting the single static HTML file sit there? Why require frequent intervention just to ensure nothing changes?

But yes, this is a minor quibble.

I guess that about covers it. I'll definitely follow Spring '83's progress to see where it evolves.