Cal/CardDav Alternatives

[stvhay]

@myfirstnameispaul wrote:

I attempted to survey options for replacing Nextcloud. A lot of searches discovered tools that have been created and then abandoned during the period this project has been laboring to maintain Owncloud/Nextcloud. This seems like it matters, since I'm guessing a final analysis will be to decide if you choose the devil you know or the one you don't.

I have not attempted to install any of these:

sabre/dav - "sabre/dav is the most popular WebDAV framework for PHP. Use it to create WebDAV, CalDAV and CardDAV servers." I think it is somewhat of a roll-your-own solution, but does support SQLite (and MySQL) for authentication and has been actively maintained for a lot of years. Note the site docs are somewhat dated, but the GitHub repos are very active.

• The project includes Baïkal - "Baïkal is a lightweight CalDAV+CardDAV server. It offers an extensive web interface with easy management of users, address books and calendars. It is fast and simple to install and only needs a basic php capable server. The data can be stored in a MySQL or a SQLite database." The saber-io organization hosts the GitHub repo, which is actively maintained. Based on the description, this one seems like the only clear drop-in replacement for Nextclould (without evaluating actual migration headaches).

DAViCal - "DAViCal is a server for calendar sharing. It is an implementation of the CalDAV protocol which is designed for storing calendaring resources (in iCalendar format) on a remote shared server." It is actively maintained, written in PHP, and requires PostgreSQL.

SOGo - "SOGo offers multiple ways to access calendaring and messaging data. Your users can either use a web browser, Microsoft Outlook, Mozilla Thunderbird, Apple iCal, or a mobile device to access the same information." Does not support SQLite, supports MySQL but recommends PostgreSQL. It is available as a package, but the package will not be updated so if it is decided a newer version should be run, I think it will have to be compiled.

Radicale - "Radicale is a small but powerful CalDAV (calendars, to-do lists) and CardDAV (contacts) server." Authentication options in the config file:

none | htpasswd | remote_user | http_x_remote_user

• I noticed that Modoboa seems to be rolling their own Python solution using Radicale, but I don't know much about Modoboa (or Python, TBH):
  https://github.com/modoboa/modoboa-contacts
  https://github.com/modoboa/modoboa-radicale
  https://github.com/modoboa/modoboa-installer/blob/master/modoboa_installer/scripts/radicale.py

Bedework Calendar - "Bedework is an open-source enterprise calendar system that supports public, personal, and group calendaring." Java. Claims to support MySQL, but only has configuration instructions for PostgreSQL (default installed with H2), but it's built on Wildfly so possibly could use any JDBC. Can't find anything indicating how much memory it uses.

Xandikos - "Xandikos is a lightweight yet complete CardDAV/CalDAV server that backs onto a Git repository." Python and has no authentication option (other than reverse proxy).

Originally posted by @myfirstnameispaul in #2083 (comment)

[stvhay]

I thought this might be a good place to discuss DAV implementations for the future, if we are considering replacing NC at some point. In addition to @myfirstnameispaul 's great work summarizing options above, I found an interesting project that I think we should take a look at.

• Davis - Davis seems to be a pretty active project, also based on Sabre/DAV, but has a slightly different focus than Baïkal. Particularly, it IMAP authentication integration on the backend (which Baïkal project rejected a patch for), so it might fit well with how MiAB currently does things. Unfortunately, it does not support SQLite and would require us to move to mariadb as a backing datastore.

Here's a gist I wrote down some notes for getting started with Davis. I managed to get it up and running, autodetect with Thunderbird, and send a calendar invite.

https://gist.github.com/stvhay/310862d92f481da18eeda96066ffd507

In terms of database backup and restore, it may be as simple (?) as:

mysqldump db_name > backup-file.sql
mysql db_name < backup-file.sql

[stvhay]

I also did the same thing with Baïkal. Good results, but the key there will probably be to figure out how to interact with the web administration tool because it doesn't have a good way to sync the IMAP backend, and not a REST API for the admin which I can see.

[myfirstnameispaul]

Unfortunately, I didn't keep my notes and I don't recall why I didn't add Davis to my list. Typical reasons I will rule out projects:

