Thoughts on Spring '83
This is as good an excuse as any to dust off the blog, I guess.
Robin Sloan has only come on to my radar quite recently, but I generally like what he's got going on. "Programming equivalent of a home cook" is something I'd love to see more of.
In any case, someone on mastodon started a discussion about Robin's Protocol, Spring '83. This is effectively a response to that, so, go read it first.
Seriously, go read it or much of this won't make sense.
In my opinion, calling it a protocol kind of buries the lede a bit, as it's mostly a proposal for a new form of "social networking" - but I also completely understand why some distance is appreciated there! Social networking is more or less rotten to the core and the whole point of Spring seems to be getting away from precisely that kind of awfulness. Good.
Some gears in the back of my head got turning and a week or so later I've got to write down the result, before it sublimates (as ruminations tend to do).
If you'd like to talk with me about it and you got here somehow other than me linking you, here's where my contact details live.
My TL;DR Understanding of Spring
At its heart, Spring is a federated pull-only network of limited-size html "boards" that can be updated with whatever, whenever, by the owner of the board, the author, over HTTP.
The intended use case is that participants follow however many of these they're interested in, and probably publish their own board. The boards are intended to be viewed as a big mishmash of content as a direct antithesis to the infinite doomscrolling of traditional social media.
It's designed to not require a participant to host their own internet infrastructure through use of public key cryptography. It draws inspiration from early internet development (even down to the name) and intentionally puts a lot of the complexity of use onto the client.
Stuff I Really Like
A big mess of stuff from people and projects I care about, updated whenever? At its core this is just, super appealing.
The pull-only model is a nice change of pace. I imagine folks are going to want to have a conversation about stuff, but there's a lot of ways to do that already! I'd be interested to see what kind of interactions grow out of it. Part blog, part newsletter. Probably a fair bit of subtweeting potential.
The design is federated at its core but doesn't really require a heap of per-community or per user infrastructure. Great for getting started easily. Extra good that it's all interoperable across communities.
Explicitly disconnected realms may reduce the amount of federation "bs" that happens with mastodon all being one enormous happy family, though I wonder a what happens when a few big spring realms inevitably form. Our mastodon instance has a pretty huge blocklist.
"Just" using public key crypto for identity is generally pretty neat, and is something I've wanted to see more folks play around with since I learned about it.
Users picking on their own how much of their "post history" to retain in their board is a really cool thing. Right to be forgotten built in. It's limited by the size of the board currently, but you could in theory be slapping a horizontal rule between thoughts and letting them drop off the bottom into scrollbar oblivion.
In general I want to see more earnest experimentation happen in the ways we connect with each other digitally. I am so sick of the existing patterns. Most of my meaningful enjoyable digital interaction comes through chat platforms these days, rather than "big" social media. So this is super welcome.
Nitpicks and Concerns
I think probably some kind of "identity" to go along with boards will be required in terms of client display. Display Name at the absolute bare minimum; probably icon support would be good as it's another visual cue. "Ah, this is Ben". Maybe it's cool to have 300 different ad hoc forms of "how do you identify whos board this is" appear but... I doubt it, haha. A big long hex hash wont cut it.
The fixed size board footprint is cool but also, it's really small, wow. I think it's based on the size of some historical html page or possibly what you could cram into a datagram, but it seems kind of bonkers in 2022 to swing so, so hard towards a tiny filesize for something which is pull-only. You're opting into following someone, you can unfollow if they post heavy stuff. I guess the majority of bandwidth would be media; if it was allowed, but it also hurts things like say, sharing a bigger recipe or long form posting, especially once you're counting markup.
As a few others have said, the difficulty factor stuff seems a bit arbitrary.
The key rotation thing needs some sort of "moved to" succession built into it at a protocol level, imo, and posting one of those redirects probably needs to be possible after the automatic expiry period so someone can restart an old presence "in band", and be irrevokable once it's done. A board "going dead" after a set time is counter to the idea of infrequent posting being a good thing, IMO. As many folks have pointed out, roughly 50% of publishers needing to restart their board on a single day of the year is going to lead to havoc around that point in time. It's a pain for users who have to "refresh their bookmarks". It seems to need more thinking through.
Moderation will need some sort of approach built in but I'm not sure how best to do it beyond "ban" which is hard to do if they can just gen a new key and get posting again. Maybe it just doesn't matter as much in a pull-only environment though? Hosts could just nuke content violating their ToS, and the author can move to somewhere that will tolerate it (or host their own).
No Media? Big Problem.
No embedded rich media is a huge fatal mistake, IMO. Honestly, I don't care much for expressing myself through custom css and emojis. I think this will be an immediate non-starter for any "normal person", sadly, and is a huge blow for creative folks. Folks who paint and draw want to show you those paintings and drawings. Gamedevs share gifs and videos of what they're working on. Musicians share work in progress tracks. Engineers share project progress shots. Myspace and piczo and the like were interesting cause you could stick pictures together like a weird digital photo album. MSN was fun because of emoticons.
Yes, you can link to media. That's not equivalent, at all. This smells to me like an IRC person saying they don't "get" why the kids prefer discord - it's because it is much more fun and interesting to engage with if you don't have 30 years of habit built up.
On the "tracking pixel" fear; individual posters doing that is relatively harmless, it'd only be a harmful thing if it became widespread and done by the network itself... which it can't be, because of the signed content - would have to be built into the client, which is defeated by competition. And I imagine realms are honestly not going to be that huge that it'd even matter.
I would absolutely expect media support in any client I would actually use day to day or week to week.
Even email has attachments.
Trustless?
I wonder a lot about the server joining being gated behind (modifiable) invite links or similar, rather than the trustless "just gen a keypair that fits the pattern and go" approach. I think it'd probably be better.
Honestly it seems like a huge can of worms to allow anyone to just dump content on your server to be federated across the realm. A normal login page would be fine too but also you don't have to go trustless if the server is able to give out keypairs to implicitly trusted individuals.
Invite systems would be a server side complication, but at their simplest, invite links could have a fixed number boards they'd issue, and an expiry date. They could be generated by trusted individuals of the server, and boards would be linked against the invite link they came from, so a careless leak could be plugged realatively easily.
A big server would have a weekly link on their meta board, and reissue it if more than a thousand folks joined. A small one would share the link in an email or text message or whatever.
Would remove the need for all the difficulty factor stuff too. Support could be built into the protocol, storage requirements are a counter and a set of boards per-link as far as the server is concerned.
I dunno. I think the world could use a little more trust.
Closing Thoughts
I really like the heart of it, honestly.
It's uncannily similar to the "digital gardens" that I've been seeing cropping up on mastodon - literally pages intended to be put in iframes in a grid in a local file for this kind of "what are people working on" overview. A proper protocol and client for that kind of interaction would probably be a better experience for everyone, so we'd see more of it. Sounds nice.