I've been following the exploits of IndieWebCamp for some time, so when I found out that a London group was starting up I leapt at the chance to attend. Despite my interest in the topic (and having owned/run a personal site for well over a decade) I've never actually taken the leap into indieweb tech like micropub, webmentions etc. and thought this might be a good chance to do so. Unfortunately, global health pandemics had a different idea, and with London increasingly on lock down the event ended up becoming remote only.

On the one hand, being remote worked out quite positively. The ethos of the indieweb makes it particularly well suited to distributed meetups, with an existing infrastructure based around Slack/IRC, Etherpad, Zoom, and other remote services making the switch fairly frictionless and allowing me to still enage with life around the event^[1]. On the other hand, as someone entirely new to the community and unaware of what most of the jargon being bandied around relates to, it left me fairly unsure of what to expect. It's the little things, like putting on the schedule "Barcamp style breakout sessions"; that's great, but I have no idea what Barcamp is or how a breakout session might work, remotely or otherwise 😅 Plus, whilst I have no issue with audio calls online, I find video really distracting and hard to engage properly with, particularly if I'm visible, so I felt a little distanced at points.

Luckily, the organisers (and rest of the attendees) lived up to their reputation of being incredibly welcoming and it all went smoothly. I opted to lurk for most of the session, only really dropping into Slack to say hi and then putting my name down for certain breakout sessions. Honestly, being remote for those bits actually helped, as I was able to "hang back" and work out what was going on without feeling conspicuous. I did feel a little silly for not stepping up and showing off theAdhocracy, though, but the idea of grappling with Zoom's screensharing was too much faff - next time, in person, I think that's a definite goal!

Being remote also meant that it was a lot simpler to take notes, but I did struggle to keep up so largely abandoned plans of live blogging in favour of actually, y'know, listening and learning 😁 What I've written here, then, is more of a summary of the weekend.

Keynotes

Saturday kicked off with the keynote speeches. First up was Kevin Feeney, CEO of TerminusDB, whose talked about why Databases Must be Decentralised or we will Never be Free. It was fascinating, but entirely outside of my wheelhouse; I wish Alison had been around to listen as I think she'd have had some interesting insights/questions.

From how I understood it, Terminus is aiming to do for databases what Git (or I guess, more accurately, GitHub) did for software repositories: it makes them easily distributable; totally decentralised; able to be amended by anyone so long as they have access; capable of being forked/remixed/merged; and ensures the data fits agreed semantic rules, thus enabling all of that cross-polination and remixing to work.

As an example, Kevin talked about how one group of academics have been using Terminus to digitise a vast amount of historical information, which is now all easily searchable and verifiable. At the same time, climate scientists have uploaded databases of ice-core and other "deep time"^[2] climate data. Because the databases all use the same semantic structure, they can now fork subsections/tables from each, merge them into a new dataset, and learn more about major climate events like Krakatoa from both geochemical and historical sources, simultaneously. That's pretty neat and almost feels more inline with what the web was intended for than its modern usage 👍

Next, we heard from Rosemary Orchard who provided an overview of what the indieweb is. It was a great refresher to remind myself of some of the core terminology that is used and an excellent advert for why indieweb tech is beneficial. I tried to keep up in my notes, but Rosemary had a habit of summing up an idea so eloquently I felt it was worth truly quoting, and then invariably missed the next bit 😁 Oh well!

She did a fantastic job of explaining why she has taken the time to wrestle her data back onto a platform she has control of:

I don't have to leave other social media behind. I integrate this website - my website - into whatever I want... We are in control of our data, we choose where our data goes.

Doing so doesn't just retake control, but also futureproofs your data. Having your own website ensures that only you can decide to take information offline. The classic example is that disappearance of MySpace, but Rosemary extends this to not just data loss but also a loss of contact channels. That's an angle I've never really considered before, but a highly relevant one and something that chimes well with the huge number of blogs I've "lost touch" with due to the slow decline of RSS feeds (now seemingly beginning to reverse).

