We Need to Talk About Calendars

19 May 2026

Do you use a web calendar and do you know how to wrangle an ICS feed? I asked this question on Mastodon and in a private Discord server, and if my results are indicative, your answer is probably a variant of: "No."

I find this really interesting because, in further conversation, many people didn't know what these terms I was using are. For example, some people know what an ICS file is, but don't understand how that relates to being a feed. Or folks use Google Calendar or Outlook, but have no conception of that being a "web" calendar. Initially my results on Discord were much lower in the "Yes" category, until people got wind of these details. People are close to understanding, but not all the way. I find this really interesting.

It reminds me a lot of two technologies dear to my heart - e-mail, and RSS. Most people hate e-mail. There was a period when we were all excited by it and its possibilities, and my mother and I are some of the last adherents of this era, it often feels like. It's bizarre sometimes, how allergic people may be to open technologies that are easily accessible - big tech has spent a long time making open technology feel inaccessible, even though it isn't!

So my hope here is to demystify, to breathe life back into the world of calendars, and help inform everyone that web calendars are in fact very simple, and not at all scary! They're kind of like RSS but for events.

What's a web calendar?

A web calendar, also called an online calendar, is a form of digital calendar that exists as an online service, so you can access it from any device in any location. It also often supports sharing events, importing and exporting, and all sorts of nifty technologies that enhance a digital calendar for the world wide web.

But in essence the dividing line between a "digital" and "web" calendar is "the calendar is in an online location, not on my device" - it's not locally stored. It might be self-hosted! Or on the cloud (imagine me wiggling my fingers like worms).

Some common free-gratis web calendars are:

• Google Calendar
• Microsoft Outlook
• Yahoo Calendar
• Apple iCloud
• Tuta Calendar
• Proton Calendar

Some free-libre web calendars are:

• Nextcloud Calendar
• Feber

Okay but how do these actually work?

That's a very reasonable and cool question. We all sort of understand how apps work, I think - or perhaps, we all understand how little we know. We have some kind of interface, and then the app does a bunch of magic that we don't know to accomplish its usability goal. So similarly, these web calendars have some magic going on in the backend. But it doesn't have to completely be a black box, does it?

Well, web calendars generally use one of those main technologies on the back end: Either Microsoft Exchange, or CalDAV. And really, unless you're in an enterprise setting which uses Outlook in a major way, you're probably dealing with CalDAV on the backend. So if you ever see the words "CalDAV" you know that means "Calendar Doing A Ving (Dracula says "Web Thing")".

Because CalDAV is a well-defined internet standard, that means that it's highly compatible with all sorts of software. If your web calendar has "CalDAV" support, that means that you can access your calendars from dozens of desktop and mobile applications of your own choosing. I'm partial to Mozilla Thunderbird for this, but I've used Apple Calendar, Outlook 2007, and a half-dozen Android apps to great success.

Now if you're thinking "So if I have a Web Calendar, and it uses CalDAV, so I can access it entirly through third-party apps, I don't really need the web calendar frontend. I can just have a raw CalDAV server right?" You're correct! You could in fact just run something like Radicale and access it from a dozen different devices all through bespoke apps! That's the beauty of CalDAV... that's a Cal-DAMN! Cool software!

This is very much like e-mail! When you have Gmail, you don't have to use their website to check your email. You can log in on a bunch of different apps to send and receive your mail. It's in your control!

Now if you followed that link above and read up on CalDAV, you might have noticed that it stores information in a format called iCalendar. Despite their notoriety for naming things iWhatever, iCalendar stands for "Internet Calendar", and has nothing to do with Apple! And this brings us to the next cool thing I wanted to talk about: ICS Feeds.

Internet Calendaring and Scheduling

That's what ICS stands for, by the way. When you get event information from a CalDAV server, it will provide it as an ICS or ICAL file. This file contains absolutely everything you need to know about an event - its time, its location, attendee lists, recurrence, etc. When you download it, you can import it to your own digital calendar, whether that be local to your device or a web calendar of some sort, or even your own CalDAV server.

It's at this point that I discovered that the people who know what to do with an ICS file did not fully intersect with people who know how to subscribe to an ICS feed. And I think I can explain where that discrepancy comes from, and also hopefully illuminate how these kind of web technologies work!

Software in the WWW Era

