Category: Indieweb

Brief overview of how I’m active in the fediverse.

My site

I would prefer this site to be the centerpoint of my fediverse presence. For now that isn’t fully feasible, but it will be over time. Already the building blocks for WordPress to be a fediverse actor exist. The Activity Pub (AP) plugin and Webfinger plugin by Matthias Pfefferle are useful, just not allowing enough granular control yet to my taste. For one, the AP plugin exposes actual usernames of my WP site, a disclosure I don’t like. I need to be able to set the actor names for AP, through the AP plugin and/or the Webfinger plugin. Second, the AP plugin allows sharing my blogposts but only all blogposts, and I want to be able to only publish certain categories of posts as well as individual posts marked for sharing through AP. Third, the AP plugin doesn’t yet take into account the interaction parts of AP (like follows etc.).

Mastodon

I run two Mastodon instances, one hosted at Masto.host. Masto.host has been a very reliable service since I started hosting with them in 2018. I ran a personal instance (m.tzyl.nl) with them until late November 2022, and started one for my company (m.tgl.eu) early November 2022. I run my personal instance of Mastodon on a VPS with Yunohost, at m.tzyl.eu

Discoverability hack

I have added simple text files to /.well-known/webfinger to both this site and my company website that allow discovery of my existing Mastodon profiles through my site’s and work e-mail addresses. This is just a hack, and I should replace it with actual functionality to disclose actors on both those sites.

Bookwyrm

Bookwyrm is the book reading application on AP. I have an account at the primary instance and supported them financially for a while, but haven’t used it much since spring 2022. This is one of the things I want to do myself through this site.

Potential AP projects

As said above I’d like to be able to share my reading through AP from this site. I would also like to be able to share my planned travel and/or check-ins through this site in AP. Specifically travel plans (Dopplr like) are of interest to me. AP, unlike this site, would allow non-public sharing of this information to followers only.

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.

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.

Current status:

  • Created a working way to submit JSON formatted blogposts to this site, code on GitHub
  • Included that in my earlier scripts to create posts from my feed reading, that I now no longer then have to post by hand.
  • Created a Microsub client to replace my feed reader, in which I can respond directly from within the page I am reading, and do so to different websites I maintain.
  • Combined the same basic script with a local webform so I can very quickly post something. I don’t think I will be using this possibility much but it was a good way to add a front-end to the micropub script first and fast.
  • Can take a local markdown file written in Obsidian and post it as html to my site. This is by far the most useful to me
    • I write my blogposts in Obsidian, drafts live in a specific writing folder. They have two inline data fields, status and tags. While writing a note has status ‘writing’, when it is ready to publish I set the status to ‘draft’.
    • Within Obsidian I use the same status field to create a dynamic overview of posts being written, ready to publish, and previously published (using the DataView plugin).
    • When I’m ready to post, I hit a hotkey which launches my PHP script. It looks at all files in the specific writing folder and checks for files that changed within the last few hours and if those contain a status field ‘draft’. For those that do it transforms the markdown in those files to html, and then posts that to my site, using the tags in the other data field to tag and categorise the post. It also sets the status field in my notes from ‘draft’ to ‘posted’.
    • I could also run the script every hour or so using a cron job, so that anything posts automatically, while I go on with my other work.
  • Use the form in my feedreader to save an article in markdown to my notes in Obsidian with my rationale and some remarks.
  • Use the form in my feedreader to post an annotation to Hypothes.is (similarly formatted to posting it to my notes in Obsidian)

Rationale:

Local first, personal, narrow band
See blogpost.

Narrow band means:
my preferences can be treated as default inputs
my tasks are predictable to me
together they are functions with parameters, aka code.

Sources:

Micropub standard
IndieWeb wiki on Micropub
Tips from Jan Boddez (in Dutch)
Jamie Tanna’s work on his personal micropub client
Jamie Tanna’s tool to get authorisation tokens manually, great for testing/development.
Parsedown, which I use to translate markdown files written in Obsidian, to HTML for my site.

I started self-hosting my presentation slides in september 2020. The immediate trigger was the sale by LinkedIn of Slideshare to Scribd, and the resulting changes in access and tracking.

I set up two separate WordPress sites to host my slide decks.
tonz.nl which hosts my Dutch language slides
tonz.eu which hosts my English and German language slides.
With my hosting provider I checked if it was ok to host a site whose only purpose is to provide downloads, as nominally it would be against their ToS to provide a download website. My purpose, sharing my own slides was no problem, as the expected traffic is light anyway.

The short domain names, and my ability to create URLs on those domains as I want, allow me to create short easily sharable URLs for my presentations. I announce the URL on my slides during delivery, enabling participants in the audience to immediately access and reshare my presentation file and/or notes, and embed the slide in their own sites.

I use the Speakerstack WP plugin to manage my slides. The workflow is uploading the PDF to my WP media library. The plugin then uses ConvertAPI to convert my slides PDF to a series of images and adds them in an embeddable slider. That slider can be seen full screen.
Next to that I create a page, with the short URL mentioned, in which I embed the slides, add a transcript, links to blog posts and PDF download.

I am now in the process of uploading presentations to the two sites, creating the pages and replacing the original Slideshare embeds with the new self-hosted embeds. It is a pleasing experience to bring slides home.