"I can build my own personal profile of my life, on the internet, without being stalked by some tech giant who may not have my best interests at heart".

She also touched on a number of useful tools, such as Quill and Monocle, that are designed with the indieweb ethos in mind. The first is great for pushing content to your website (micropub) whilst the second becomes a centralised hub for your social channels, websites, and RSS feeds so that all of your interactions are in one place and you can decide which ones to push to your website. Interestingly, Rosemary mentioned that she pushes everything to her site but only some of it is public; this means she controls her own data and can track it, but can easily make it accessible or not in the future.

Using indieweb authorisation services like OpenAuth and IndieAuth also means that she's able to use her own website as a key, effectively, to authenticate on other services. That strikes me as a very useful feature.

Breakout Sessions^[3]

Following some really interesting website show cases (which included a cool little tool, Noter, for live tweeting made by Kevin Marks) and a break for lunch, we launched into the collectively agreed upon sessions. I was really glad to see us covering some foundational knowledge, but was just as interested in topics like analytics and static site challenges. Honestly, it felt extremely relevant, which was a pleasant surprise - think I just got lucky!

Building Blocks of the IndieWeb

The basic requirements to be considered part of the indieweb is to:

1. Have a website;
2. Own your URL;
3. Make it available.

Hooray, I meet that criteria!

More recently this has been expanded to include a wide array of newer technologies and specifications, the most important of which is microformats. These allow other websites to read your content and understand what it is, which in turns enables remixing and other froms of data/information sharing. In other words, you might publish the page as a webpage, but the structure (and therefore the content) is available to other tools to do something else with it.

Microformats are broken down hierarchically, starting with the "h" definition e.g. h-entry. Content contained within it is then marked up using a structured form of notation, making it machine readable/parsable. From the examples given, it seems like these values are set on the class attribute; that seems like a bad idea to me, as you'd expect classnames to be inferring a CSS hook, not markup data. I wonder if you can use something different, like an attribute? Of course, I should have just asked, but by this point I was in full lurker mode...

In terms of testing your microformat markup, the website indiewebify.me looks great. It also has a lot of key information in how to get involved in indieweb technologies in general. Similarly, the MDN docs have recently been updated to include all microformat standards as a useful referral guide.

