Marty McGuire

Posts Tagged webring

Sat May 20

Rebooting πŸ•ΈοΈπŸ’ an IndieWeb webring

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🚭/next can just link to , 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.🚭) 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 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:

You can find the old codebase here:

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).

Tue May 16

Tiny notes as I work on migrating my IndieWeb webring πŸ•ΈοΈπŸ’ to a new tech stack.

Downloading the database from the project’s .data folder was easier than I thought.

I’m also working with a slightly different schema to drop the unmaintainable emoji slugs, so learning the sqlite3 syntax for selectively dumping columns was very helpful!

Still a few rough edges to knock off, mostly around making sure I can successfully fetch folks’ pages and find the webring links on them, but it’s close!

Wed Apr 26

Bad web dev ideas: emoji as IDs in URLs

It's another rambling web dev post sorry not sorry grab a beverage and let's go.

Begin with the Horrible Admission 🀫😳

Rather than make you wait, here it is:

I created and maintain An IndieWeb Webring and it uses emojis as IDs. When you add your site to the webring by signing in, an emoji ID is created for you, and it acts, in some ways, like your username or profile ID.

For example my webring profile is: πŸ•ΈοΈπŸ’.ws/🚯

Hopefully you see the appeal. The webring is on an emoji domain, which I registered at IndieWeb Summit 2018 inspired by something Doug Beal presented. It was soon decided that I must in fact build a webring there and, leveraging his influence as the originator of the idea, Doug insisted that emojis be used as user IDs. Probably because: moar emojis!

Why even have IDs? πŸ›‚πŸ€·πŸ»β€β™‚οΈ

This is a dang good question and I could probably sleep better if I drop them.

Ring-ness and identifying click sources

At the time, the idea was that a webring should be a ring, with adjacency. In other words, if I click the "next site" link on your website, it should consistently go to the same site. If I click the "previous site" link on their site, it should consistently go back to yours. In order to consistently know which site to send them to next, the webring needs to know where you're coming from.

Historically there has been a way to know where a visitor is coming from: the HTTP "Referer" [sic] header. However, at the time (and in the time since) there have been privacy issues around using this header, and it was not uncommon to see sites sabotage this info with purposeful redirects, browser standards were added to allow degrading or removing referrer info, and Chrome even implemented default policies to degrade it.

So the more reliable thing would be to put some identifier in the URL and trust that webring members wouldn't like weirdly spoof one anothers' unique webring URLs.

Profile pages

Another at the time thought was that webring members might want to "prove" that they were on the webring. An active profile page with rel-me verification linking back to their homepage could allow other sites and tools to say "oh hey! you're a member of this webring". Maybe we could show some stats there! At any rate, none of those use cases ever came into existence as far as I know. (Besides, stats are gross.)

Why not use <xyz> as an ID? πŸ€”πŸ’‘

Some things I considered and discarded:

  • Just use the URL. URLs-appended-to-URLs require escaping and sanitizing and this gets ugly and long.
  • Use a hash of the URL. I like this approach (spoiler alert) but even when they are short hashes are also long and ugly.
  • Use a numeric ID like a database row. This would probably be fine but numeric IDs can be easily crawled (fine for a webring I guess??) and people get weird about low ID numbers sometimes (warning: orange site link). Also they are boring.
  • Something more clever. Well, we probably could have but this was a weekend hack kind of project.

The original sin 🍎🐍

There is a fun little NodeJS library called hash-emoji that takes any-ol-thing and gives you back a string of emojis of the length you ask. Under the hood, it uses a strong SHA256 hash in hexadecimal, parses that hexadecimal number, then uses modulo arithmetic to keep adding "digits" just like any hash algorithm, only the "digits" come from a collection of emojis that were in wide use back in 2017 when the library was created.

I alluded to this in my post about adding a directory to the webring in 2019, but slapping a random emoji or two or three on someone's profile is potentially problematic. When some folks pointed out it was odd that they were assigned a country flag for a place they had never been, I cheekily forked hash-emoji to make hash-emoji-without-borders, which is identical in all ways except I pulled out all flags. Now nobody would get a flag!

However, by removing the flags I had shrunk the key space for the emoji hash. It wasn't great to begin with - using one emoji from the initial set of ~1300 was bound to lead to collisions eventually - but by changing the set I felt like I was increasing the likelihood that some new signup would be assigned the same emoji ID as an already existing site in the ring.

