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. micro.blog 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.