Earlier in the year, Amy Cheng twote thus, and I was immediately wracked by an ache of nostalgia:

I finished the first pass at creating webrings using 2019 technology!
Check it: webring-2020.glitch.me 
Source code: glitch.com/edit/#!/webrin …
I still have some code clean-up and documentation to write but I'm shipping it anyway.

— Amy (@am3thyst) January 23, 2019

There's a name I haven't heard in years

Webrings are (were) in essence linked lists of websites who have chosen to associate under a common topic: hobbies, fandoms, etc. If you, perhaps, found yourself on a fan site that you liked, you might have scrolled to the bottom to find a rectangular embed that linked forward and backward through a list of separate but related websites who shared a theme. In a time before search engines capable of crawling 100s of millions of URLs, it was a way to distribute visibility to tiny niche websites that wouldn't otherwise be indexed.

The decline of webrings is documented in What Ever Happened To Webrings? (Hover), chronicling webring.org's acquisition and utter mismanagement by Yahoo! I honestly had no idea that webrings were pioneered by a single company (though people hosted their own home grown rings too).

All this old internet tech hits me in the gut with memories and longing, but there was something off about this feeling: I never actually used a webring, either as a member or a visitor. Why was I feeling this pull?

I spent a precious few pre-2000 years on the Internet, mostly posting info I gathered about hacking Command & Conquer game files and reading racy anime fanfics. Notably, I wasn't part of any community. At a time when other kids were making long-distance friends, and (privileged, internet-enabled) young queers were tentatively taking the first steps figuring their shit out, I was just kind of passing through and posting to an ISP-provided url that nobody visited.

I think that's what was so off, and in fact painful, about this nostalgia: it's memory of something missed out on, even though it was staring me in the face the entire time.

Believe it or not, I actually meant for this to be a short technical blog post and project retrospective, so let's get to that

Inspired by Amy's creation, I decided to attempt to make my own. My driving design decision was to use Jekyll as a static site generator on GitHub Pages. This has a number of advantages.

  • GitHub based forking and hosting

    A Jekyll site is seamlessly hosted by GitHub Pages, automagically supplying a URL and building the site with each update. It also brings along PRs as the canonical "request membership" step, and forking as a way to spin up one's own webring.

  • Each site is one entry in a Jekyll collection

    Aside from filename collisions, this eliminates merge conflicts when two people make a pull request that adds something to the end of the same list.

    This is also intended to ease admin duties, making the act of accepting a submission a matter of clicking "Merge", rather than manually placing the new site oneself.

  • One unique static embed page for each site

    Each site embeds its own unique page, with its next and previous links precomputed. This removes the need for either JavaScript or a dynamic webserver.

But it also comes with some complications.

  • Membership via pull requests still isn't accessible

    It requires a GitHub (or GitLab, etc) account, so the "PR to add a site" workflow still has barriers to outsiders.

    It should be possible to set up a 3rd party form that automates signup PRs by triggering a githook, but it doesn't meet my desire for "fork and change files" to be the only steps required to spin up a new working webring.

  • Jekyll is just really annoying to develop for

    Jekyll is big and complex. As a webring admin, your initial setup only consists of changing a few files and resetting the repo's list of sites, but actually updating the site generator to do other more interesting things is unintuitive. In my opinion.

  • Jekyll can't output multiple files from a single input

    Ideally a single sitename.yml should create both sitename.html for use in an iframe, and a sibling file sitename.json to be used in a hypothetical XHR-based implementation for members who'd prefer that. But as it currently stands, Jekyll maps exactly one input file to one output, and there's no getting around that.

The end result

Emotionally speaking, the end result was a whole lot of mixed feelings about online adolecence and fabricating a lost youth you never had, and wow I didn't see the queer symbolism coming when I hit rightclick->new file this morning.

In terms of tangible output, though, the code is here github.com/toomanybees/ring, the hosted ring is here toomanybees.github.io/ring, and the hosted embed is this:

This is no better or worse than Amy's prototype on Glitch. Both are hosted by social coding sites that offer one-click forking/remixing and seamless hosting without needing to set up a domain. Both are static so they don't need a dynamic webserver.

I think I prefer the near total lack of JavaScript in my implementation, but that's a personal preference of someone who doesn't run untrusted JS in their browser and chooses to not visit sites if it takes too many whitelisted domains to get them to work. :shrug emote:

And as a static site generator, Jekyll is too much overkill for a project this simple. Amy's implementation on Glitch is clearly more accessible to not-super-technical people, just owing to how few files there are to edit. Jekyll was chosen mostly for seamless GitHub Pages publishing. But its lack of plugin support on that platform makes some of the more interesting things (like publishing a static json api alongside html files) out of reach.

Webrings as community (or: why this is not one)

I have recently become enamored of the idea of teaching technical literacy, and I hope that's what this project (and Amy's, and other "click to remix your own working micro-community" apps) helps to do.

It's tempting to think of it this way, but this will never be a safe home for the marginalized communities that Facebook and Tumblr outlawed on their platforms, because GitHub and Glitch are still corporate entities under threat of SESTA/FOSTA and whatever terrible laws the EU decides to enact.

But hopefully the increasing number of do-it-yourself codebases can expose otherwise non-technical people to software deployment, such that when it's time for them to create their own communities, they have the experience to make better informed decisions.

Sorry, I have no idea where I was going with this story. But '90s social tech is neat.