Are you a member of the 🕸💍 IndieWeb Webring? Today I swapped out the underlying codebase. Don't worry about it!
Nothing to worry about??
Okay, okay, there are some changes that you might notice!
RIP emoji IDs
I wrote about why I think emoji IDs ended up being a bad idea.
This webring is about personal sites and uses IndieAuth for sign-in. So, I decided to lean into the IndieAuth philosophy "End-Users [...] are all represented by URLs". If your entry on the ring is already identified by your site's URL, there's no need for an extra identifier, emoji or not.
You'll notice this change in a couple of ways:
- You don't need to put your emojis in your previous/next links to the webring. So, a link to https://xn--sr8hvo.ws//🚭/next can just link to https://xn--sr8hvo.ws/next , no problem. You can update them directly on your site, or visit your webring dashboard to copy-and-paste them again. But! I'll also more-or-less keep supporting URLs with the old emoji IDs, so feel free not to worry about it.
- Emoji IDs no longer appear on the webring directory. We don't have them, so there's nothing to show! The rest of your profile info should still appear as before.
RIP webring profile pages
One reason I adopted emoji IDs in the first place was to allow profile pages to exist without having to figure out a scheme for encoding your URLs in the webring's URLs. I still don't want to solve that problem! So, the old profile pages at your emoji ID (e.g. https://xn--sr8hvo.ws/🚭) are just not there anymore.
But to be clear: profiles are not gone! They still exist in the webring directory. You can still update or remove your profile via your dashboard page as before!
A new codebase, eh?
The first version of this webring was slapped together over a weekend. It was a proof-of-concept and, honestly, was intended to be a way to experiment with how IndieWeb building blocks might support and extend the idea of a webring. I used the excellent Glitch.com and their NodeJS-based Express template app as a way of "sketching with code", getting something up and running fast, and working in the open where I could invite others to collaborate.
However, I don't work with that stack on a regular basis! So as time went on, and dependencies inevitably churned, I found it harder and harder to come back and make updates quickly.
I've ported the codebase to PHP because I, without citation, feel like a lot of the functionality I was relying on slowly-drifting libraries for in NodeJS is built directly into PHP or implemented via agreed-upon interfaces that shouldn't change out from under me as I apply the inevitable security updates.
Similarly, the IndieAuth stuff for the NodeJS version was really banged-together (by me) and was now out of date with the specification. I had never been that comfortable with my implementation, and moving to PHP where there is a larger set of well-maintained (by other people) IndieWeb building blocks feels like a stabilizing one.
(I'm also using the webring and other IndieWeb projects I maintain to sharpen the tools and smooth the edges on a lil framework for making IndieWeb web apps, shh, keep it on the down-low.)
You can find the new codebase here: https://git.schmarty.net/schmarty/gem-diamond
You can find the old codebase here: https://github.com/martymcguire/indiewebring.ws
Is that all?
It is not! I am hoping this can be a nice solid base for tackling some long-standing issues and requests for improvements.
Can I ask you a different question or give you feedback?
Of course! Please do! You can reply to this post on your own site or via Twitter, or feel free to drop me a line in the #indieweb chat (I’m `schmarty` there).
