I failed moving my Google calendar to Proton
79 comments
·January 15, 2025yoavm
TeMPOraL
> In reality OAuth Hopper can be used to abstract OAuth away from any endpoint - it isn't CalDAV specific in anyway.
You're doing Lord's work here. Thank you. OAuth2 has been the bane of my existence; it's basically the One Weird Trick to Prevent Automated Use of a Service.
true_pk
This is neat! I will take a look.
godelski
A bit off topic but why are calendars so hard? I recently moved from android to apple and I'm just really impressed no one does a dedupe operation on calendars. Seriously, who works on these things? I'll write you the regex if you really really need it but damn, if you're going to push fancy AI on me to make my life easier at least take care of all the annoying trivial bullshit that makes my life harder.
ttepasse
My pet theory is that it is the data model: everyone must support ical/Exchange and those only support events with a textual description.
Events may be a part, but not the only part of a good calender. There is a lot of stuff which could be part of a calender but doesn't necessary fit into the event paradigm: Fuzzy events like the car inspection you are putting of. Transit times - not just the fixed time span you get today, but integration of public transport or current car traffic, so that you can plan. If you're menstruating a period tracker. Your health and sleep data. The weather, the day-night-cycle for your location. All background data with time and date, which we have, but not just in our calendars.
And even traditional events are limited: I'd like to have a general repeating workday event but also like events in that workday as extra events. With a normal digital calendar they are clashing. Hierarchical events would be a solution.
Or multi-layered events, some years back there was this blog post on HN which made me rather unhappy with iCal:
TeMPOraL
My pet peeve: buffer time. Or, rather, lack of it. Almost every calendar event requires some extra buffer time before and after, for things like getting to event location and back, and/or preparing, etc. No calendar app I've ever used even supports the concept, much less does anything to help. Right now, I resort to having a separate calendar for "buffer time" events, which I currently fill manually; I'm working on automating this, as almost all events also have fixed buffer time, that's known to me, but again there's no way to record that fact in existing calendar software.
godelski
This is a great point! And in the class of problems I was trying to illustrate. There's a lot of low hanging fruit here. We're programmers, we should be able to take our frustrations and turn them into solutions! If we're not, then we're doing something wrong lol.
FWIW, in Apple Calendar there is an option for "Travel Time". This will prepend the event with some buffer value. When looking at the event on my calendar, in my iPhone, and ONLY in my iPhone there is a little : (vertical dots + car) symbol and saying (e.g.) "15 minutes travel time", while the event has a vertical continuous bar next to it. On my Macbook, the whole event is just expanded.[0]
My pet peeve: dramatically differing interfaces between devices. I do understand that at times this must happen. But there's no reason for it to in this case. But worse than that, when CREATING a new event on my Macbook it is just so much clunker. I don't see "Starts" and "Ends" until I click on the time, where it instead expands. Then I can see the "travel time" option (in iPhone it is "Travel Time") and if I click the end time I can only select from a pre-determined time of 30min to 3hrs with 30 minute intervals. If I select "starts" I don't get this. In both cases I can __type__ the actual numbers in.
[0] Update: while writing this comment, my macbook's calendar updated to show the vertical dots but does not include the little car nor the text (again with continuous vertical bar under actual event). Why did this take so long? "Just works" my ass. Arch linux has been more stable than trying to live by the Apple way.
ivan_gammel
This is really a good question. Progress with calendars has stopped 10-15 years ago, the only major innovation relevant to it was Calendly, but that’s it. I guess it’s hard to imagine new features or even incremental quality updates as a viable business idea.
jamalaramala
> I guess it’s hard to imagine new features or even incremental quality updates as a viable business idea.
There is market for privacy; but the missing piece, after so many years, is how to synchronize calendars in a seamless way.
ivan_gammel
It’s not just that. Manual entry is still a thing happening too often. Yes, some apps allow to put your booking in a calendar, but that doesn’t cover all use cases. You call, make an appointment — getting an ical via SMS after the call would be great. You open a website, then check there the opening hours or schedule, taking that information to your calendar app would be great. Etc etc.
thih9
It’s difficult to maintain basic features in a popular calendar, at least according to the ms exchange team blog:
> calendaring is particularly tricky. Why’s that? Well, consider time zones for a start – a meeting you set up isn’t necessarily in the same time as it is for me, and then you also invited people, from a whole bunch of other time zones (did you know some time zones are 30 mins off, not a full hour?) (…)
https://techcommunity.microsoft.com/blog/exchange/calendarin...
Then there is the “falsehoods programmers believe about time” list: https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... , with some counter examples: http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
godelski
I don't buy it. I do think the problems are not trivial but it's not like there aren't trivial problems within the larger problem.
Let's take a trivial problem: holidays. Every account you have comes with a holiday calendar. So if you got a Microsoft, Google, and Apple account you'll have entries in triplicate. These are all day events with identical names. There's a lot of hints to tell you that these are identical and you only need to display 1.
A bit harder would be birthdays. These might not be in a unique calendar. But the word "birthday" is a huge hint when it's an all day event.
I do agree that defaulting to a position of not destroying data is best (though here we'd never destroy data). But that doesn't mean we can't offer users assistance. We do have the capacity to let users merge events or in some way note that they are identical.
One more issue, why the fuck can't I move an event from my Google calendar to my Apple? In the worst case, just copy the damn thing and then hide the event. You can do this even when you don't have write access to the Google calendar.
So the thing I don't buy is that we can't do more. A programmer's job isn't easy. But it involves problem solving. I think there's not enough grumpy yet motivated people who will voice up such things because management usually says that it's not important. But these non important things add up. Life is complex so the little things actually matter a lot.
OptionOfT
Weirdly enough an all day event in Office 365 isn't an all day event on a day.
E.g, I record my wife's birthday in my calendar.
I create an event on April 12th, and mark it as an all day event.
What actually happens is that the calendar records an event that starts at midnight, and ends 24 hours later, and is marked as an all day event.
But, when you change timezones the 24 hours actually shift, which can be very weird when you get notifications that are 6 hours earlier.
TeMPOraL
> and then hide the event
Speaking of - hiding events is one of the features of Sectograph[0] I most frequently use. I think local event modifications on shared calendars are another big feature missing almost everywhere. In my case, hiding events lets me just sync the shared family calendar synced directly to my watch, and just hide the events I don't care about, as to not clutter the display, without deleting or otherwise affecting what my wife sees on her devices.
> So the thing I don't buy is that we can't do more. A programmer's job isn't easy. But it involves problem solving. I think there's not enough grumpy yet motivated people who will voice up such things because management usually says that it's not important. But these non important things add up. Life is complex so the little things actually matter a lot.
In Admiral Adama's voice: So say we all.
--
[0] - https://sectograph.com/ - may seem like a bit weird gadget, looking at the app screenshots, but it's true value comes from the same circular view being available as a watch face, giving you always-available view of the next 12 hours on your wrist. This is why I started adding bus/tram departures and event buffer times to my calendars - they become useful for quick checks on the go. IMHO, it's the only actually useful watchface on the Android smartwatch market.
Which is exactly why Google had to fuck it up with their Watch Face Format idea, aka. Manifest V3 For Smartwatches, aka. removing "smart" from "smartwatch". Fortunately, I'm not forced into it until my current watch dies.
TeMPOraL
> It’s difficult to maintain basic features in a popular calendar, at least according to the ms exchange team blog:
There's a large amount of things that regular people do with calendars every day, that could be automated or managed through better interaction paradigms, and to which those issues don't apply. That's a lot of low hanging fruits, that everyone's leaving to rot.
Like:
> meeting you set up isn’t necessarily in the same time as it is for me, and then you also invited people, from a whole bunch of other time zones (did you know some time zones are 30 mins off, not a full hour?)
99% of my calendar use involves events happening within days or weeks, and concerning me alone, me and my wife, me and my acquaintances, or me and some random local company. I don't care about timezones for those - they all happen in the same one, with the same DST shift.
(The remaining 1%? Timezone shenanigans happen at few distinct points in a year, and everyone knows to be careful around those and communicate out-of-band if needed. So again, not an issue in practice for users like me.)
Microsoft is thinking about calendars as tools for employees of multinational corporations. But calendars aren't only useful for managers frequently flying intercontinental; there's a lot of regular folks using them for affairs much more localized in time, space, and social graph.
ivan_gammel
Timezone stuff is trivial with modern libraries like Java Time API. Event entity and event identity is hard.
karamanolev
Eh, I don't buy that. Storage in UTC and converting to a local timezone for display / notification purposes has been the standard practice for a looong time.
What I would believe, I don't know if true, is that different applications support subtly different feature sets, integration has varying levels of support and correctness and so on. Additionally, I feel like vendors are incentivized to offer good support within their ecosystem, but integration with the outside world is a second-class citizen.
happytoexplain
"Just store it in UTC" will cause bugs for human time, which calendaring is the most complex example of (because it contains basically every other use case). Don't throw away the date and time the user entered. How you store it is the subjective part, as different choices have different risks. But don't just throw it away.
Also, the existence of this thread should be good evidence that it is indeed not that simple.
ivan_gammel
Storage in UTC is generally wrong for future events and doesn’t make sense at all for unbounded sequences.
Edit: better approach will be to store event as it was defined and include processing hints, e.g. when next UTC time of occurrence can be reliably established.
pluies
> Storage in UTC and converting to a local timezone for display / notification purposes has been the standard practice for a looong time.
All good until summer time kicks in and your recurring 9am meeting now starts at 8am, oops.
makeitdouble
UTC storage is standard practice, but not the best practice nor something that solves all the major issues a good application should be dealing with.
I'd qualify it as "good enough to not get fired" grade of decision, for people who don't care that much about calendaring in the first place or have the luxury ignore complex cases (we're back to "why are calendars so hard?")
freddie_mercury
A lot of this reads like "I wish Proton Calendar wasn't encrypted on their servers."
But that's like the entire value prop of using Proton Calendar over the many other options out there, isn't it?
rekoil
While I agree with you in general, E2EE can't be a blanket excuse for building bad applications. If your E2EE applications can't deal with data encryption in a way that makes them comparable to competitors non-E2EE products from a usability aspect, then they are still bad applications, regardless if we know that E2EE does make it all way harder.
I love Proton, but there are aspects of E2EE that they haven't worked around well enough at present, in my opinion.
The biggest pain points are:
- Collaboration
- Offline access
EduardoBautista
The issue is that the open protocols IMAP, CalDAV, and CardDAV weren't built with E2EE in mind. This is the big reason why you can't use 3rd party calendar clients with Proton.
ivan_gammel
3rd party client or support for those protocols is not the only solution to collaboration and offline access. Their own app must do it well first.
rekoil
If that's the only issue it should be trivial for Proton to release a slightly modified version of Thunderbird that allows decrypting an encrypted CalDAV XML. That could then be the basis for extending the spec to allow encryption.
Over2Chars
I think it's not about encryption as to the primitive tooling of Proton's calendar import, and maybe a little inflexibility on the author's part.
That's how I read it.
InsideOutSanta
Calendar is the one feature of Proton I don't use. For my calendar, the issues caused by encryption are not worth the additional security. But I don't want my calendar to be on Google, or some other large cloud provider, either.
So I ended up just self-hosting my calendar.
It's pretty easy to self-host a calendar, it can be as easy as dumping a bunch of PHP files on a server and connecting to a MySQL database (e.g. using Baïkal).
jamalaramala
Curiously, the easiest Google product to move away from is "google" (search):
I have been using DuckDuckGo for years, both for searching and browsing. I love the ability to burn the cookies after each session!
But I haven't been able to replace Gmail, Calendar and Maps (which are quite good products IMO).
It's quite ironic that "google" (search) has become one of Google's worst products.
true_pk
Good point! In truth, that was the first starting point for me as well. Then browser. Then everything else :)
rekoil
I've used Proton for like 5-6 years now, Calendar is definitely the roughest of their products. Good news there is they are rebuilding it from scratch with an initial (beta?) release scheduled for this year!
ploum
Any source? I’m interested!
rekoil
https://proton.me/blog/mail-calendar-product-roadmap-winter
> To support much-requested features like tasks, search capabilities, and offline access, we’ve started work on our next generation of Proton Calendar apps for iOS and Android, which we aim to release toward the end of 2025.
tobi_bsf
In my experience, these proprietary encrypted systems like Proton or Tutanota all have their shortcomings caused by their mandatory client software.
TheCapeGreek
Yeah, unfortunately this is one of those sandpaper tradeoffs for some users with some of the Proton suite and how they approach privacy (and its consequences for you as the end user).
I've had similar bugbears with their other products which end up in me not using anything except the core mail product.
They seem to improve things over time, but it's a game of patience.
E.g. I stopped using the Drive apps and only use it as an async backup store, because it keeps creating sync conflict files if you sync something you edit frequently (like an Obsidian vault). It also for some reason kept setting my user permissions to read only for my note files while it did this (on macOS).
kookiburra
I started out using Proton calendar but ended up discovering the dates are actually not encrypted, which I think is quite an oversight. Haven't found a replacement unfortunately so it might just be the best option for the cloud. For now a local notepad calendar it is!
jamalaramala
Why would one encrypt dates? They are public domain!!!
emersion
Another option would be to try this hydroxide patch (that i need to find time to review...):
Over2Chars
"And the url did not work because my work email is private (and will stay so)."
I have not tried this, but there is some email obfuscation feature:
https://proton.me/support/pass-email-alias
and other email obfuscation services.
Not sure if this would matter for something like a calendar import, as I'm sure how the traversal works.
Also, the author could have tried a Murena /e/ os de-googled phone.
Glancing at my Murena /e/ os "App Lounge" there's dizzying number of calendar options with high privacy scores.
Also, doing some poking around and testing rather than going all-in on proton mail's calendar, esp. if calendaring is so important.
That said I use proton mail's calendar for everything personal and it works "ok" for me.
preya2k
Switching from Google to Proton sounds like picking the lesser of two evils.
If you really want to “degoogle” you should probably go for self-hosting or getting a managed OSS product (e.g. managed Mailcow/Sogo Hosting). Otherwise you’re just switching from one crazy billionaire to another.
beretguy
That’s why I use pigeons and carve my weekly schedule into a stone with a chisel.
Over2Chars
Do we really know which crazy billionaire is the lesser of two evils?
We can merely choose between which is the seemingly better known evil.
Self hosting is a way to go. It would be nice if one of those "no code" shops could make it a bit easier or something.
InsideOutSanta
FWIW, Proton has no billionnaires, crazy or otherwise. They are governed by a non-profit foundation, though:
https://proton.me/blog/proton-non-profit-foundation
I do agree that self-hosting is best, but particularly for email, that's not trivial.
Over2Chars
Supposedly these "no code" sites can stand up a basic infra with very little effort.
If so, have a no code site set up a mail host. It might still not be trivial but it might be much easier?
eptcyka
Self hosting is a pain and not sustainable. I self-host, it is cool, but this cannot be the solution. It’d be like everyone going back to farming because walmart can’t be trusted - they cannot but the world will go to hell if everyone has to do everything themselves.
Over2Chars
I agree with you, or rather I think the barriers to farming are becoming lower, so maybe we should reconsider that homestead?
If this no-code stuff isn't a bunch of malarkey, it might be lowering the barrier to self-hosting that we've all been waiting for.
And self-hosting of email isn't quite "doing everything", it's doing one or two things.
It would be, to use your analogy, like growing your own tomatoes because Walmart's suck (and they do). Homegrown tomatoes don't have that "red leather" skin, a mysterious past, and may be quite inexpensive.
You can still get your Chinese made shirts, shoes, pants, and other inexpensive Chinese made goods at Walmart. But skip the Tomatoes.
kookiburra
I agree, though self hosting can be too hard for everyday non tech users. I think the fact that Proton exists, regardless of all their issues, is still a good thing and a move in the right direction
Over2Chars
I am a fan of proton, but we should always be ready for the bad news that forces us into another provider or self-hosting. Sooner or later it always happens.
Like lavabit or anon-penet.fi, cases where things go tits up for non-provider related reasons.
Google Calendar supports CalDAV, but only behind OAuth, which many clients do not support. I've created https://github.com/bjesus/oauth-hopper to solve that - it takes care of the OAuth steps and provides a clean CalDAV endpoint that you can use to read and write to your calendar from almost any calendar application. In reality OAuth Hopper can be used to abstract OAuth away from any endpoint - it isn't CalDAV specific in anyway.