The foundation of a flexible, good IndieWeb website is markup (the "M" in HTML!") that doesn't drive you batty to debug and CSS that works with it to have it look, sound, and interact how you want, whatever device or format the website is displayed on.
I'm going!
Couldn’t stay for the whole thing, but enjoyed sitting in on my first Front End Study Hall (FrESH). Kudos to Joe for building such a great event! Looking forward to joining again.
The post does a great job linking to and summarizing a spate of posts that I
will call “people being mad at the IndieWeb”, while also being one of these posts.
These posts accuse “the IndieWeb” of being elitist, exclusionary,
overengineered, complicit, and unnecessary, among many other things.
There are some common threads I noticed among these posts:
They seem to attack a “straw person” version of the IndieWeb, where one is
expected to read, follow, and implement over a decade of experimentation on the web.
Micro.blog is real
Folks that would like to try a turnkey website hosting service, where:
you bring your own domain (or register a new one!)
you can leave and take your content with you whenever you want
requires no coding (and no plugins to configure, and no “files and folders”)
offers mobile and desktop apps that let you post (and read) the kinds of content you want
supports IndieWeb building blocks to let you follow and interact with other
people via your own websites
I don’t see eye-to-eye with its creator Manton Reese about everything, but
micro.blog is a great example of a real world service that makes use of IndieWeb
building blocks in ways that customers benefit from without having to build
anything!
The rest is wiki
I think many of other complaints, from being “overengineered” to (paraphased)
“POSSE makes IndieWeb complicit with the corporate web”, come from misconstruing
the IndieWeb wiki at indieweb.org as the entirety of
“being IndieWeb”.
When I discovered indieweb.org (in maybe 2015?) I was intrigued and nearly
instantly overwhelemed. Trying to absorb all the concepts there would
be nearly impossible. Understanding and implementing all the techniques there is
actually impossible.
That’s because indieweb.org is not a presciption or a cookbook or
an exercise plan. It doesn’t tell you how to “be IndieWeb”. It’s a collective
memory of experiments, some successful and some not, from a group of
experimenters that has changed greatly over time.
For example, I find that criticisms like “f*ck the corporate web and f*ck
IndieWeb for interoperating with the corporate web” don’t really hold up when
a lot of that stuff doesn’t even work anymore.
On corporate complicity
Automatic POSSE, syndicating posts from your own
site out to your profiles on social silos, only ever barely (and briefly)
worked for Instagram, was turned off for Facebook a few years ago, and was all
but destroyed for Twitter shortly after its last acquisition. backfeed -
pulling comments and likes from these platforms to display on your own site -
has similarly been blocked by technical measures.
These were experiments that worked for a time. People used them for a time. That
time has passed and the people have moved on.
Some folks have replaced their Twitter usage with something like Mastodon, or
Blue Sky, or Threads, and amazing people like Ryan have
stepped up to help experiment with bridging personal sites and federated services.
There is no “the way”, only “your way”
People don’t have to move on for purely technical reasons. Even before
Twitter closed their APIs, many in the IndieWeb community were shuttering their
Twitter accounts and removing posts. They moved on from Twitter, despite all
those documented pages on the IndieWeb wiki, because they didn’t want to use
the web this way anymore.
And to me, this is actually what “being IndieWeb” or “doing IndieWeb” is
about: using the web in ways that fit your wants and needs, being mindful of
when (and to whom) you give up control over your stuff and your connections.
Figuring out how you want to use the web is a daunting task, to say the least!
The IndieWeb wiki is full of interesting examples and ideas - but as a logbook
of ways of using the web, it can be inscrutable. It was never intended that
every way of using the web would be suitable for everyone. A collective memory
is extremely hard to keep up-to-date and to signpost for navigation. Trying to
rely on the wiki alone is a recipe for frustration.
I freely admit that the community has fallen into some serious prescriptive
traps over time. Like with tools like indiewebify.me
that offer a checklist of implementation details, without accompanying reasons
why you might want these features.
This isn’t the first time this has happened, by any means, and it won’t be the
last, but the criticisms of these tools and models do make their way back into
the collective memory. (see: generations
and IndieMark)
Talk with us
That’s why the IndieWeb chat exists. It’s a
place where real actual people, who are working to use the web in ways that
suit them, are ready to help in whatever ways we can. We love to share what is
(and is not) working for us, what we’re trying, and so on. More importantly, we
want to help you find ways of using the web that work for you.
Are you a member of the 🕸️💍 IndieWeb Webring? Or have you wanted to be, but you couldn't sign in because it strictly required IndieAuth for sign-in?
I was recently gently reminded that the IndieWeb webring at one time allowed you to verify your identity using an alternative sign-in mechanism. For instance, by making bi-directional links between your home page and your GitHub account, you can delegate the step of "proving" that you are the person in control of your homepage to GitHub, and let them worry about storing and checking usernames and passwords.
This concept is called RelMeAuth (because it works by embedding links in your homepage let look like <a rel="me" ... >). The original version of the webring would first check to see if your site specifies its own IndieAuth provider and, if not, would fall back to using Aaron Parecki's indielogin.com, which handles checking for these rel="me" links to supported sites. It also supports sending codes to your email, if you prefer!
So it used to work?
Yeah! I, uh, broke it when I moved the site over to PHP some time ago.
But it works now?
It should! If your homepage has no IndieAuth server specified, but has rel="me" links to your GitHub or an email "mailto:" link, you should be able to sign in to the webring using those methods!
It was broken for how long?
😅 it was fixed within a day of someone telling me it was broken!
Okay that's it, for now! Thanks for reading, imaginary interlocutor! As always, feel free to reply to this post on your own site, or feel free to drop me a line in the #indieweb chat (I’m schmarty there)!
I'm pleased to announce that the "next" and "previous" links between webring member sites should now be, more or less, deterministic! For example, if you visit gRegor's site, scroll to the webring links at the bottom, and click "next", you'll be taken to a site like mine! (at this moment, it is mine!) From my site, if you click the "previous" link, you'll be taken back to gRegor's site! This should m-
Wait, did you say "more or less"?
Well, uh, yeah, good spot. At a high level, the update works like this:
Each active member site gets a pseudo-random "sorting" number. For a given site, the "next" site is the one with the next highest sorting order, and the "previous" is the one with the next lowest.
When you click on a "next" or "previous" webring link from a member site, your browser tells* the webring where you're coming from with a "referrer" header. If the webring recognizes the referer as an active member site, it'll look up the next - or previous - site in the ring to redirect you.
Most of the time, the webring will only see the referring URL up to the first slash after the domain. For folks whose site on the webring has a path component, the webring won't be able to match it against most referrers.
It's also possible that your site is configured to not send referrer headers at all - in that case, the webring has nothing to go on to figure out that the visitor came from your site.
If the webring can't figure out where a visitor came from, they'll just get directed to a random active site.
That feels kinda broken if you ask me
Well, it's no worse than before!
Isn't there a way to improve it?
There is! Or... was. The first version of the webring included unique identifiers in the webring "next" and "previous" links for each member site. These unique IDs would have made it straightforward to figure out where a visitor is coming from.
The emoji-based IDs were hard to manage, added messy unintended meaning, and made it easy to mess up the webring links (or spoof someone else's) when copy-pasting!
I'm not sure! I feel like this update has the webring in a pretty good place. It's simple enough that I understand it and it works. I might look into some updates for the directory or the site layout, or help surface more information about member sites, like whether they advertise RSS feeds.
Okay that's it, for now! Thanks for reading, imaginary interlocutor! As always, feel free to reply to this post on your own site, or feel free to drop me a line in the #indieweb chat (I’m schmarty there)!
I'm pleased to announce that the webring will now be self-gardening! Webring member sites th-
Hold on, links to what now?
That-... is actually a good question!
In order for webrings to work, member sites have to link to one another, usually through the webring itself.
When you sign in to the 🕸️💍 IndieWeb Webring, you see this prompt on your dashboard page:
Screenshot of a warning "to stay active, make sure these links are visible on your site", followed by a text area with HTML links to copy and paste.
These links should be copied and pasted into your site so that they appear on the page that matches your webring sign-in. For example, I sign in with my homepage https://martymcgui.re/, so I put my links to the webring on my homepage. They look like this on my site, but you can style them up to look like anything you want.
"An IndieWeb Webring 🕸️💍" text flanked by left and right unicode arrow links.
The basic deal for most webrings is that, in order to receive incoming traffic from other member sites, you need to also display links back to the webring so a visitor can continue on their journey browsing sites from the webring.
If that's the deal, then when a member site goes offline, or removes the webring links from their page, the webring should no longer direct visitors to that site.
The IndieWeb webring tracks whether a site is "Active" or ... "Not Active" (ahem, Inactive). Active sites can receive traffic from webring visitors and, if you choose, appear on the Directory page. Inactive sites... can't do those things.
As the owner of an webring member site, you can sign in to the webring and your Dashboard page will show your site's current "Active" / "Not Active" status and the results of the most recent attempts to check your site for webring links. If you've made changes to your site, there's a "Check links now!" button on the Dashboard to scan for them again.
Okay that's enough background, I think.
Right, thanks. But actually no, there is more.
Initially, Active status on the webring kiiiiind of worked like an honor system. The first time you successfully sign in, your site is added to the webring and set to Active. From that point on, there were only two ways for your site to get marked as Not Active:
If you clicked "Check links now!" while your site was offline or didn't have webring links on it.
OR if I ran a "gardener" script that checked the webring links for one or more sites.
Since the webring came online in, um, 2018, I've only received a handful of nudges from folks who have been willing to track me down to the IndieWeb chat and complain. That led me to think this honor system was "okay" or "at least not so bad that folks are willing to jump through hoops to bring it to my attention".
That's definitely enough background.
Agreed!
So what's new?
Well, the honor system days are over! Which should be good for all webring member sites, I think.
I've built a little automated gardener that will periodically check member sites for their links. It's designed in a way that trends towards polling member sites about once per month.
For a new member site, it basically works like this: about an hour after you sign up, your site will be checked for links. If they're there, the gardener will check again the next day. It will check again a few days later, then a week, then two weeks.
Finally, as long as the links are there at every check, the gardener will only check once per month.
What happens if the webring links disappear from my site?
If the gardener finds that an Active member site has gone offline or lost the webring links, the site is marked Not Active. It's checked again the next day, then a few days later, then a week and then two.
Finally, the Not Active site will be checked once per month for 3 months. If the site stays Not Active that whole time, the gardener will stop checking and the site owner will need to sign in to re-check links manually if they want the site to become Active again.
What happens if I put the webring links back on my site?
If the gardener finds that a Not Active member site has their webring links back, the site is marked as Active and the schedule resets. The gardener will then check it the next day, then three days later, then a week, then...
Okay, got it!
Woohoo!
Why now, though?
Oh dang, that's a good question.
I've found the energy and space to start working on the webring again, including some possible projects like those I listed in my last update. Before jumping into any of those, though, I want to feel like I can "trust" that the webring is taking care of itself and its visitors. That means not sending folks to sites where the owner changed their mind about being a webring member or, worse, lost sites, and keeping track of active sites on its own!
Can we see the code?
Sure! The bulk of the updates are here on my git hosting. As with most things webring there's a little bit that's well thought out and some attempts at rigor followed by a rush of throwing things together when it appears near working.
I'm open if folks have suggestio-
Wait, I didn't actually want to look at code!
I put some words in your mouth, there, yeah. Sorry. 🙈
Okay! That's it for now. As always, feel free to reply to this post on your own site, or feel free to drop me a line in the #indieweb chat (I’m schmarty there).
Are you a member of the 🕸💍 IndieWeb Webring? Everything is fine! We are up to around 450 active sites, with more than 250 of those appearing on the webring directory page!
Okay so what is this update?
Ha! Ha. Reader, you see right through me. Since the last IndieWeb Webring update, an afficionado of IndieWeb, webrings, and PHP who goes by Von Explaino (aka Colin) reached out about collaborating!
That all started in, =ahem=, JULY OF 2023. After a slow email exchange between a patient Colin and a very embarrassed and tired me promising to take a look any day now, I eventually apologized for not having the energy to work on the web ring at that time, and around September we stopped corresponding.
The update is that there's no update?
No! Well, sort of? This weekend I finally made time to reading through Colin's updates and additions, especially focused around the PHPUnit tests that he added for the basic database logic and site fetching and parsing and link-finding code.
The tl;dr is: I've incorporated most of Colin's updates, hooray!
I don't want to look at code! Show me what changed for webring members!
Oh! Fair enough. None of today's updates affect how the webring looks or works at this time. It's more like setting up support infrastructure around the way the webring works now to make sure that nothing breaks unintentionally during future updates.
Does that mean changes are coming?
Most likely! But all good stuff, I think. At the top of my list are:
Automating the "gardener" that checks whether active member sites have lost (or inactive members have regained!) their webring links.
The directory page sure is getting unwieldy with so many profiles on there. It could use some improvements.
General design and navigation cleanups.
I've seen some interest in having the webring be a "true ring" - with deterministic next / previous links. I'm open to this but I want to keep it simple. (And I'll probably want to shake things up every once in a while!)
I've seen some interest in using the active member sites on the webring as a "Who to Follow" for folks who are setting up their feed readers. I don't have it in me to maintain a "planet" feed that contains posts from everybody, but I could probably add some feed discovery so you can see which sites have clearly labeled feeds and maybe let you export an OPML list.
Oh! And I keep wonderi-
Okay! Okay.
Right, haha. That's it, for now. As always, feel free to reply to this post on your own site, or feel free to drop me a line in the #indieweb chat (I’m schmarty there).
Well, it's a rainy day and a good day for someday projects. Also, oops, here's a post about a tiny site update that accidentally sprawled into a post about 6 (or 14) years of my relationships with Foursquare and the whole idea of sharing "check in"s (not 🐔s).
Oh no it's backstory time
In 2009 I was living in Pittsburgh, working as a research programmer at Carnegie Mellon, a proud member of the newly formed HackPGH hacker space, starting down the slippery slope of joining the 3D printing industry, and basically excited about technology and the future. It was in this context that I vaguely remember being talked into joining Foursquare, so friends and I could keep up with one another at our usual haunts around town.
I'm not sure how much serendipity it really enabled, but checkins did lead to conversations and a nice general awareness of what folks in my social network were up to. Oh, and some competition for points and mayorships, of course, thanks to gamification.
I made use of checkins pretty regularly, in town and on trips, across a move to Baltimore and starting a new job in the aforementioned 3D printing industry. And then in 2012 I stopped. I don't 100% remember making this a conscious choice, but I do recall that most of my friends who used the app regularly were far away in Pittsburgh, privacy and surveillance capital concerns were on the rise, and — heck — I probably changed phones or something and just plain didn't install it.
Fast-forward about 5 years to 2017 and I'm all-in on the IndieWeb community. After learning about it in ~2015, putting together my first blog since ~2003, and attending my first IndieWebCamp in NYC in 2016, I found myself in Portland, OR for the IndieWeb Summit.
And goodness these folks liked checking in with Foursquare (now Swarm)! They were tagging one another in the app, maximizing points with photos, just documenting the heck out of where we were going and what we were doing.
Aaron Parecki, one of the co-founders of IndieWeb, had set up a service called OwnYourSwarm which you could set up to watch your Swarm account for new checkins, at which point it would send 'em off your your website. While I probably should have been paying more attention to the excellent IndieWeb Summit discussions, I hacked up some bits of my site to understand posts from OwnYourSwarm and posted my first checkin to my own site.
OwnYourSwarm is still around and working well, despite some speedbumps over the years from Swarm API changes. Thanks, Aaron!
Okay, but something about maps?
Speaking of Aaron, I was jealous of how good his checkin posts looked. Like this example checking in for IndieWeb Summit day 1. I specifically liked the little map at the top and wanted one for myself.
Screenshot of the top of Aaron's post checking in at Mozilla Portland. A small map in wide aspect ratio has a blue pin indicating the location among the streets in downtown Portland.
So, uh, almost a year later, I was inspired by this really great post on privacy-preserving, self-hosted maps by Sebastian Greger, to finally put together my own setup and promptly never blogged about it. I know this because I bookmarked his post and found the Git commit from June 25th, 2018 where I switch from Javascript-powered Mapbox (which I don't really recall setting up) to my own static map setup.
Black and white map image with a purple push pin at the corner of SW 2nd Ave and SW Pine St in downtown Portland, OR. Map tiles provided by Stamen, contributions by OpenStreetMap contributors, etc.
I use https://github.com/dfacts/staticmaplite on my site. It’s no longer under development but, as long as you point it at a working tilemap server, it works fine! I switched out the URLs hardcoded in the PHP file for the Stamen “Toner” tiles, using the tile server URL pattern on the Open Street Map wiki.
staticMapLite is a little PHP service you can self-host that creates plain old map images, of the locations you want at the sizes you want with overlays and pins if you want them, and caches them forever. It does so the same way as pretty much all map tools on the web: by asking bigger servers (called "tile servers", or "raster tile servers") for larger sets of "tile" images, then slicing up those tiles to make the image you want. The project is archived and hasn't seen updates since 2018, but it works fine! Raster tile server technology hasn't changed much since then.
Assuming, that is, that you have a raster tile server! You can run your own, but they require a ton of storage for all the map data, need regular updates, and generally are considered a pain to maintain.
When I set this up I remember looking over the list of raster tile servers on the Open Street Map wiki to find one that was free, didn't require signup, and produced map images that were aesthetic and minimal. With its dithered black and white look, Stamen's Toner definitely fit the bill. Stamen, those data visualization folks, right? I don't really remember thinking too hard about it!
We were promised a site update
Okay, okay! As it turns out Stamen also didn't like being maintainers of map tile servers. Especially when so many folks were freeloading on them!
To that end, this year Stamen announced a partnership with Stadia to begin hosting Stamen's many tile designs with Stadia, a map service with a business model, instead. The tile images remain shareable under their Creative Commons attribution license, I can keep all my existing cached images, and so on. They're offering a free tier of up to 200,000 tile images a month which is welllll below what I'll need for my few static images on rare times that I make checkin posts.
So, I've updated my deployment of staticmaplite to pull tiles from Stadia. Steps largely followed their migration guide:
Make a (free) Stadia account.
Generate an API key.
Update staticmap.php to replace the "a.tile.stamen.com" map URL with "https://tiles.stadiamaps.com/tiles/stamen_toner/{Z}/{X}/{Y}.png?api_key=MY_API_KEY_HERE".
Update my post template with the new attribution requirements.
I went hunting around the map cache on my server to find the most recent map image and delete the cached image so it would re-generate. It took me a couple of tries to get my tiles.stadiamaps.com URL correct, as Stadia's example used lowercase placeholders like "{x}" while staticmapslite requires uppercase like "{X}". Also, Stadia supports an optional "{r}" value — either an empty string "" or "@2x" if you want double-resolution images for Retina displays — that staticmaplite doesn't understand (and that I opted not to use).
Map image of Brooklyn, NY with a purple pin near the southeast corner of 5th Ave and 3rd St. Map tile courtesy Stadia and Stamen and OpenStreetMap contributors.
Looks pretty much the same, which is the point!
So.
Was this a site update? Perhaps one long overdue from 2017 or 2018? Or is this a post about a very specific kind of admin tax? Or something else? I'm interested in your thoughts!
Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!
