Linkal is a public-calendar aggregator server. Given a set a public calendars links, it can make a CalDav client believe all these calendars are part of the same calendar collection. It makes it easy to source public calendars from multiples users and locations and easily distribute them to your end user. It works by exposing the same endpoints as a real CalDav server, emulating responses when needed and otherwise forwarding the requests to the upstream servers.
nix build
nix-build
One can build a docker image for docker by running nix build .#docker-image
.
Having cargo installed, run cargo build
.
Linkal is configured using a json file describing your calendars. The file has to follow this structure :
{
"calendars": {
"https://calendar1.link/public-calendar/path": {
"name": "Calendar 1 name",
},
"https://calendar2.link/public-calendar/path": {
"name": "Calendar 2 name",
"color": "#c63b52",
}
}
}
The calendars have to be public. Linkal does not perform any authentification. The color
field is optional. If provided, the color of the calendar will be overriden by Linkal. This is useful if several of the calendars you're aggregating have the same color.
linkal --calendar-file <FILE>
This command will start the Linkal Server on port 8443
. It is recommanded that you host Linkal behind a reverse proxy with https enabled (like Nginx for example).
To add a linkal aggregated calendar to your client, use as url either the ip/url of your server with port 8443
or the url that is set in your reverse proxy. The id and password that your client is asking can be set with any value.
Supported clients are :
- ✅ Thunderbird
- ✅ Apple calendar
443
if you run Linkal behind a reverse proxy with https enabled.
If your calendar client is supported and not on this list, please open a pr/issue. If your favorite calendar client is not supported, open an issue.
Linkal is in development phase and can be succeptible to bugs. Identified elements for upcoming developments are :
- Parallel requests to answer to
/cals
requests - Improve the auto discovery of the service
- More abstract handling of propfind requests
- More reasonable format of the config file
- Allowing to override more calendar fields
- Ability to serve multiple calendar collections
- Better support of the RFC 4791 (Long term)
- Filtering protocol, if possible actionnable from the calendar client or a web interface (Long term)
- Supporting private calendars with auth en both sides