So, I bumped the length of new IDs up to 2. And then, after an unrelated change where I started normalizing URLs differently before creating their hash ID, up to 3.

Let me tell you. 3 emoji almost always tell a story. You can't not see them. Sometimes those stories can be problematic! Or maybe it's nice but you don't find it relatable. Or maybe there is no story, per se, but you're assigned something that you object to being associated with, like weapons or kissing faces or drugs and alcohol or religious symbols, or ...

Some folks also ran into issues with the URLs on their web hosting. While I tend to think of the web as being universally UTF-8, that's not necessarily the case. Some hosts would mangle the Unicode URLs, resulting in the webring not being able to find them, resulting in sites being de-listed from the ring. To make it easy for the widest possible of webring users to simply copy their webring links and paste them into their site, I change it to use the %-encoded versions of the emojis. So now my beautiful πŸ•ΈοΈπŸ’.ws/🚯 has become the horrific:

Instead of worrying too much about any of this I just ... left it alone. A few times I received requests for folks who wanted something custom, and sometimes I obliged as long as it was a request for a unique one- or two-emoji ID, so it couldn't collide with someone's future random ID.

Fooling around, finding out πŸ₯«πŸͺ±

I've been low-key working on porting the webring from its old and crumbling NodeJS implementation to (hear me out) PHP (I SAID HEAR ME OUT). The basic idea is to reduce the number of emails I get from GitHub where dependabot reports a vulnerability in this or that dependency-of-a-dependency, and more importantly to reduce the amount of time that updating those dependencies takes by reducing the amount of breakage that occurs. I guess this is me saying that churn among dependencies for NodeJS apps feels more disruptive to me than I expect churn to be for PHP. Please don't @ me. Any way.

hash-emoji is broken

When porting hash-emoji from Javascript to PHP I had some issues where the modulo and division math wasn't working. Turns out SHA256 digests, which are hex-encoded strings 64-characters in length, make for very large numbers when you represent them as numbers to do number math on them. With basic PHP numeric types this was turning up junk, zeroes for every modulo division.

So I tried out both of the main PHP extensions for arbitrary precision math, GMP and BC Math, and got results that were at least functional. However, they weren't the same as the Javascript hash-emoji implementation.

At least, they weren't the same until I updated my copy of hash-emoji to use BigInt to make sure it was doing its arbitrary precision math properly. It was at this point that Javascript hash-emoji now began consistently outputting the same results as my new PHP implementation.

That means the original hash-emoji algorithm, due to some quirks of Javascript Number math for large numbers, gives results that are not consistent with the same algorithm when using arbitrary precision math types.

With my skills I cannot hope to make a PHP port of hash-emoji that produces identically quirky results to the Javascript version, so, it looks like emoji IDs will have to change again.

Considering the abyss βš«πŸ‘€

I thought that, if the emoji ID generation has to change, maybe I can change it for the better? I brainstormed some ideas in the IndieWeb chat. One nice change would be to bring the emoji set up-to-date to at least Unicode 14 (published 2021, implemented widely during 2022). One major unsolved challenge would be to come up with some "unproblematic" set of emojis. For example, modifiers for skin tone and gender are widely supported, even in complex combinations like people kissing.

Thanks to sknebel some helpful suggestions, like generating IDs without skin tone modifiers and stripping out skin tone modifiers before looking up an ID. This would allow webring users to customize any emoji that have skin tone variants. Maybe that could be expanded to customizing more things when there are variants by gender, or complex combinations like family with two adults and two children, if it should come up. A "customize your ID" tool begins to design itself (lol).

sknebel also pointed me to an excellent resource that the Unicode consortium calls the "best definition of the full set [of emoji]" - the emoji-test.txt file. Here's the Unicode 14 emoji-test.txt file. It encodes each emoji in a line-oriented format, organized helpfully into groups and sub-groups like the ones you see on your favorite emoji keyboard.

I could parse this file out into various datasets annotated with their groupings and sub-groupings. Then, I could use those definitions to pull together any combination of (sub-)groupings that I want into different hash-emoji datasets.

