Live data from Hacker News

Owning my own data, part 1: Integrating a self-hosted calendar solution

emilygorcenski.com

81–90 of 157 posts

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#81
I use the CalDAV protocol for my to-do list (tasks.org and nextcloud) and I've been wonder if someone could hookup CalDAV with MCP so I can talk to my to-do list to modify it without going to some proprietary solution.

Is this feasible? Has anyone seen a tool like this yet?

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#82

Earlier quoted context omitted.

It was 14 years ago, I’ve forgotten everything by now. 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.

bflesch might be suggesting that you (or some other motivated + heroic person) write a new spec for calendar collaboration, like what jmap.io is trying to do for mail. 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…

I thought the solution to datetime was almost always to use TAI plus a library to convert for display in the UI. (Or UTC and accept that leap seconds might cause bugs.)

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#83

Earlier quoted context omitted.

> 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. 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 alte…

[flagged]

> I'm not even sure you're qualified to comment then.

I'm qualified to point out that this is a hugely dickish way to communicate

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#85
How does this actually help with owning your own data and repatriating it?

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.

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#87

I know I will probably get pushback over this, but CalDAV sucks . People say that it's great and that it's easy; yet if that were true there would be way more self-hosted CalDAV solutions out there and they would be far more ergonomic than what's available. I was not impressed with Radicale. Because there's really only one calendar file I wanted to serve to myself, I tried implementing my own CalDAV server just for t…

I think the core issue with CalDAV (and by extension, the protocol it's build on top of, WebDAV) is one somewhat endemic with most W3 approved standards: it's way too overengineered to do too many things at the same time rather than a lean format. 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…

WebDAV is what it is because it's designed (largely by Julian Reschke who also took over the HTTP spec from TBL back then I believe) to be addable conflict-free and routable without complex payload inspection to existing HTTP services/practices. Its use of XML can be regarded over-engineered, but it follows what was available and considered adequate at a time that had much much more consideration for interoperability and multi-party buy-in than is even conceivable today. I wouldn't dismiss it so quickly, especially considering WebDAV is an IETF RFC not W3C spec to begin with.

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#88
I have the weirdest calendar problem: if someone sends an invite to my Fastmail account, it gets swallowed up by Gmail. It never shows up in Fastmail, and in the calendar invite it appears as if it was sent to my Gmail address even though it wasn’t. It’s the strangest thing and I don’t know how to stop it or even what’s causing it (Fastmail support also had no idea).

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#89

Earlier quoted context omitted.

[flagged]

> I'm not even sure you're qualified to comment then. I'm qualified to point out that this is a hugely dickish way to communicate

Come on folks, be nice, we are all here to learn.

Re: Owning my own data, part 1: Integrating a self-hosted calendar solution

#90
post #88

I have the weirdest calendar problem: if someone sends an invite to my Fastmail account, it gets swallowed up by Gmail. It never shows up in Fastmail, and in the calendar invite it appears as if it was sent to my Gmail address even though it wasn’t. It’s the strangest thing and I don’t know how to stop it or even what’s causing it (Fastmail support also had no idea).

Wow, that' sounds like something I'd love to figure out how to setup with my Fastmail...

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

Post reply on HN