mirror of
https://github.com/go-vikunja/vikunja.git
synced 2026-03-09 07:13:35 -05:00
Using Vikunja as a caldav client #43
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vikunja#43
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SamirSaidani on GitHub (Apr 8, 2022).
As far as I understand, Vikunja intends to be used as a caldav server and not as a caldav client.
I'd like to point out that there is already rock solid floss caldav servers (sabredav, radicale, etc.).
I think that a better strategy would be to repurpose Vikunja as a caldav client-only. In my opinion, it's a waste of energy to develop a new caldav server: simply ship vikunja with sabredav/radicale server if you really want a caldav server, and just make them collaborate together.
Vikunja could be incredibly useful as a cross-platform front-end task management software able to connect and sync to a caldav server. You'll get integration with Nextcloud Tasks for free (based on sabredav). Caldav is the only floss widespread solution to get a way to synchronize tasks through different devices (mobile, web, desktop), and Vikunja could fill a gap right away.
I've desperately dig into the internet, and such a software simply does not exist in 2022 !
Look for instance here :
https://github.com/tasks/tasks/issues/1256
https://www.reddit.com/r/kde/comments/gs2acz/todo_manager_with_caldav_sync/
https://www.reddit.com/r/selfhosted/comments/grlrtr/has_anyone_gotten_personal_task_management_right/
Why writing an opensource caldav server (which is quite hard, and exists already), instead of just focusing on writing a cross-platform caldav client (which does not exist at this level of quality) ?
Moreover, a restful api frontend library for the caldav task protocol would be awesome, there is simply none in the web AFAIK.
Anyway, thank you very much for offering to the world this really neat software, it's the best cross-platform floss alternative task management client I know of.
@kolaente commented on GitHub (Apr 10, 2022):
I agree building a fully working caldav server is a lot of work and hard to get right - you can see this very well in the current caldav implementation which does not really work properly.
It's not really possible to integrate either sabredav or radicale "just like that" into Vikunja because both are written in other programming languages than Go. A possible way would be to build something with one of those tools which translates caldav calls into Vikunja API calls and just proxies requests between caldav clients and the Vikunja API.
I would love to have a caldav import at some point, similar to the other importers we have right now (Trello, Todoist, ...). That could extended into some kind of sync thing in a second step. I'm just not sure if it really is easier to implement a full-blown caldav client that it is to implement a caldav server.
I'm all open for suggestions on how to build this.
@SamirSaidani commented on GitHub (Apr 10, 2022):
I think that writing a caldav server is harder than writing a caldav client, for the same reason that building an api is harder than just using it.
About vikunja/sabredav, it's like php/mysql: they don't use the same language, but I can imagine building a dockerized container with both server. If vinkunja is a caldav client able to sync with any caldav server, then it's pretty easy to install a compatible caldav server alongside with vikunja. For instance, it's super easy with cloudron. Anyway, my proposal would be to not care about this aspect: the idea would be just to let the vikunja admin be able to setup the caldav server in vikunja settings, like it is the case for any caldav client.
On how to build a caldav client, there is a bunch of caldav libraries out there, in go, dart, or javascript, e.g:
https://github.com/emersion/go-webdav
https://github.com/julisanchez/caldav_client
https://github.com/nextcloud/cdav-library
I don't know which one would fit your needs, and there is probably others libraries, but I think that it would be definitely easier to start from an existing caldav library client in the language of your choice instead of rebuilding a caldav server from scratch.
Hope it helps !
@kolaente commented on GitHub (Apr 18, 2022):
Just to make sure I understand you correctly: Do you want to use the Vikunja Frontend with any caldav server or do you want to import/sync tasks from a caldav server into your Vikunja instance? The latter one is somewhat possible, the former is pretty much out of scope for the project.
@SamirSaidani commented on GitHub (Apr 20, 2022):
To be specific, I'd like to use the nextcloud sabredav-based caldav server with Vikunja. Either as a front-end or by syncing tasks. I think that it would be easier for vikunja to be just a front-end caldav client instead of a full-fletged caldav server supporting two-way sync. Check for instance 2do for Mac OS which is a great caldav client (unfortunately closed source).
@kolaente commented on GitHub (Apr 20, 2022):
Thanks for the clarification. It might be easier to implement a caldav client without an api layer in between, however we already have the api layer for Vikunja. Replacing that with a caldav-only client would be a lot of work and result in less features than what Vikunja currently has (Caldav does not have share links or kanban, for example).
Therefore, I don't see Vikunja becoming a fully-fledged caldav client any time soon. However, I see how having functionality within Vikunja to connect to other caldav servers would be useful. I think the best way to achieve this would be to first build a migrator from caldav to Vikunja (similar to the other ones like trello) and then in a second step build a sync mechanism so that Vikunja can update tasks in a remote caldav server. Both of these would still require a Vikunja api server running somewhere so I'm not entirely sure if that's what you want.
@SamirSaidani commented on GitHub (Apr 21, 2022):
Thanks for taking into account my request, I really appreciate :-)
I understand that the api layer seems to be a problem to make vikunja a caldav client. I'm curious to understand why it would be easier to code an api able to migrate or sync with a caldav server vs an api able to get and push information (crud-like) to a caldav server ? It seems to me that if you are able to sync, then you need first to code an api able to act as a caldav client, since syncing feature is a superset of caldav client features ?
I'm ok with an api server, I guess that it's a kind of an api-bridge between a caldav server and the vikunja core api ?
As far as I'm concerned, just a migrator would be useless for me since it would break my actual workflow: I won't be able to use a android caldav client anymore (tasks, 2do, etc).
Maybe we can get some inspiration with Etesync or DecSync approach - cf DecSync cross-platform library, Etesync caldav adapter or the decsync-radicale plugin, though I don't know how it would fit with the vikunja approach:
@kolaente commented on GitHub (Apr 21, 2022):
The main reason is we already have the api. The Vikunja frontend is designed to work with Vikunja's api. Changing that in the frontend would require a lot of work once and afterwards to maintain it. Hence, it would be easier to fetch the tasks from an external caldav server and put them into Vikunja in the format it (and the clients) can already understand. Pushing changes back to the caldav client would "translate" the tasks from Vikunja back to the caldav server.
For a migrator there's already parts in Vikunja to build it upon which would make that part easier than a rewrite of the frontend.
Have you tried using the caldav integration of Vikunja?
If you only want to run VIkunja on your computer, you theoretically can. You will still need to run the api somewhere, but you can do that on your computer as well, next to the desktop app.
@SamirSaidani commented on GitHub (Apr 22, 2022):
I didn't: I've understood that vikunja caldav integration is at a early stage and alpha, I don't want to take the risk to lose critical professional data. I prefer to rely on a battle-field tested caldav server for professional use.
@kolaente commented on GitHub (Apr 25, 2022):
As always - no backup, no pity. I understand you don't want to put critical data in there but please check if maybe the caldav integration already does what you want. You don't need to switch everything at once, maybe just try it with one little project?
@young-druid commented on GitHub (Jan 29, 2024):
Please, don't remove caldav server/api from Vikunja backend. I am using Vikunja as todo/planning tool. And it is super handy to have an option to sync tasks with DAVx5 and jtxBoard.
I think cladav server should be only removed once an Android client for Vikunja is released. Otherwise you don't have really any options to set up notifications/reminders for tasks in Vikunja on your android phone. Setting up mail server (in case of self-hosting) for reminders is quite hard.
@kolaente commented on GitHub (Jan 29, 2024):
It's not planned to remove the caldav server functionality from Vikunja.
@no-fox commented on GitHub (Aug 25, 2025):
I think Samir has raised some excellent points, and I’d really love to see this feature implemented. Honestly, I’ve never quite understood why Vikunja includes its own CalDAV server - this has been the main reason I haven’t been able to use it productively so far.
I did try switching over, using Vikunja as my CalDAV server, but unfortunately, I lost my tasks in the process. The server didn’t seem stable enough: some changes weren’t synced properly, and one of my lists disappeared; yet it still showed up with sync attempt errors, even though it no longer existed in the frontend. That’s definitely not something I’d feel comfortable relying on for critical data.
While looking for alternatives, I came across many comments from others facing the similar issue. It seems like this is a common blocker for people who would otherwise love to use Vikunja.
So rather than repeating Samir’s arguments, I just want to add my voice in support.
In my view, this would be a great direction for Vikunja to take, and I’d be thrilled to see this feature become a reality.
Kind regards
@Lyzod commented on GitHub (Oct 18, 2025):
I have to agree with everything said here which is especially important bc my workflow involves referencing vJournals, vNotes and eventually scheduling Tasks or attaching them to vEvents and exporting the whole thing into orgmode and markdown and back Instead of asking you to built a rock solid CalDAV server which supports vTask, vEvent, vNote and vJournal, it's much, much easier if Vikunja was able to use existing servers and different clients access different information and enable functions such as geobased reminderes, attaching other vThings, adding colors and switching types.
Idk, have you considered an opt-in mode for people who want to use it as a Client (what it does in the background doesn't matter, it should function as something to pull and push tasks. If it syncs to its own format or uses ics)? It doesn't have to be a monolith, so the API can peacefully coexist with that bc doing this via API calls definitely sounds like PITA, especially if all necessary libraries already exist.
I also wanna reiterate like the others how much I enjoy Vikunja. The interface and way to add tasks slowly makes me finally actually use it and get back into the habit of making tasks. Just the Fdroid Client sucks a bit, I prefer using it as a PWA which sadly doesn't work offline.