The second building block is webmentions, which are basically a way for you to create a two-way URL (sort of, we'll come back to that). More generally, they tell a webpage when it's being interacted with from a seperate domain. For example, if you share a blog post on Twitter, webmentions can be used to inform the original page and update it to link to that tweet or increase a counter.

Of course, very few large web companies (i.e. Twitter) are able to be configured to trigger webmentions, so there's a host of tools that have grown up to fill the void... or bridge the gap 🙄 Yes, the main one being suggested is called Bridgy, and it does just that, for free. Another was webmention.herokuapp.

Personally, it seems like a big issue with the concept of webmentions is that it's so manual (though it can be slightly more automated with tools like webmentions.app). On the one hand, I like the idea of being able to track when people mention/share/respond to my blog posts, but it seems to unreliable. I know I've seen webmentions on places like adactio.com, have reblogged an article, and then been disappointed not to see my reblog appear as a mention. Now I understand why, I can use the form that Jeremy provides, but it still feels clunky and if I'm on the move I doubt I'd ever do so. Scrapers like Bridgy help, but they only work because of large silos like Twitter, which almost feels like a defeat for the indieweb. It's a shame that two-way links aren't a native feature of HTML... I know that was an original part of the specification for the web and it feels like it would make this a simple, intuitive, and automatic piece of functionality.

Moving on to building block number three, we have rel=me, an HTML attribute that informs indieweb tools when websites are interconnected. For example, if I have a portfolio website or a GitHub page, I could add rel=me to the links between them and theAdhocracy and then the three sites would effectively be linked. Of course, this only works if both sides of the link agree i.e. they point at each other.

rel=me is normally combined with an h-card element^[4]. This is a top-level microformat that allows you to specify all your key indieweb/personal info in a way that makes it accessible to machines.

An h-card represents a person or a place.

Whew, that was a lot for a single session. There was definitely a wide range of understanding and experience in the virtual room, but I found it a really helpful session to wrap my head around several core concepts.

Static Sites & Micropub

The second session started with a brief overview of what the micropub standard is for, which is to publish content dynamically to your site from third-party services (your own or genuinely third-party tools).

The first step in setting up micropub, though, is to enable some form of authorisation tied to your website. That effectively allows you to validate your identity using your domain, by piggybacking on services like IndieAuth to do all the heavy lifting. Once you have authentication, you can handshake with your own website and securely publish content from anywhere, as well as allowing other people to do the same.

Of course, you still need an endpoint to publish to. That's where the micropub server comes in: it parses incoming data, validates it using indieauth methods, converts it to the necessary format, and passes it to the site for rendering. The indieweb central site has a list of useful tools for setting a micropub server up; indiekit is another option in development.

Unfortunately, that means a micropub setup is a lot simpler if you have dynamic content. If you're like me and serving static pages, you need to start getting a little tricksy with client-side JS and automating rebuilds on the (technically non-existent) back-end. Jamie has some useful links on how he overcame that using Netlify and serverless functions to run micropub integrations, so it's definitely possible, but a bit off putting. It does make me wonder if a Craft plugin wouldn't be the way to go.

Once you have that endpoint setup, you still need to actually publish. This is the pay off for me: easy mobile apps. If I'm on desktop, I have a CMS that is a joy to use, but I still don't have a good mobile workflow. Apps like Indigenous look like a really nice fit for that; they could also take the place of big tech solutions like Instagram for side projects my beer journal.

Analytics & Indieweb

The big question is: if you're an advocate of the indieweb, you clearly care about privacy. So how do you pair that up with the potential privacy impact that analytics trackers come with. Overall vibe from the session was that Google Analytics is best avoided, but there are some other options.

Both Fathom and Matomo seem like competent alternatives; we also took a brief look at Cloudflare, but it's probably too high level to really be of use. Fathom looks nice and has some neat layout features, but it's a paid-for Cloud service, whereas Matomo has a self-hosting option. I've looked into both before, so it was great to get some genuine user feedback and hear that they both work well enough.

That said, the fact that more people are blocking trackers than ever before does make all of these services a little redundant. Unfortunately, no one really had any solutions for that, though a few ideas were thrown around for tracking via secondary data such as webmentions, Google Search Console, and even Bridgy. After all, knowing how often a post is reshared or searched for is probably more useful than full traffic data in some ways.

The discussion also veered into some other areas, including analytics as a proxy for social media style engagement stats and whether it could create a similarly negative feedback loop. Ana made a really interesting point that she tracks webmentions but doesn't display them, to try and tease apart that validation cycle. I think that's a very valid consideration to take into account when considering social feedback elements like webmentions and comments.

In turn, this led to a discussion around whether webmentions are a truly opt-in technology and, if not, whether there's an element of privacy intrusion to them similar to analytics tracking. Personally, I think that's valid; if I'm getting a webmention through from a service like Bridgy, it's fully automated. The person triggering that mention may have no idea about it, so it necessarily is a removal of autonomy to some extent. I remember a few years back when a prominent blogger commented on this website after I had written a counter argument to an article they'd posted. He had been made aware of that via a linkback notification, as I had linked to the original article. On the one hand, that interaction was pretty awesome, but at the same time it made me wary - I'd never considered that the original author would read my counter argument.

Overall, I'm not sure any concrete conclusions were drawn about analyics, but I think the general feeling was summed up best by Cheuk:

"It's a balance between what you want to know and what you need to know"

RSVP

I found this a very interesting discussion in terms of the work we're doing with Growable; there was a lot of anti-Meetup sentiment on the call, but also a general admission that it remains hard to ditch it (our experience exactly, though we're getting there). However, from a personal point of view I have no real interest in implementing event RSVPs. That's just not data I care about keeping a record of, so it's not something I'd consider doing for now.