• Appears not very popular - Even well-maintained projects need to have a large user-base or MiaB will end up being the beta/RC testing pool, which is probably not a good fit for the majority of MiaB installs. I usually will search beyond just the GitHub repo because many projects do not use GitHub. Even mature well-maintained projects may have a nearly dormant-appearing GitHub repo, but remain active on GitLab, SourceForge, or self-hosted
• Exceptionally long inactive periods - Usually this indicates only fixing show-stopper bugs for the maintainer's own installs.
• Young - MiaB should be using reasonably mature projects, so same reasons as first bullet above for not listing.
• Requires some sort of container. This one is just my opinion, but containers are for SaaS, not standalone installs.

I've still got too much going on to spend real time here, but this NC madness needs to end and will be I think a great contribution to figure out a better solution.

Also, whenever it is migrated we should create very clear documentation because there are many people using NC file sharing between users, so removing that feature from MiaB should include a clear migration path to a standalone NC server, or something, so we aren't just saying "no longer supported, have a nice day" because I really hate when projects do that to me.

Additionally, I really feel that MiaB should include something like a 500-character HTML (support hyperlinks, colors, bold, etc.) max message length in the dashboard new version notifications to provide only critical information related to the next version upgrade. Because MiaB version upgrades are usually so trouble-free, there will be many users who do not review anything only to discover they've removed NC and no longer have access to their file-sharing tool, likely turning an estimated 15-minute downtime to half a day or more.

[stvhay]

Unfortunately, I didn't keep my notes and I don't recall why I didn't add Davis to my list. Typical reasons I will rule out projects:

* Appears not very popular - Even well-maintained projects need to have a large user-base or MiaB will end up being the beta/RC testing pool, which is probably not a good fit for the majority of MiaB installs. I usually will search beyond just the GitHub repo because many projects do not use GitHub. Even mature well-maintained projects may have a nearly dormant-appearing GitHub repo, but remain active on GitLab, SourceForge, or self-hosted

Davis does not look like it is used by a ton of people. But the good news is that it is relatively simple, like Baikal, and there is an active developer maintaining it, like Baikal.

* Exceptionally long inactive periods - Usually this indicates only fixing show-stopper bugs for the maintainer's own installs.

Yeah, it doesn't look that bad, but it is one person maintaining it. Unfortunately the landscape here is pretty bleak in general.

* Young - MiaB should be using reasonably mature projects, so same reasons as first bullet above for not listing.

Davis has been around since 2019.. So its not new, but not old either.

* Requires some sort of container. This one is just my opinion, but containers are for SaaS, not standalone installs.

No container required.

I've still got too much going on to spend real time here, but this NC madness needs to end and will be I think a great contribution to figure out a better solution.

Also, whenever it is migrated we should create very clear documentation because there are many people using NC file sharing between users, so removing that feature from MiaB should include a clear migration path to a standalone NC server, or something, so we aren't just saying "no longer supported, have a nice day" because I really hate when projects do that to me.

I can say this -- Davis has the basics. you can do CalDAV, CardDAV, and WebDAV with it. It doesn't have the greatest documentation, but its all there. Migrations scripts will be tricky. Files are easy, but I think the contacts and calendar will be much more difficult. That is probably true of any non-nextcloud solution though.

Additionally, I really feel that MiaB should include something like a 500-character HTML (support hyperlinks, colors, bold, etc.) max message length in the dashboard new version notifications to provide only critical information related to the next version upgrade. Because MiaB version upgrades are usually so trouble-free, there will be many users who do not review anything only to discover they've removed NC and no longer have access to their file-sharing tool, likely turning an estimated 15-minute downtime to half a day or more.

If we end up torching NC, I agree we need to give the users a big heads up. I mean, I can go either way with it. NC is fine. Yeah its kinds slow and a pain in the arse to keep up to date. But it can be made to work and is working.

Here are what I see as the main benefits of Davis:

• It supports CalDAV, CardDAV, and WebDAV out of the box.
• It is actively maintained.
• It is a relatively lightweight front-end to SabreDAV, which is very mature.
• It seems to have native IMAP authentication with automatic user creation. This makes it very easy to integrate with MIAB.
• Simple PHP--self-contained app using PHP composer. Should be easy to keep up to date without mucking around with the base OS install.

