Generalities
Going with standard protocols is always a great idea because on the long term, the implementations of it grow, and they end up solving many use cases or problems.
In this case I will speak up CalDav and CardDav, which according to RFC that contains them it’s a technology proposed by Apple, specifically to handle calendar access, address books.
If you are interested in reading about the standard or developing for the standard, you can take a look at the following RFC’so
- vCard MIME Directory Profile
- Internet Calendaring and Scheduling Core Object Specification (iCalendar)
- CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)
- Scheduling Extensions to CalDAV
I am not entirely sure the fact that it’s a standard written by Apple has anything to do with the poor support in Android devices, but that is where DAVx⁵ comes in. In Apple devices, you can directly go and register a new internet account it will successfully integrate all these protocols to their corresponding apps. In Android devices you need to use DAVx⁵ to support these types of accounts, but after you download it and use the regular calendar app that you have in the device, you should be fine.
About Radicale
Radicale It’s one of my favorite pieces of software that one can install on a personal or small organization’s server, it allows you to implement these protocols, and user your server to store all this information.
It’s a fairly simple project, and they even have a Simple 5-minute setup tutorial. Once you installed it and start using it you might notice there is an interesting feature missing, which, is the ability to have shared calendars.
Once you figure on a high level how the objects are getting store, you will notice that the default directory is /var/lib/radicale/collections/collection-root, and inside of it there are directories per user and each address book or calendar will be identified by a UUID which will be used to generate the URL.
So the “hack” to allow shared calendars is to just do a symbolic link to the specific asset in the original user directory, similar to the following command:
cd /var/lib/radicale/collections/collection-root
ln -s $(realpath user1/<UUID>) $(realpath user2/)Now a HUGE drop back here is that, there is no way of tracking ownership, since the radicale won’t be able to tell who created it, due to the fact that we are abusing the file system.
This issue can be mitigated if you are in regular communication with the other users you share a calendar.
Now another hack we could do a read only mount, which will enable you to visualize the assets from another user.
I haven’t had a need for this, and If I ever do it, I will make sure to update this post with the resolution of that attempt, but I’m suspecting it will raise errors when the read only user attempts to write.