Peter has experimented for a while with Mastodon (and the ActivityPub protocol behind it) and decided that it’s not for him.

Well, this has been fun, but it turns out that the effort-vs-reward for the fediverse doesn’t balance for me; I need fewer reasons to be tethered, not more. @mastohost, recommended by @ton, was an excellent playground. In 24 hours this account will self-destruct. But, now and forever, is where you’ll find me.

I very much recognise his point. The disbalance he mentions I felt strongly in the past month, where it was absent in the five and a half years before it. The enormous influx of people, positive in itself, and the resulting growth in the number of people I followed made my timeline too busy. In response I started following topics more and am evaluating rss feeds from ActivityPub servers. The disbalance expresses itself in spending too much time in the home timeline, without that resulting in notable things. (I mean literally notable, as in taking notes) Unlike my feedreader. It does result in some interesting conversations. However such interactions usually start from a blogpost that I share. Because of the newness of AP and Mastodon to the large wave of people joining, many posts including mine are of the ‘Using Mastodon to talk about Mastodon’ type. This is of course common for newly adopted tools, and I still have a category on this blog for metablogging, as blogging about blogging has been a 20 year long pattern here. Yet it is also tiring because it is mostly noise, including the whole kindergarten level discussions between petty admins defederating each other. There’s a very serious discussion to be had about moderation, blocks and defederation, to turn it into a tool that provides agency to individual users and the groups they are part of. These tools are important, and I’m glad I have them at my disposal. Ironically such serious discussion about Mastodon isn’t easy to conduct in a Tweetdeck and Twitter style interface, such as Mastodon provides. I moved the home timeline over to the right in my Mastodon web interface, so I don’t see it as the first thing when I open it up. I’ve concluded I need to step away from timeline overwhelm. Much as I did on Twitter years ago.

A tired purple mastodont lies on the ground sleeping while groups of people are talking in the background, sketchbook style. Dall-E generated image.

There are however two distinct aspects about AP and the recent incoming wave of people that I am more interested to be engaged with than I was before this started.

First, to experiment personally with AP itself, and if possible with the less known Activities that AP could support, e.g. travel and check-ins. This as an extension of my personal site in areas that WordPress, OPML and RSS currently can’t provide to me. This increases my own agency, by adding affordances to my site. This in time may mean I won’t be hosting or self-hosting my personal Mastodon instance. (See my current fediverse activities)

Second, to volunteer for governance related topics in the wider Dutch user group of Mastodon. Regardless of my own use of Mastodon, it is an environment in which many more people than before have new choices to make w.r.t. taking their online presence and tools in their own hands. A step from a global silo such as Twitter to e.g. a larger Dutch instance, while not the same as running one’s own, can be a significant step to more personal agency and networked agency. I’m involved in a group discussing how to establish governance structures that can provide continuity to the Dutch instance, lets people on the instance have an active voice and role in its internal governance, and raises awareness of the variety of tools and possibilites out there while purposefully avoiding becoming a new silo (through e.g. providing pathways away from the instance). Such governance is not part of the Mastodon instance, but structured around it. Such involvement is an expression of my experience and role in using tech for the past 33 years online as being inherently political.

A purple mastodont is conversing with a crowd of people, sketchbook style. Dall-E generated image.

Ik zag (op Twitter, jawel) dat de video van mijn presentatie op WordCamp Netherlands van afgelopen september is gepubliceerd. De video heb ik aan de presentatie toegevoegd, maar zie je ook hieronder.

Op WordCamp NL deed ik een oproep om standaard microformats en webmention in WordPress core, blocks en themes te ondersteunen zodat de 40% van het web die op WordPress draait ineens ook betekenisvol met elkaar kan verbinden: “WordPress sites tot IndieWeb alleskunners maken”.

Bookmarked What IndieBlocks Does, and Why by Jan Boddez

I really need to start testing Jan’s IndieBlocks plugin, to see if it allows me to switch to WordPress Gutenberg. If yes, I think it will allow me to also do a few things with my site to make it less blog-centric. Because from what I’ve seen from E’s work on my company’s site, Gutenberg makes that easier than writing a theme from more or less scratch which I’ve been balking at for some time, aka 2 years.