Here are some weak points:

• It does require MariaDB. This means figuring out a strategy for user data.
• It doesn't seem to have a wide user base.
• Documentation is light. (but the app is pretty simple also)
• Requires, or is best installed, on its own subdomain. Shouldn't be a problem. but its a limitation I wanted to point out.

Of all the options you listed, and I think its a very thorough list, here's what I think about them:

• SabreDAV: Very solid, but really this project is for developers to make their own client. They have a pretty extensive "sample" for Card and Cal DAV (called groupeware.php or something), but it ends there, and while there is an IMAP plugin, PHP code would have to be written to make it all actually work.
• Baikal: This would be a winner for me if it had an admin REST API. Stable and been around a while. Right now, the developer seems pretty adamant at keeping the project very simple and using the web page to manage users. Maybe someone else can speak to the feasibility of 'scraping' the actions out of the website, maintaining authentication, and doing some kind of thing headless without a clean API.
• DaviCAL: It does not include CardDAV or WebDAV, and requires Postgres. So we'd need to figure out a CardDAV and decide if MIAB is going to support generalized WebDAV for file storage or not.
• SoGo: I think this would be almost a complete rethink of MiAB. SoGo is almost an alternative to MiAB itself. That said, it looks highly capable and claims Exchange Active Sync support. I'd worry we'd run into similar problems as we do with Nextcloud.
• Radicale: Worth a deep dive to see what we can do with it. There appear to be plugins for IMAP integration but they look a little gimpy in terms of development activity. No WebDAV, so we might need to rethink support for file storage.

[stvhay]

Migration Challenges:

• Finding a solution that meets all of our objectives: well-supported, active development; solid userbase; required functionality; fully featured replacement; requires no significant additional coding to meet our requirements.
• If we want to do this completely automagically, it will involve figuring out how to pull the calendar and contacts OUT of Nextcloud and then into the new implementation automatically. Right now, I have no idea how to do this. In addition to this, I've run into some pretty serious bugs in the Nextcloud contacts export function. Using Thunderbird, I've also failed a workflow of exporting and importing my calendar from and to Nextcloud (due to a missing STATUS field in on of my events. Thunderbird just exits out with the error when this happens so not graceful at all. I was successful using BusyCal and BusyContacts, a Mac calendar app you have to pay for to use. All this is to say, I think that this problem is going to be very sticky to generalize.
• Loss in undocumented functionality. It isn't clear to me how people are using their calendars and to what extent they rely on functionality of Nextcloud that might not be in another implementation. Stuff like calendar sharing perhaps.
• Synchronizing the Contacts, Calendar, and email accounts.
• Whether to adopt the use of a database, which expands the possible choices on the table. For what its worth I think we have two options here. (1) move the data directory to $STORAGE_ROOT (2) Add SQL backup commands to the backup cron.
• As @myfirstnameispaul notes: Additionally, I really feel that MiaB should include something like a 500-character HTML (support hyperlinks, colors, bold, etc.) max message length in the dashboard new version notifications to provide only critical information related to the next version upgrade. Because MiaB version upgrades are usually so trouble-free, there will be many users who do not review anything only to discover they've removed NC and no longer have access to their file-sharing tool, likely turning an estimated 15-minute downtime to half a day or more.

[mschering]

Disclaimer: I am the author of this software and I don't want to spam. But it looks like our software Group-Office https://www.group-office.com meets all your requirements!

[downtownallday]

Some thoughts and ideas from the maintainer of the carddav plugin for Roundcube:

mstilkerich/rcmcarddav#454 (comment)

[cmonty14]

Could you please share an update on this topic?
In my greenfield installation directory /usr/local/lib/owncloud allocates ~630MB w/o using Cal/CardDav.
Imo Nextcloud is not a thin solution for Cal/CardDav only.

Would it be possible to give end-users who want to deploy MiaB from scratch the option to select which Cal/CardDav service to use: Nextcloud or thin service?
This would allow MiaB development to delegate responsibility for Cal/CardDav migration from Nextcloud to another service to end-user.

[arodier]

I am very happy with SOGo.
For a demo of the integration using Ansible: https://github.com/progmaticltd/homebox