Live data from Hacker News

I failed moving my Google calendar to Proton

shilin.ca

51–60 of 80 posts

Re: I failed moving my Google calendar to Proton

#51

Earlier quoted context omitted.

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.

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.

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?

Re: I failed moving my Google calendar to Proton

#52
post #8

Earlier quoted context omitted.

And Australia is Five Eyes, which means FBI/DHS/DEA/ATF all have warrantless access to everything in Fastmail via FAA702.

Seems to be a useful summary of 702 from a USA perspective: https://cdt.org/insights/section-702-what-it-is-how-it-works...

According to the article, Section 702 sunset on December 31, 2017.

Re: I failed moving my Google calendar to Proton

#54
post #28

Earlier quoted context omitted.

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 ar…

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.

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.

Re: I failed moving my Google calendar to Proton

#55
post #53
post #10

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!

Any source? I’m interested!

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.

Re: I failed moving my Google calendar to Proton

#56
post #8

Earlier quoted context omitted.

And Australia is Five Eyes, which means FBI/DHS/DEA/ATF all have warrantless access to everything in Fastmail via FAA702.

Seems to be a useful summary of 702 from a USA perspective: https://cdt.org/insights/section-702-what-it-is-how-it-works...

This is out of date. We know now from multiple different sources that 702 is routinely used illegally to spy on US persons as well.

It has also regularly been renewed and is still in full effect, and appears that it will remain so in perpetuity. It is the #1 most used source in US intelligence gathering.

Re: I failed moving my Google calendar to Proton

#57
post #28

Earlier quoted context omitted.

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 ar…

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.

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.

Re: I failed moving my Google calendar to Proton

#59

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.

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:

https://julian.digital/2023/07/06/multi-layered-calendars/

https://news.ycombinator.com/item?id=36617504

Re: I failed moving my Google calendar to Proton

#60
post #32

Earlier quoted context omitted.

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?) (…) h…

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…

"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.

Post reply on HN