Category: Indieweb

I read lots of RSS feeds, for which I use a FreshRSS instance that is hosted on a VPS I rent from Hetzner.
To read I can use the FreshRSS’s own web interface, but on my laptop I use a personal interface.
That personal interface allows me to not just read, but respond while reading.
This is the original vision for the World Wide Web, in which you don’t just read, but write too, and where reading and writing are part of singular experience.

What my personal interface does / allows:

  • Show me my folders of feeds (the folders are in FreshRSS, and named / sorted according to my ‘reading by social distance‘)
  • Click open a folder to load unread items in that folder (using the FreshRSS API)
  • Click open an unread item if the title catches my eye.
  • Clicking on a ‘Respond’ button reveals a (larger) response form to fill out
  • Submit the response form, calling a processing script on my local machine in the background, and continue reading
  • Mark a folder or all feeds as read (using the FreshRSS API)

The response form allows me to do several things, both individually or simultaneously

  • Post a bookmark, favourite or reply to my blog, my company’s website and other WordPress sites I control (using IndieWeb micropub)
  • Create a note in my Obsidian vault (by writing to the filesystem directly)
  • Create a page annotation in Hypothes.is (through the Hypothes.is API)
  • Post to one or both my Mastodon accounts (through the respective Mastodon instance API)

I am in the process of slowly adding additional features from my list of ideal feed reader capabilities. Currently I am working on being able to tag feeds (readers usually only allow adding tags to items), so I can not just have folders but also subsets based on tags (e.g. coders in Berlin).

Screenshots (status February 2026):


The general overview of my reader, listing the folders in my FreshRSS instance. Clicking one reveals unread items.


Every unread item has a Respond button beneath it.


The response form allows various texts, and has a selector for bookmark, favourite or reply type of responses.


A response can have one or more destination: blogs, local notes, hypothes.is annotations, or Mastodon accounts.

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.