Trying on the Indie Web, Part 1
John Colagioia- Spinning(?) the Indie Web from Apr 3, 2024, 7:30am
- Caught in the Indie Web from Mar 27, 2024, 7:30am
- Deeper in the Indie Web from Mar 20, 2024, 7:30am
Quick Summary: In case you wonder why a tech tips post has so much prose and so little code, this post will kick off a series of occasional posts where I’ll try to explore an alternative to social media, the various Indie Web protocols. This post will have some code, but will mostly set the stage for the posts to come.
If you follow me anywhere on social media, you have probably noticed a lack of posts other than blog announcements and my semi-automated Mastodon shares. A big part of this (admittedly mild) shift comes from the fact that I have a blog, where I should publish what I have to say.
I like the idea of social media, where some random person can show up to have an interesting conversation when you say something, or making it convenient to find someone with a particular interest or experience. But I don’t love that we need to choose from one or more of three unpleasant experiences.
A Quick Typology of Social Media
I’ve hinted at the three major social media experiences in my post about why federation makes sense for most social media, but I’ll make it explicit, here.
At one extreme, you have one centralized website, which needs money to continue operating. This money can come from any combination of investors, users, and “side hustles” like selling ad space or user data. No matter their founding principles, these sites will inevitably either compromise on their principles—directly or through somebody buying it to enact their own agenda—or shut down. Worse, the choice grows more important as more people agree with those principles, because it costs more to operate a popular site, in terms of required hardware, programming talent, and moderation.
At the other extreme, you have totally decentralized systems, such as Scuttlebutt. Those don’t require money, because each user manages their own experience, but requires that each user manage their own experience, at a minimum requiring that they store and maintain a lot of information. The system can’t have any significant moderation or guidance, creating a multi-tiered group of users, with “old hands” talking to each other and filtering out the noise, a deluge of noise from people acting in bad faith, and newcomers who mostly see the people acting in bad faith, because the better users (as mentioned) won’t engage with anybody who they don’t already know. Worse, because the experienced people shield themselves from the behavior that bothers them, by definition, they don’t see it, and so don’t have the context to make the network better for newcomers.
Alternatively, you end up with a system like twtxt, where it inherently protects you from the noise, but interacting with people requires that you constantly scrape the entire network, on the off-chance that somebody wants your input on something…which then exposes you directly to everything that the structure protected you from.
Finally, somewhere in between, you have the federated systems, with the Fediverse serving as the primary example, at the moment. While you get a resilient system—one that you can reasonably moderate and keep safe from the pursuit of profit—you also get some of the problems of both extremes. You end up with uneven moderation, which might isolate groups of servers from each other without anybody explaining why. And you still end up with a need for money and other resources, because these websites don’t run themselves, and the more popular servers need more support.
My tolerances lead me to federated systems, because I have certain priorities and understand the tradeoffs. Many people want a centralized website, because they haven’t really seen anything else, and only grasp the idea that “one site means everybody in one place.” And a handful of people like the post-apocalyptic idea of the decentralized systems and, as long as they can find their community, will also do fine.
The middle group often posts incomprehensible items like the following, which we’ve probably all seen and many people have mocked.
It frustrates me to see social media constantly destroyed by capitalism. Anyway, come follow me at ██████@bsky.social!1
I see and understand those perspectives. But I also want something different.
Enter the Indie Web
The Indie Web website describes its purpose as follows.
The IndieWeb is a community of independent & personal websites connected by simple standards, based on the principles of: owning your domain & using it as your primary identity, publishing on your own site (optionally syndicating elsewhere), and owning your data.
It goes on to describe five major pieces—IndieAuth, Webmention, Micropub, WebSub, and Microsub—not all of which will probably apply to every website.
This series of posts will dig through the process of making my website, particularly this blog, as “social” as possible. If I can get through it without too much trouble, and assuming that I understand the overall premise, then this should give me a platform where I can find out if people pick up my thoughts, but will also give me a better basis for re-posting blog ideas to social media, when it seems relevant.
Let’s Go
What can I set up before this post goes out on the morning of the thirteenth? I’ll start with their getting started self-hosting instructions, since I do host this blog myself.
Conveniently, I already have a personal domain, using a subdomain (john.*) on the original domain that I use for my company. I also host the pages on my VPS, so I don’t need their advice on hosting.
Starting at Indie Webify Me, I’ll now walk through their steps on my homepage, and propagate what I need to the blog, later.
Level 1
Look, the tool calls them “levels,” not me. I’d give them names.
In any case, this “level” involves identifying myself on other networks, using the rel=me microformat. It picked up the reference back to the same page and my Mastodon validation. I could probably stand to add others.
Level 2
This “level” wants me to add an h-card microformat, identifying myself. My first pass looks like this, inserted at the bottom of the page code. Yes, we finally get to look at some code.
<a
href="https://john.colagioia.net/"
class="h-card"
rel="me"
style="display:none;"
>
John Colagioia
</a>
The style prevents the card from cluttering the page.
It called that a success, but wants me to add a photograph and a short biography. I suppose that I can do that, using whatever I use for Mastodon…
<img class="u-photo" src="/images/d29181b871b001b0.png" />
<p class="p-note">Hi, I'm John, and I work on various odd things.</p>
That now suggests that I make it a representative h-card by adding a class…but that seems to require a bit of reorganization. I present the final version.
<span
class="h-card"
rel="me"
style="display:none;"
>
<a href="https://john.colagioia.net/" class="u-url u-uid">
John Colagioia
<img class="u-photo" src="/images/d29181b871b001b0.png" />
<p class="p-note">Hi, I'm John, and I work on various odd things.</p>
</a>
</span>
The card now lives in a span element, with the URL an element inside it. I still keep it hidden, so that it doesn’t clutter the page.
Apparently, We Ran out of Level Numbers
Next up, we look at the posts, looking for the h-entry class. And whether I did it or Jekyll handles that out of the box, that already seems done.
However, it suggests adding an author, any categories, and links to any syndicated copies. I no longer use categories—it never really made sense for this structure, especially once I created tags—and don’t currently syndicate, but I can probably add empty values to the page templates, then fill them in later if I ever need them. And every post does have an author, though you can always guess that the author looks a lot like me, so I can plug that in, too.
<a
class="p-author h-card"
href="https://john.colagioia.net"
rel="author"
style="display: none;"
>
</a>
<a
class="h-syndication"
href="."
rel="syndication"
style="display: none"
>None</a>
<a
class="p-category"
href="."
style="display: none"
></a>
That all goes in my post layout template.
The analysis results wanted me to add the image to the author h-card, so I did that. It didn’t like my empty syndication list, however, but since—as mentioned—I don’t currently syndicate, I probably don’t care.
Finally, it also mentions that every post (or whatever you call them on your site) should have the following.
e-content— the main content of the postp-name— if your post is an article with a name, use this class name.dt-published— the date/time the post was published at, in ISO8601 format, with a timezoneu-url— the canonical URL of the post, especially important on pages listing multiple posts
I have each of those, conveniently, suggesting that Jekyll added them to the template by default.
Web Mentions
Now we start digging into the “real” work. The authors describe Webmentions as follows.
Webmention is a simple way to automatically notify any URL when you link to it on your site. From the receivers’ perspective, it’s a way to request notification when other sites link to it.
It’s a modern alternative to Pingback and other forms of Linkback.
And it outlines the expected behavior like the following.
Alice posts some interesting content on her site (which is set up to receive webmentions).
Bob sees this content and comments about it on his site, linking back to Alice’s original post.
Using webmentions, Bob’s publishing software automatically notifies Alice’s server that her post has been linked to along with the URL to Bob’s post.
Alice’s publishing software verifies that Bob’s post actually contains a link to her post and then includes this information on her site.
That sounds like a big piece of what I want, so we’ll make that the target for now. Unfortunately, the Indie Webify Me tool stops validating, at this point, and only provides a form to send Webmentions. Coincidentally, it also has no more steps, so I’ll need to go elsewhere.
Since, as I’ve mentioned a couple of times in this post, the blog runs via Jekyll, I can’t deal with Webmentions directly. That presumes a server running, taking proper requests. Jekyll generates a static site, which doesn’t have that extra server.
However, people have already thought about that, creating webmention.io and, critical for my purposes, the Webmentions for Jekyll gem. With any luck, I can ride on their work.
Setting up the Server
It looks like I need to claim my URL, in some way, on the Webmention service, so I give it my URL, and…this will take some effort.
None of the rel=me URLs found on your page were recognized as a supported provider.
That sends me to setting up IndieAuth, which you might remember mentioned earlier in the post as a core part of this Indie Web package. Digging through the IndieAuth page on Indie Web makes it seem like the least-effort path involves running Selfauth , since I have PHP running for some other services, and I don’t think that I need any of that token nonsense.
Putting that into place, I visit it, which tells me to visit this ugly page.
Doing that tells me to create a config.php file in the same folder, and…honestly, it looks broken, when I try to interact with the service. However, I don’t need to interact with the service, the other service does, and…yes, I can now log into webmention.io.
Note that I could have used some other providers, such as GitHub and an e-mail address. This felt like a reasonable approach, though.
Adding the Gem
Now, I install the Webmentions for Jekyll gem as the directions instruct, and…it relies on the OpenSSL gem, which it can’t build, claiming that the “OpenSSL library could not be found.” On Ubuntu and similar systems, that usually means installing something like openssl-dev.
That moves me forward.
I added a minimal configuration to Jekyll’s _config.yml file.
webmentions:
username: john.colagioia.net
And then add the Liquid tags to the layout templates, and…
Liquid Exception: Liquid syntax error (line 103): Unknown tag ‘webmentions’ in …
Hm. That seems unfortunate…
In fact, Jekyll can’t find any of the three tags listed in the directions. It turns out that I added the gem to the general list, rather than to the Jekyll-specific group. The Gemfile should look like this.
group :jekyll_plugins do
# Other gems, for example, I have...
# gem "jekyll-feed", "~> 0.12"
gem 'jekyll-webmention_io'
end
And now it builds.
Does It Work…?
The good news? Everything seems to build correctly, though my build process has grown a bit slower. I don’t see any definite problems.
However, I have no idea what this will actually do when I publish it. The local Jekyll server doesn’t interact with any of the outside infrastructure. Even if everything works as expected, I don’t know if anybody has Webmention-ed any posts. I don’t have any styles attached to any Webmentions that I happen to find.
In other words, I won’t have any idea of what any of this actually looks like until I have already published this post. As such, you could see a complete disaster when I push this out, and then watch me scramble for a few days deciding what to do…
Coming Soon, Maybe
As I said, I’ll try to make this process an irregular feature of the blog, if for no other reason than I haven’t published as much technical work as I’d like, recently. If tomorrow fails, I’ll follow up next Wednesday with whatever I did to fix it. If it succeeds, I’ll continue reading up on these Indie Web formats and processes, to see what I can integrate.
For example, assuming that this all works, then I’ll need to figure out how to send Webmentions, and probably build Jekyll plugins to insert the various types. And I also have three major features of Indie Web’s five—Micropub, WebSub, and Microsub—to investigate, since this post dealt with IndieAuth and Webmention. And services apparently exist to simplify syndication to certain destinations, which might simplify my publication process. Stay tuned.
Meanwhile, if you have had any experience with these Indie Web processes, I’d love to hear from you and compare notes.
Credits: The header image is Web by Martyn Wright, made available under the terms of the Creative Commons Attribution 2.0 Generic license.
-
Yes, sure, the AT Protocol can federate, at least in theory. Right now, though, they don’t exactly have any serious peers on their network other than experimenters downloading all posts, not even in-house to reduce server load, so we need to treat them as centralized for now. ↩
No webmentions were found.
By commenting, you agree to follow the blog's Code of Conduct and that your comment is released under the same license as the rest of the blog. Or do you not like comments sections? Continue the conversation in the #entropy-arbitrage chatroom on Matrix…
Tags: blog indieweb programming techtips