Instead, initially went with the approach of hosting my dynamically updating iCal file in an S3 bucket and using ICSx5 on Android to sync with it. No CalDAV needed – just HTTPS.
However, FOSS calendars for Android still suck, and for some reason I couldn't get ICSx5 to work within GrapheneOS, so I now use almost the same approach but with Proton Calendar which happens to support calendars from direct links to iCal files. It's not perfect, but it suits my needs enough.
I think the author's approach for using iCalendar format is a good one, though what I've discovered is the amount of support for various iCalendar features varies drastically between calendar software. Rather than dealing with that headache, I somewhat gave up and decided to shove most metadata into the description field rather than use the respective properties.
EDIT: My use case is software I wrote to grab data from various sites (Eventbrite, Meetup, pub trivia companies, public event calendars, etc.), filter for only social events I would be interested in, and combine them into a single calendar I can view in my normal calendar software.
I agree, the protocol sucks. But we also had a ton of trouble handling Exchange and Google’s non-compliant CalDAV server, which all the users blamed us for.
Now that I work at Google I can see that gCal apps use an entirely different protocol.
IMO the quality of software is only pushed forward by motivated individuals with the right skillset.
[1] https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-22... [2] https://www.rfc-editor.org/rfc/rfc8984.html
What I do know for sure is that it‘s feasible for a calendar server to service both JMAP for Calendars and CalDAV. All our work in that regard is open-source in the Cyrus server [1] and is used at Fastmail.
Apart from the exchange protocol one also needs to convert between iCalendar and the data structures used in JMAP. For this, I am currently working on an IETF RFC [2]. Anyone also interested in implementing conversion between iCalendar and JSCalendar, please contact me! We have a test suite for interoperation tests.
[1] https://github.com/cyrusimap/cyrus-imapd [2] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalenda...
To be honest if I were to do that today, I’d vibe-code it by writing a strong set of tests against the protocol rfc, then a client against the tests. The client would be low level and have higher level interfaces in various languages.
I know that calendars and datetime management suck, hard. I hazard a guess that several people have already started trying to replace caldav (because of the suckage of caldav) and have quietly given up (because of the suckage of datetimes and timezones).
It was hard because of the debugging blindness, not so much date-math itself. We had to do hardware-level things.
Worse, imagine a recurring meeting, every week at noon. You've got the TAI for the original instance, but as you cross a DST boundary, some places will shift according to DST and others won't, and thus you have half the attendees showing up at the wrong time.
Finally, TAI introduces the leap second bug for calendars. When you schedule a meeting for noon next year, you want that to happen at noon, not now plus however many seconds. If a leap second is introduced, you don't want that meeting to happen at one second before or after noon.
TBH, if you find yourself in a situation where you need to deal with calendar events, I recommend updating your CV.
I also realize that there might well be complexities involved in calendar software that I'm unaware of. Hence my comment - I'm genuinely interested to learn. That said, I think your examples are all fairly clear examples of errors in reasoning by the programmer. Specifically they stem from conceptual mistakes regarding the relation of different logic domains (by which I'm referring to storage, display, scheduling, etc).
You never move events around in TAI (the unambiguous storage format) just as you don't go manually flipping bits in an SQLite database. You always work in a localized time because that's what the user is reasoning in. And you use the datetime library to implement as much of those manipulations as possible.
> US vs Germany, conflicting DST rules.
Go back to the era before smartphones and PDAs and the internet. You're in Germany on a business trip. You call your secretary to reschedule next weeks meeting back home. You don't use German time when doing that, you use US time.
Events have a location which has a timezone. Scheduling happens in that timezone. Blindly using the current local timezone of the device is a reasoning error. Storage, scheduling, and presentation are distinct logic domains.
> you have half the attendees showing up at the wrong time.
There is a single unique TAI time for a given event (after all that's the entire point of using UTC or TAI or what have you). All attendees will see an equivalent local time barring a bug in the datetime library.
See my earlier point regarding which timezone to use for the computation.
> TAI introduces the leap second bug for calendars.
Only if you make the mistake of attempting to manually manipulate your data storage format. The point of TAI as opposed to UTC in this specific case is to offload the complexity of handling leap seconds onto the datetime library so that you don't need to worry about it.
You actually do. From the point of view of future scheduled events, a event scheduled for 13h00 in a specific timezone is still "13h00 in a specific timezone" even when crazy people on that timezone suddenly declare a new Daylight savings time to start before the event happens. All future "timestamps" are prone to move due to such shenanigans. And you need to keep your timezone DB as updated as possible to update thing as soon as possible, if you don't want users with wrong times on their future events.
If you're not doing something like full rfc9557 https://datatracker.ietf.org/doc/html/rfc9557 "Internet Extended Date/Time Format (IXDTF)" [iso 8601 local time + as-of-now known timezone offset + IANA timezone] as "timestamps" you're probably truncating important information that will bite you back later if you're doing a calendar/scheduler.
After glancing at that RFC I'm unclear about the purpose of the UTC offset. Is it simply an error check to catch the case of a datetime library with outdated timezone information? Otherwise it seems like the library will have all the historical information on hand so it shouldn't have any use for it.
However it doesn't seem particularly difficult to fix. My error was suggesting using TAI for storage. I guess that works only for events in the past. So the timezone that the event belongs to is what should have been used for storage, you should forget leap seconds exist because this is a human centric calendar so who cares, and you should trust the datetime library to just do the right thing when converting timestamps.
Is there some other issue I'm missing? Because so long as all the timezone complexity is stuffed into the datetime library (and thus NotMyProblem™) it seems like the really difficult part is already solved for you.
But timezones are super byzantine. Especially when the rules update. More especially when the rules update on short notice.
If you scheduled an event at 5 pm local time at some place on some day and the rules change, the event's UTC (and TAI) would change. But you may want to confirm with the user, because maybe they're calling into an event somewhere else and they entered their local time but the event is really scheduled in the other time.
You might also have fun when multiple clients are using the same event and the clients and the server don't all agree on timezone definitions. iCalendar suggests that the timezone definition be included in the files, but my experience is definitions are often missing and most things ignore the definitions if present; you've got to include a timezone name the software is going to process as you want or you won't have a good time (or use UTC and hope)
If the event was scheduled in the DST window, the time may no longer exist, or may be ambiguous. iCalendar has rules for that, but they might not actually meet your user's needs (otoh, who is scheduleding things at 2-3am on a Sunday ... probably not a lot of people)
Isn't that scenario unsalvageable regardless? It presumably means one or more of the devices are displaying the wrong time to the user. Or at least will be upon arrival in the timezone of the event.
For example (intentionally extreme) suppose the library used by my calendar thinks EST is -4, the OS on my device thinks EST is -6, and everyone else thinks EST is -5. What possible program logic could prevent disaster in this scenario?
It's a really interesting edge case to point out, I'm just not clear what a sensible algorithm for handling it would look like. I strongly suspect that assuming that can never happen is the right answer. Everyone agrees the event is scheduled for 9 am EST. If outdated client software translates that to PST incorrectly or displays the incorrect time on the clock then the affected user is going to have issues and I don't see what the programmer can realistically do about it.
> ... DST window, the time may no longer exist, or may be ambiguous.
Assuming the timestamp disambiguates the daylight timezone from the standard timezone this should be handled gracefully by the datetime library since the stale timestamp is merely "out of bounds" for that timezone now that the laws changed. I'm failing to think of a scenario where it becomes ambiguous (although reasoning through this is once again reinforcing my view that we should have ditched DST long ago).
However this did cause me to realize that there's an additional edge case for far future events where the timezone is modified multiple times. If the event timestamp was never updated in the interim you land in an ambiguous situation and have no way to detect it.
I'm not sure that particular edge case is worth worrying about, but it seems like tracking a second timestamp indicating the last time that the event was processed by the datetime library would resolve it. The library should hopefully have all the necessary historical information on hand to update a long since stale timestamp (I haven't tested this though). Anyway if it doesn't I don't see that there's anything you can do about it.
Well, sure, it'd be nice if we could all spend our time building things to give away for free, but it's just not always possible. Life happens and people shouldn't have to explain or apologize for it.
The result is a protocol that's essentially become a furball of different ideas mashed together, which inevitably leads to the situation where a lot of services just... don't try to be full spec compliant since it's out of scope for what they actually want to do.
I don't think I've ever seen a W3 data format spec that didn't end up this way, it just always seems to happen. (It doesn't seem to happen with their lower level protocol specifications.)
It just builds on actual HTTP, i.e. you have to actually think about the transport layer in a way that’s out of fashion now.
And some people don’t like XML.
It’s certainly true that CalDAV specifically is complicated, but… multi user calendaring is intrinsically very complicated.
Other systems are not less complicated, they just tend to be more vendor specific.
It’s also a good story about the conflict between startups and open source, building products, and software development in general.
[1] http://www.dreamingincode.com/ ; https://en.m.wikipedia.org/wiki/Dreaming_in_Code
It mostly works great, except for 3rd party Office365 calendars imported into Nextcloud. It has issues with some events on some clients displaying correct time when event invitees are from different time zone.
To sync with Android I use DAVX5 which runs a background sync service (open source and non-root). I had a lot of issues getting it working, could be because of different CalDAV implementations. DAVX5 to ZOHO calendar sync takes forever.
Evolution on Ubuntu has pretty good CalDAV support, but it would refresh the entire calendar each time upon switchin between the mail view and calendar view. Refreshing that ZOHO calendar takes forever and ZOHO has pretty frugal rate limits, so it ends up soft-banning me.
Latest Thunderbird has a CaldDAV incompatibility where it expects a different HTTP success code. ZOHO gives a 200, but Thunderbird expects something else. (PS Thunderbird CalDAV code is written in JS). PS This only happens on the second calendar. Whenever you add a second one, it starts failing.
So it is quite a pain, at least with ZOHO.
Well you also can't integrate this into most calendars. I don't even know what the hell an iCal file is. I haven't even heard "iCal" in what feels like decades.
> I know I will probably get pushback over this, but CalDAV sucks.
All the alternatives are worse.
I'm qualified to point out that this is a hugely dickish way to communicate
Data is saved in plain text files and I track/backup it using git.
Over the time I've accumulated some interesting modifications:
- Authentication runs with pam on the host system.
- To enable sharing of calendars I run a periodic script symlinking the calendars to all authorized users. Unfortunately this suffers from combinatiorial explosion.
- Using a rights plugin with custom CalDav Attributes and a modified web plugin I added support for access Control Lists.
- To enable public calendars you give read permissions to the `public` user using ACL. Then a nginx hack gives blanket acces for read operations:
location /public {
proxy_pass http://127.0.0.1:{%RADICALE_PORT%};
include proxy_params;
proxy_set_header Authorization "Basic {%RADICALE_PUBLIC_AUTH%}";
proxy_hide_header Authorization;
add_header Access-Control-Allow-Origin * always;
add_header Access-Control-Allow-Methods "GET, OPTIONS, PROPFIND";
add_header Access-Control-Allow-Headers "Depth";
limit_except GET OPTIONS PROPFIND { deny all; }
}
These public calendars are can be viewed on a web calendar (https://gitlab.nomagic.uk/popi/js_calendar_from_ics)I should probably write a blog post about the setup.
I have two calendars, one on my personal server running Mailcow (SoGO) and my work calendar with Fastmail.
They don't work together- I've never found a way to get mailcow's calendar to work with other tools well, and so I spend time syncing between them semi-manually.
I've wanted to de-couple the calendar for a while but the only alternative I knew about was Nextcloud, which I think is a bit heavy weight.
This Baïkal looks great and I can't wait to give it a try. Doing this will also allow me to explore changing out Mailcow for another self-hosted mail service.
If you want to increase the resiliency of your data, look up the 3-2-1 backup strategy (and maybe also RAID).
Back in the early 2000's I used Mozilla Sunbird to host my calendar on my personal Win2k server via IIS's WebDAV module… I don't think CardDAV was a thing yet but I might be mistaken.
I ended up importing all that data from it into my Google Calendar which is kind of fun because I've got all my homework and whatnot for college courses on there if you go back far enough.
Sunbird was abandoned. I haven't looked recently to see if there's a reasonable replacement that might run on Windows.
When I do eventually revisit this I am going to look at DAViCal again, as well as Radicale[1], and now Baikal.
I really don't understand how these 2 major providers cannot fix what seems to me such a basic feature.
If using my own system would solve it, I'd do it immediately, but I am afraid that it would be just the same: meeting created on Outlook and imported with 2 hours difference.
Also, alot of companies actually prohibit syncing between personal and work due to data leakage issues.
1. Create a memories like feature from my photos to send on my cell phone, grouping by different features I like: anniversaries, similar activities, A `Me an X(X is Spouse, family, friends etc)`, Over the years(how x has evolved over the years).
2. Be able to save photos taken from my device to my servers.
I've set up three true-nas machines in different places with 2TB of space and want to slowly build this feature.
cloudflare tunnels is a game changer, I can't believe it's free.
Could you explain cloudflare tunnels are secure. I understand not punching holes through one's firewall and dealing with a residential connection that's often targeted for exploits. However, if one targets the tunnel endpoint to exploit is it more secure even though it's still exposed to the public?
[1] https://www.synology.com/en-global/dsm/feature/photos [2] https://www.synology.com/en-global/dsm/feature/moments
But, solutions like FreeBusy.io do offer connections and work well on calendering polls, etc.
When working with a world locked in Google, Apple, or Microsoft calendaring/groupware solutions on scheduling, it can be a hassle. But, if AI had to roll my own caldav, I probably would not so kudos to the author and effort here.
Check
"calendar systems suck. All of them."
Double check
"I’m trying to break off of big tech as much as I can"
I wish I could check this more ...
I've had similar needs/desires/gripes with my calendars and the terrible state of calendaring apps for a while. So thank you for scratching your own itch and sharing it with us.
I'm curious when you say that "[CalDAV] is an area begging for disruption". Can you enlighten us as to what your wishlist could be for (a) better protocol/systems/ecosystem might be? (a rant about your pain points might work too).
Thanks again!
My recurring events are all blocked off on the calendars already ("private" for personal events on my work calendar), so it really is quite a quick update.
I only need to manually add some appointments per week (not even every day, I'm a lucky guy) and realized I do not even need a grid layout for my calendar.
Having worked with times and dates in my favorite programming language already, I feel confident I can make something simple based on the standard default classes.
Even running something as simple and important as a calendar through third-party apps has started feeling very strange the last years.
The integrations that are installed on the end devices (phone) sync all that private data into the cloud platform regardless of the backend server. State is shared.
Google Information Services, and Apple's backend's unpublicized equivalent both process and store that related data, regardless of the phone you choose to use or the options you choose on that phone. There is a reason gigabytes get sent up to the cloud every evening, and its all encrypted.
Until you remove the implants on your phone you won't be able to receive any benefit from repatriating the data. That requires jailbreaking, or installing a new OS (something like Graphene), which is model specific due to compatibility issues.
One thing for which I don't have a solution yet, and neither does that article seem to address, is how to send invites. My data is one next cloud now, so if I create an invite it sends it. But if I create a it from a client (eg phone) it doesn't. The best I've found is manually export as ics and send an email myself, which ain't great.
Anyone has a solution for that?
Last I played around with it it all worked, somewhat. It does require you to use baïkal as your caldav server though.
services:
baikal:
image: ckulka/baikal:0.9.5
restart: always
ports:
- "XXXX:80"
volumes:
- /mnt/baikal/data:/var/www/baikal/config
- /mnt/baikal/data:/var/www/baikal/Specific
volumes:
config:
data:
To be fair, I think the author's main work was spent on tailoring those calendar import/export scripts. :)
As for your setup, what do you use for calendar & contacts hosting? I couldn't find any details about that on your website.
Also did you create a Google account using your fastmail address? I haven't tested it, but it's possible this causes a hairpin route where Google supresses the outbound email since it thinks it can directly modify the calendar.
I had a theory that maybe at some point I set up iCloud with both of these accounts (fastmail + gmail) and it's somehow intercepting these and rewriting them. It's not a super strong theory. Another thought is maybe it's a DNS setting somewhere?
I use Fastmail for my email, but due to... life, I still do all calendaring on Google, and so I often miss events that get sent to my Fastmail...
Other variants of this malady include:
- Building a todo list app. - Building a web framework. - Editing Wikipedia articles. - Building your kernel.
This part confused me a bit. Wouldn't running the NAS at home be more safe and secure? Or are they talking about backup safety?
Everything they mention can also be accomplished on a home NAS or something with plenty of security. I don't think anything is really justified here besides simplicity? Which..this isn't that much simpler.
Which..$100/month is pretty expensive for what's basically an N100 with support.
Ultimate self hosting that. Also only costs $15/year approx.
I'm in the Proton ecosystem, but from what I understand their Calender kind of sucks right now.
Is this feasible? Has anyone seen a tool like this yet?
Citizenship application is asking for my travel for the past couple years. And I have no idea. Especially since in Europe a weekend getaway to another country is feasible.
Some sort of long term tracking would have been really useful
... but they will be able to know if you're lying to them because they are trained to read people.
At Qbix, we build software for communities to collaboratively manage various things, and that includes events. For example, here are three sites we built, all different:
1) https://yang2020.app for Andrew Yang's 2020 campaign and Yang Gangs - to help people collectively organize and knock on doors, etc.
2) https://new.freetalklive.com for a libertarian show that pulls their episodes into the site, and let people watch and discuss them
3) https://gba.community for their annucal conferences in Washington DC - all the speakers, events, etc.
We've long ago implemented integrations with people's devices (phones, computers). You can add contacts to your address book using .vcf files, and they can even contain thumbnails. They don't need to include people's phone numbers, they can include their IDs on your site, and URLs to contact them.
Similarly, we have a button to subscribe to calendars, and it even works on MacOS. Imagine each user having a calendar appear on their phone. The subscription will pull new events into the calendar, update and remove old ones. About the only downside is that the OS usually suppresses any VALERT info that we place there, so you can't place alerts on these events. But you can have location, directions, etc. You can have a URL for group rides. We've built it all!
For both contacts and events, what you really want is access control - some people can see some things, others can see other things. If you paid for an event, you can see the location and time, for instance. You can maybe see the speakers, etc.
I've been thinking about it: certainly most of the numbers in my contacts list are probably invalid by now. But there's definitely a delta of finality to going "oh there's like 10 people I will ever call and that number is only going to go down... "
I don't connect google to my phone anymore, so at least they don't pollute any data elsewhere
FOMO? That odd chance you may need that contact.
Last time I tried I couldn't find a way to bulk delete contacts. I had to delete them all one by one. I couldn't stand how tedious it was and gave up. I don't feel any kind of sentimentality towards these contacts, given most of these people I haven't spoken to in nearly 15 years
I don't connect google to my phone anymore, so at least they don't pollute any data elsewhere
It was my main reason to purchase Motion but they eventually removed it.
It seems like the author has very different needs than you.
The cobbler's children go barefoot, so I haven't come up with a good solution for us... >sigh< It almost makes me want to hitch my wagon to a hosted product/service. Almost.
Comparing a paper calendar to a digital one is like comparing a Nokia 3310 to a modern smartphone. Yes, technically both are "a phone" but that's roughly where the similarities end.
Set up a webcam stream of the calendar
How do you share it for common events with others?
Share the webcam link or ring them up on the telephone if we are (jokingly) going traditional.
Why not make it more convenient for them and pipe the webcam stream through a script that OCRs it on change (or on timer) and makes it available as an .ical file that others can import via a link?
Also it's 2025, you can do it fast and robust by piping it through an LLM instead, with a prompt like "turn this calendar image into an .ical file pretty please".
/s, but only a little :). I've honestly thought of doing that for real, except with a feed of my laptop screen, to sync availability (busy/free) info from my work calendar to my family one, because it's way easier than trying to argue the point with corporate IT.
(I've changed jobs since then, and now I'm using a lazy hack on top of some random Fastmail-friendly cloud app.)
https://www.plantuml.com/plantuml/uml/VPBFQXmn3CRlynGYzzdUXn...
1. Create a shared family calendar 2. For things that need to block work calendar, invite my work email to the event.
Ownership is not about storing everything at home (or well, it's part of it), but having control over your data, which you can easily have while at the same time using the convenience that the cloud offers.
In the cloud your major concern is not losing data, but losing access to data, and you can counter that with making backups.
If privacy is a concern, use something like Cryptomator[1] to source encrypt data before uploading it. Cryptomator in particular integrates well with mobile phone operating systems, and has clients for all major operating systems (yes, Linux included).
Source encrypt your backups as well, and nobody can read your data besides you.
Ownership is not just about r/w control of your data but also over what software gets access to it and what that software does. Not just about privacy, but knowing the process and being able to alter it to your desires. There is no way to control that unless you run your own servers.
If it does, I assume you also roll your own network equipment. If you're worried about surveillance, know that you're far more likely to be targeted at the network port than at your data.
As for the process, the cloud (for storing data) is nothing more than a remote fileshare that someone else keeps running. If you have an up to date copy of your data you can change the process any way you like.
Servers are not free, nor are they fire and forget. Once you setup a server and decide to open it to the internet, you become a target, and you will be found. There are bots scouring the entire ip range of every residential IP network looking for juicy targets, and when they find something they record it for later use. Then when some new 0-day is found for service X that you're running, they don't need to scan, they can just lookup in their database an exploit right away.
I'm not against self hosting, and god knows I've been doing it for decades, but it is very rarely worth the hassle compared to the gains. The power cost alone of running a server is more than the equivalent cost of storing it in the cloud (assuming we're not talking media servers, but regular user created data).
The worst argument I usually see is people self hosting mail for private, completely oblivious to the fact that there are usually 2+ people in a mail thread, and something 68% of the worlds population runs on Google/Microsoft/Apple/whatever, so while you may keep your emails private, if they're targeted for being scanned they have already been so.
For other things it's about being in control, if just for tinkering. I self host mostly to not being reliant on 3rd parties for everything and to just know how it works. I don't do it for privacy. IMO if you want something private, you don't put it on the internet.
The moment you start opening ports you're no longer remotely safe. Cloud providers have dedicated staff monitoring services (or monitoring systems monitoring services) for anomalies, as well as people monitoring their networks. These same people will also know in advance when a new patch is coming for some 0-day exploit that might leave them vulnerable.
Compared to your setup at home, where you will patch it "eventually" (at the earliest when you get home from work), and you won't know if you're the target of an attack until your server gives up.
Not to mention the risk of losing other data. The LastPass leak a couple of years ago was made possible by attackers gaining access to an unpatched Plex server on a developers home network, from which they could gain access to his work laptop. LastPass had questionable security practices sure, but the validity of the attack still stands.
Unless you use Google Timelines. Then you’re out of luck.
https://mjtsai.com/blog/2025/03/24/google-maps-timeline-data...
I'm happy with Apple and iCloud holding our personal contacts and calendars. I'm happy with Fastmail holding our email. I still have local (and other online) backups, of course.