Category: Wiki

All pages considered part of the wiki section

On #2022/11/12 I have created a VPS running Debian 11. It is a CX41 from Hetzner.com, and I installed Yunohost on it using this description.

Yunohost then provides a GUI to maintain the VPS. It also does the diagnosis and provides the infromation to fix issues. The first experiences are encouraging.
From 2014 I’ve used a VPS for a few years, but it became too much of a chore, and in the end I shut down the entire VPS, because it became unmanageable. I stil haven’t fully deleted it, but I should.

Yunohost also supports the installation of all kinds of applications (like softaculous on cpanel for hosting environments), which makes things easier.

It’s an experimental space first and foremost.
I moved my (and E’s) Mastodon instance over to it (and save on the monthly fee I paid for Masto.host before, folding it into this one). I’m also interested to see if using e.g. Bookwyrm and Pixelfed over it brings use value. These are all AP based applications. Or it can be a testing ground for other projects, e.g. Linqurator.
I have installed Fresh RSS read on it, and a personal NextCloud instance on it, both for my own use as well as for experimenting with apps in Nextcloud, before running them in my business’ Nextcloud.

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.

What I intend to do and why

I’ve been using h. in the past weeks, and I like the tool. It created/uses a W3C protocol and has an API I can use with a token connected to my account.
I want to integrate annotations I make with my notes I keep locally better. This points towards using h. ‘headless’ in the sense I push things to and pull things from the API, rather than do my annotations in browser. This would reduce friction in my note making flow.

There are several things I can think of, at different levels of difficulty to achieve.

  • Being able to submit urls with a page wide annotation, tied to how I save webpages and a motivation for saving with a markdown clipper.
  • Being able to annotate a page saved in my notes, and send the annotations to the right url in h.
  • Being able to update annotations.

The first is the most straightforward, and the first I will try to achieve.

Steps taken

Save new page annotations

  • Envisioned path:
    • Use markdownload to save a page in markdown in an Obsidian folder. Alter the template to have the relevant info in a predictable spot (h post status, URL, web archive url and motivation for saving)
    • Run a script that checks for new files in that folder and filters those with a status of not yet posted to h.
    • Run API calls to submit the selected notes to h.
    • Change the status of the notes in Obsidian to published to h.
  • Steps taken
  • Steps to take
    • Try out the minimal JSON / POST structure in Postman to get it right
    • Try out the same JSON / POST re-using an earlier micropub script to post from PHP to h.
    • Find out how to evaluate the response and then set the status in the Obsidian note, re-using the script I use to blog from my notes to WP.

I find discovery in Hypothes.is of users that are more than sporadically sharing annotations around topics interesting to me very difficult. To aid discovery for others I’ve listed below the Hypothes.is users I’ve encountered. Split in two lists, those frequently or moderately active or of higher interest to me, and those sparingly active or inactive.

Active

https://hypothes.is/users/tonz
https://hypothes.is/users/chrisaldrich
https://hypothes.is/users/HeinzWittenbrink
https://hypothes.is/users/mayaland
https://hypothes.is/users/nateangell
https://hypothes.is/users/jeremydean
https://hypothes.is/users/dwhly
https://hypothes.is/users/diegodlh
https://hypothes.is/users/Flancian
https://hypothes.is/users/remikalir
https://hypothes.is/users/danallosso
https://hypothes.is/users/mattmaldre
https://hypothes.is/users/gyuri
https://hypothes.is/users/mrcolbyrussell
https://hypothes.is/users/michael_rowe
https://hypothes.is/users/jbove
https://hypothes.is/users/peter_murray

Inactive or less active

https://hypothes.is/users/ruk
https://hypothes.is/users/JeremyCherfas
https://hypothes.is/users/benwerd
https://hypothes.is/users/judell
https://hypothes.is/users/actualham
https://hypothes.is/users/mpelzel
https://hypothes.is/users/mrkrndvs
https://hypothes.is/users/jgmac1106
https://hypothes.is/users/ma1m

Do you use h.? You’re welcome to let me know in the comments.

Third party services usually make it very easy to add something to your digital life online. At the same time it always means a loss of control over the material you share through, store in, collect with such third party services. If one such third party shuts down, decides to pivot, pulls up new pay walls and restrictions, blocks or deletes your account, you have no

The IndieWeb, basically an open web approach, starts with the notion that you have control over your own material. It’s your creative expression, your data. For that it’s useful to have your own domain. As long you have that, you can move whatever material you share there to other servers, services etc. Second, whatever material you share outside your domain on third party services, should originate on your domain, or end-up there as a copy. For instance I share messages to Twitter that I write here. I used to share check-ins made in Swarm/Foursquare to check-in entries on my site. In both cases whatever happens to Twitter or Foursquare, I have my own online original or copy to which I can link. When I want to link to something in a conversation I share the link to my own domain.

I treat my domain name as ‘the mothership‘ of all my online traces. It is how my blog keeps being my avatar.

These are the ways my domain(s) is / are my mothership:

  • My articles, here on my blog
  • My messages to Twitter and Mastodon written on my blog
  • My slide decks hosted and sharable on my own domains, not using slideshare/scribd
  • My photos, here, linked to my off-site copy Flickr
  • My shortened URLs using Yourls on my own domain tzyl.eu
  • My code repositories on Github have their own URL redirect from a domain I control, so I can move to another code hoster or my own and keep the same links I shared with others
  • My check-ins when I used Foursquare, copied into my blog

This page was created using my personal Micropub client. This allows me to post not only posts but also pages to my various WordPress websites. And to do so along several paths, such as directly from my local notes. This page is merely a proof of concept. My intention is to use this way of posting to better extend my publicly shared notes in my Digital Garden. For now it is just about creating new pages. A next step would be to also apply this to updating of pages.