Before the rise of Apps, the default form of interaction for all software was the "file". Most of us are probably roughly familiar with files and file systems, but it's a rapidly losing percentage of people. I've heard from friends who teach at universities that their Computer Science undergrads often need a tutorial on how saving files to folders works. In the world of Apps, all data is self-contained in objects native to that app, siloed away unless an explicit form of communication is provided. Even on the web, most sites now operate as Single Page Applications, where you go to the site and never think about things like the "url bar". If you need to share something, you press a share widget on the page, and it does some magic to give you a link that is compatible with whatever chat or social media app you want.

But this isn't how things worked in the World Wide Web era. Back then, software was built on a principle of file systems. You would open a drawer, and all the things inside it would spill out, and you'd select what you wanted to feed into the software. Websites were not an app, or even a single page - every single piece of information you wanted to view was provided as its own file. HTML, Hypertext Markup Language, reigned supreme. When you went to a web site, your browser didn't make a request to a black box which somehow magically gave you an app to interact with. Your browser went to a URL, and requested to download a file - an HTML file! The server provided it, and after downloading it, your browser would display it. If you've ever browsed my website, and this blog itself, this is how it works! My entire site is statically generated files, meaning you could theoretically save a complete backup of my website to your home computer for offline reading.

Back then, software wasn't expected to talk directly to each-other. Internet speeds varied wildly, sites had downtime, and wi-fi wasn't a thing yet. It was expected that all interaction over the world wide web would be mediated by files! This era produced many beautiful web technologies that are still around today, such as HTML, RSS, and iCalendar!

I think what causes a lot of confusion in the modern era about "what is a feed" comes from this different understanding of software. Nowadays, the majority of software interactions occur via direct communication. A client asks a server for something, constantly passing information back and forth. What can be confusing is that we had feeds in the world wide web era! They just were provided asynchronously.

Asynchronous Feeds

Let's compare with RSS. Have you ever downloaded an RSS file by mistake? It's easy to do. If you do, it looks very confusing, full of triangle brackets and esoteric terminology. What all those things do is define what the articles inside the feed are, and maybe even provides full text of said articles! But how come you can sometimes download that file, but also pass it to a reader to keep up-to-date with your favorite author?

When you provide an RSS "feed" to your reading app, you actually are just passing the link to a file. The reader software then takes that link, and downloads the file. It takes all the information from that file, and writes down everything in its own database. It then waits a bit, and when you aren't looking downloads the file again! It takes all the information from that file, compares it to what's already in the database, and flags anything different between the versions as "new"! That's it!

Theoretically, you could take the RSS file and hand it to a reader exactly once. It could read all the information, write it down, and then silently wait for you to give it another one. But you couldn't stay up to date that way, could you? It doesn't know where this information came from, so it can't go out on its own to get it. It's not really a "feed" if you don't feed it! It becomes an RSS "feed" when the path is provided for the software to consume it on its own diet.

An ICS Feed

But when you go to a website and it provides a link to an iCalendar file, that file can be used as a feed! Instead of downloading the file, you take the URL and provide that to your software of choice. Every software does this a little bit differently, just like every software has a slightly different flow for providing an RSS feed. For Thunderbird, for example:

1. Click "New Calendar"
2. Select "On the Network" and hit "Next"
3. Paste the URL into "Location" and click "Find Calendars"
4. The feed will be listed, and should be selected by default. Hit "Subscribe"!

All events provided via that feed will now show up in your calendar software! It's that simple! If the creators of the feed change something about the event, like the time, location, or place, your software will catch those changes and update your local copy! It might even alert you about that, if the software has that feature!

There's far more digital calendars with support for ICS feeds than I could mention, but here's a short list of free-libre options to get you started:

• Mozilla Thunderbird
• KDE Kalendar
• GNOME Calendar
• Etar
• Fossify Calendar

A Better Future

We've been talking a lot lately, in my corner of the web, about going to more open standards and a more open ecosystem. Divesting from Discord, switching to Linux, bringing RSS back, static site building... these are all things which seek to free us from the bonds of capitalist app enclosures.

And I think we can have a better future for event information than "posting on social media." You've probably missed an event getting rescheduled because it was only corrected in a post you missed, yeah? Maybe that's just me. But it happens! And what if you can't read a social media post because your account has been revoked for being transgender? Or you just don't want an account but they won't let you see posts on the network without one? My watch can't beep every time an Instagram post with event information is posted, but it could when a calendar event is coming up!

We can take back computers and make them usable for people again. We just need to learn about what they tried to take from us.