I probably will need to set-up one of my test WP sites (nicknamed proto and meso) with IndieBlocks. A key thing to test will be if interacting with the site through my Micropub client(s) needs to be changed. I now push everything into a raw html text that gets submitted to the site, and I don’t know in what ways that would need to be different in Gutenberg blocks, and how it might change how I need to talk to the micropub end-point.

Because nearly everything in IndieBlocks is configurable, it will be possible to keep using the other IndieWeb plugins beside it. Simply disable the bits you don’t need!

Jan Boddez

This page is to sketch out my tentative thoughts about adding check-ins to my website.

My history with check-ins

From October 2004 I used Plazes, the original social geolocation service. I met one of the creators of Plazes at a workshop I organised in early 2004 when it was still in its early stages. I used it until sometime between 2008 when it was acquired by Nokia and 2012 when Plazes was shut down by Nokia.
Foursquare was launched in 2009. My first Foursquare check-in was in September 2009. I used it similarly to Plazes. In 2014 it split up in both Foursquare and Swarm, of which the latter contained the check-in functionality. It led me to use Swarm less, and my last check-in was at the end of 2016.

I also used Dopplr, which was a slightly different type of check-in service. Where Plazes and Foursquare tracked specific locations I was at that moment, Dopplr let me indicate a city where I would be in the future. I first used it in June 2007, shortly after it launched and I suppose after hearing about it at the Reboot conference that month. It immediately was very useful, and I list it in 2007 as a tool I actively use. I last used it in 2012 to announce my month long stay in Copenhagen. It shut down in 2013.

In my site I have a posting category ‘plazes‘ for check-ins.
For a while I posted check-ins, from March until September 2019. It was based on automatically importing Swarm check-ins into my site, for which I started using Swarm again temporarily. Since then the pandemic made checking in superfluous. I only checked in three times afterwards, two times I was ‘outside’ in 2020 between lockdowns, and once last summer, on our way to our holiday destination. That last one was a check-in I created by hand on my site, without using an external service.

The purpose of check-ins

For me the purpose of check-ins is to help create serendipitous meetings with people I know, and with people that I don’t know but are close to me in the network graph. Crossing paths are an opportunity, and they are scarce, making spotting them valuable.
Such meetings can be aided in two ways:

  • By checking in where I currently am, people I know or who know of me and who are in the same city at that moment could see me pop-up in their vicinity. This is like what Foursquare and Plazes let me do. It is how I met Peter.
  • By checking into where I will be and when, people I know or who know of me and who also will be in the same city in that period. This too has been of tremendous value. By finding out beforehand that someone in my network and I will be in the same city at the same time, or because people in the city knew I would be visiting. In both cases it allows people to reach out to each other to agree a meeting.
    These effects in the past for me were never frequent, but they happened often enough to make checking-in when traveling (and checking other’s check-ins in places I usually frequent) a habit.

Self check-ins

The silos I used to use have gone away or changed in other ways. The average life span of a digital service is way shorter than the average life span of a person, or than the time span in which a digital service might be useful to a person. This means I am convinced there is value in bringing back things that were useful in the past, especially if done in a way that does not create another silo or exploits its users.

It also means my own blog has been in existence longer than Plazes, Dopplr, Swarm, and indeed platforms like Facebook or Twitter. My blog is essentially the best place to contain check-ins. Check-ins are just another part of my avatar.

My blog is also limited: I know many people and many people know of me who do not read my blog, so they would not encounter such check-ins.

The needed check-in flow

There are three elements to a check-in

  • Determining my location or venue (either current venue, or future location)
  • Posting the check-in for a location or venue
  • Ensuring discoverability of my check-in

Determining my location or venue

This is what Foursquare/Swarm supported well. They’d use your position and compare it to a database of venues. You’d then select the right venue from an overview and proceed to checking in. A database of location names is not a trivial thing.
For check-ins into a city you could use a geographic names database.
This is never easy, and well outside the realm of something you’d do on your own website. What can be done is, during a check-in, go and retrieve information from such a database, if a commonly accessible option exists, and use it. Experimental projects like Meridian aim to build on venue information and geographic names contained in Open Street Map, and contribute back to it.

Posting the check-in

This is the easiest part, as it boils down to creating a post on my site. Shaping that post can take some effort, depending on the amount of detail I’d want to give.
Does it link to the website of the venue I’m visiting, does it link to a page about a city I plan to be in? Does it show a map of the surrounding area? Does it link to a location in one of the Foursquare type of services? If it does anything like that it probably depends on information from the previous step.