There was some discussion about whether widespread adoption of personal "event lists" might lead to better discoverability of good meetups, but I think you'd run the risk of just creating influencer-style behaviour and eroding trust there too. In some ways, a centralised algorithm like Meetup might actually be better for that in the long run.

Microsub & Feeds

The nice thing about microsub is that it can do anything you want it to, if you teach it.

Microsub is a new indieweb standard, still very much in draft stage by the looks of things, that determines how you ingest data and convert it to a standardised JF2 feed. It's aiming to be able to convert any feed on the web into one that can be ingested, standardised, and made available, creating a more open information ecosystem.

The main point of the session was to determine what datafeeds people currently can't access, to determine how best microsub may be able to help in the future. Honestly, I tapped out here; I think I need to learn a bit more about the fundamentals before these kinds of discussions make any kind of sense 😂

That said, the discussion swung around to being able to pull in information from Discogs, and that's quite interesting to me, so perhaps I need to look into this more in the future.

Hack Day

Day two of the camp is reserved for building. I've got to admit, I left day one knackered and with a long list of other things that I felt would be better to focus on than web work for day two, so didn't really intend to get all that involved. This was definitely a major bonus for the remote aspect of the event, as I felt zero pressure to show up and no guilt about dropping in/out throughout the day. The result was much more productive - I think - than had I actually gone along for a physical session.

As it was, I spent most of the day bouncing between tasks, doing little bits on my website, getting myself setup on the IndieWeb community site, and sorting out various chores around the house. Oh, and I fixed my desktop wallpaper problems 😁 In terms of indieweb, here's what I got done:

• Added rel=me links to Twitter and GitHub, as well as (non-functioning) ones to Instagram and 500px;
• Used that GitHub connection to authenticate my domain via IndieLogin;
• As an FYI, whilst I had heard a lot about IndieAuth on day one, I hadn't fully realised that it's both a service name and an underlying protocol. The two have been synonymous, but IndieAuth.com now has a warning stating that it will be deprecated in the future and to use IndieLogin for new projects.
• Authenticated myself (using indieauth) on the IndieWebCamp Wiki;
• Setup my Wiki profile, chat name, and sparkline template (also learnt what sparklines actually are 😂);
• Ended up adding a new question/answer to the Wiki FAQ (by request) 😨
• Spent quite a long time looking into the historic reasoning behind microformats being associated with the class attribute, which I turned into a seperate post;
• Realised I really dislike that the www subdomain is becoming an integral part of how I'm now known, thanks to indieauth setup, and changed it... thereby breaking my IWC login (woops!);
• Added h-card, h-entry and various other microformats to my homepage and content templates;
  • At this point I managed to miss the end of IWC and the show and tell because I was stuck debugging an API error (now fixed) so that's annoying!
• Finally managed to get the "updated" field on articles to appear only when relevant;
• Fixed a few CSS issues and began implementing proper pagination for Notes, before calling it a day.

Overall, a pretty productive second day, even if it had some false starts and partial failures.

Thoughts

Overall, I really enjoyed my first taste of the indieweb. There were elements of it being remote which were beneficial, and others which made things harder. I definitely didn't get as involved as I would like, but it left me wanting to, which is pretty high praise. The organisers were great and ran it really well, and even though we were all just a group of floating heads on a VoIP call, it still felt inclusive and welcoming (even for us lurkers).

In terms of the underlying concept of the indieweb, there's still a lot that I like. I fully back the central idea that people should have their personal pocket of the internet, that you should own the content you create and the data that you generate, and that its use is fundamentally your choice. However, it does feel like a bit of a bubble. I'm interested in getting to know the various parts of the indieweb better, but that's because I'm a nerd. I think it still has a long way to go for it to have genuine mainstream impact. But hey, maybe I won't think that so much once I've actually given it a go. Or maybe that's not actually a problem at all.

My brain also feels a little frazzled from all the new information! I thought I'd come out of day one and just be ready to jump straight into a code editor, but actually I was more interested in sleeping 😁 I don't think I've learned that much in such a consistent manner since university. (And, honestly, probably even a bit before then - eight hours is a long time!)