I could expand a "customize your ID" tool to allow folks who don't like their initial ID to opt out of any groups they don't want emojis from. I could treat those groupings as a flag set and map that flag set to an emoji to prepend to their ID, so each combination of groups becomes its own key space. Nice!

Reader, let me tell you: I do not want to do all of that.

End with the other Horrible Admission 🀫😏

As implemented, the webring isn't a true ring. Whether a visitor clicks your custom emoji /next link or your custom emoji /previous link, the webring, in fact, sends you to another active site in the ring at random.

So what's next? I think the webring can function fine without these IDs. The copy-paste webring links can become identical for everyone, and the directory, sign-in, and dashboard pages don't make use of them at all. The one exception is individual profile page URLs for member pages, which I think I can safely drop.

What do you think? Are you horrified by any of this? Enraged? Got an ideas I can try instead? Drop me a reply, I'd love to hear from you!

Sat Dec 28

Are you a member of the πŸ•ΈπŸ’ IndieWeb Webring? Today I added a page for Terms of Use and Frequently Asked Questions!

The webring has mostly been churning along on its own, with a few folks adding themselves here and there. A couple of times folks have shown up in IndieWeb chat to let me know about sites that break the webring, or when they ran into other issues.

Hopefully this page answers some of the more common things that come up. The TL;DR version? The webring is more proof-of-concept than robust-community-service. I’ll do my best, but can’t make any promises! πŸ˜…

If you have any questions that aren’t addressed there, please let me know!

Sat Jan 19

An IndieWeb(ring) Directory

Members of the πŸ•ΈπŸ’ IndieWeb Webring now have a new way to find one another, and show off!

Screenshot sample of profiles in this IndieWeb Webring directory including photo, name, URL, and bio note.

That's right, this πŸ•ΈπŸ’ IndieWeb Webring now has a directory showcasing profiles of active sites in the ring! Where possible, it shows name, photo, and short bio in addition to the site's URL (and of course their potentially problematic cute emoji ID).

These profiles are possible when people publish personal particulars on their page as a microformats2 representative h-card.

That is a bunch of jargon, to be sure, but what it means is that you with a few tweaks to your homepage, you can make info like your name, photo, and a bio – which is probably already displayed for people to see – readable by machines that understand microformats2, like this one!

Fated-to-be Asked Questions

How do I get my site to show up in the directory?

Visit the your πŸ•ΈπŸ’ webring dashboard (you'll need to log in) and click the "Check for updated profile" button.

I updated my profile, but it's not working!

Try out your page in the validator. If it shows you that it found a "representative h-card", then your page should work for the webring directory!

Wait a sec, my site is already in the directory!

I went ahead and pre-loaded the profile info for all registered and active sites! I don't plan to do that again.

My site is in the directory but I don't want to be listed!

Sorry about that! You can remove yourself by visiting your πŸ•ΈπŸ’ webring dashboard (you'll need to log in) and click the "Remove my profile" button.

Why did you do this?

I was inspired by Grant's IndieWeb Directory, Aaron's, this πŸ•ΈπŸ’ review by Brad Enslen, and more. Basically: surfing around a webring with next and previous links is good fun, and it's even more fun to see so many folks excited about the IndieWeb in one place!

Is there anything else?

Yes! There are also now individual profile pages, if that's something you want to link to. My webring emoji ID is 🚯, so my profile can be found at: πŸ•ΈπŸ’.ws/🚯

I don't know yet how these pages might evolve so I welcome your feedback!

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).

Sat Sep 29

Are you a member of the πŸ•ΈπŸ’ IndieWeb Webring? Today I made an update!

All members of the webring get a unique emoji ID when they first sign in. Previously, those emoji might have included the flag of a country or state, and not everyone wants to be associated with a random country or state!

From now on, new emoji IDs will not include country flags.

If you’re a member of the webring already, and would like a new emoji ID, feel free to drop me a line in the #indieweb chat (I’m schmarty there). I’ll reset your account and you’ll get a new emoji ID. You’ll also have to update the webring links code on your page to make sure they point to your new ID!

Sun Jul 22

Looks like Aaron Parecki is up to something fun with his new podcast directory-slash-webring.

I went ahead and added This Week in the IndieWeb Audio Edition! Looking forward to seeing more webrings like this bloom throughout the web as a means of discovery.

(and, yes, I very much need to add a few features and post about πŸ•ΈπŸ’.ws here!)