In its simplest form I’d name the venue or city simply by mentioning it in the post, and at most add a URL manually or a short sentence about what brings me there. As in the last check-in I did on this site. That last check-in contains a nice SVG icon, and that type of thing would need to be in a template. For a simple check-in I could use micropub, probably for ease of use as a stand-alone form.

If I want to include retrieving and using information w.r.t. determining my location, then it would need several steps of interaction to help fill that submission form.

Ensuring discoverability

I think this is the hardest part. If the purpose is to allow serendipitous meet-ups, then any check-in must be easy to discover by others that I think would be worthwile to meet or others that think it would be worthwile to meet me. For these people to have to read my blog closely enough to know where I am / will be is too much to expect.
Silos like Dopplr had limited numbers of users, who were more or less by default in the same sort of groups I was in. Having an account was the right level of preselection. Swarm much less so, but it allows you to mutually connect with others and disclose check-ins to your existing network only.
This is the reason I used Swarm for check-ins before, as it was possible to check-in using Swarm (solving the problem of determining my location) and then post that to my site automatically (while the check-in in Swarm solved the discoverability part). It couldn’t be done the other way (initiate the check-in here, and syndicate it to Swarm).
What is possible is to start with the regular readership of this blog, those that follow my RSS feed. That is a limited audience, but definitely a group of people that I would like to meet if an opportunity arises. It would be up to them to overcome the friction of responding to a check-in, but friction is not a bad thing per se. I also think that travel itself has a higher threshold than before, making check-ins connected to travel stand out more as well. Another step would be to alert other types of services or websites, e.g. or posting it to my Mastodon stream or my private twitter account. Or post it as an activity pub message on this site, so it is available to an approved list of activity pub followers.

Favorited Yes! My IndieBlocks plugin is now up on by Jan Boddez

Oh, nice! Jan has been working on his own WordPress plugins w.r.t. IndieWeb for some time and now released some of that work as a public plugin. Current IndieWeb set-ups do not support the Gutenberg editor in WordPress as blocks are not supported. Jan’s plugin is created for blocks. Will need to try this out (also because my recent presentation at WordCamp on making WP IndieWeb compatible by default played a small role). Nice timing Jan, releasing it just so it can dominate my weekend 😀

Current version offers a single “Context” block, and, optionally, (1) some custom post types, and (2) the ability to add microformats2 to block-based (!) themes. More is on the way.

Jan Boddez

Also on IndieWeb News

I presented during the 2022 Netherlands WordCamp edition in Arnhem on turning all WordPress sites into fully IndieWeb enabled sites. Meaning turning well over a third of the web into the open social web. Outside all the silos.

The slides are available in my self-hosted Slideshare replacement for embed and download, and shown below.

I have been blogging a long time, and can tinker a bit with code (like a home cook). I want my site to be the center of how I read and write the web. Its purpose is to create conversations with others, who write in their own spaces on the web. The IndieWeb community supports that with a number of technical building blocks that allow me a set of pretty cool things. But all that IndieWeb offers has a high threshold for entry.

The key parts of IndieWeb to me, the parts that make interaction between websites possible, that allow any site to be an active part of many conversations, are much simpler though:

  • Microformats2 so that computers know how to interpret our blogposts,
  • some class declarations, so computers know why we link to some other web page,
  • and WebMention, the protocol that lets a web page know another page is linking to them.

Making interaction possible between site authors, across sites, just by writing as they already do, is both the simplest to arrange and the most impactful. It’s not something that site authors should have to deal with though, it should be in your website’s engine. WordPress in my case, and an enormous amount of other websites.
Ensuring that WordPress Themes, and Gutenberg blocks would support and could handle Microformats2 and classes correctly therefore will have a huge impact.

Over 40% of the open web would then with a single stroke be the open social web. No need for data hungry silo’s, no place for algorithmic timelines designed to keep you hooked.

WordPress wants to be the Operating System for the Web. That OS is missing social features, and it’s not a big leap to add them with existing web protocols. No website owner would have to be a coder, be it home cooking style or professional, to use those social features and create conversations. It would just be there.

If you build WP Themes, if you create Gutenberg blocks, you’re invited to help make this happen.

(also posted to Indienews)