Linkal
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.
🔧 How to build
❄ Nix users
❄ 👴🏼 Nix legacy users
🐳 Docker users
One can build a docker image for docker by running nix build .#docker-image.
Others
Having cargo installed, run cargo build.
Usage
⚙️ Configuration
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.
Running
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).
Add a linkal calendar in a CalDav client
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.
🚧 Roadmap
Linkal is in development phase and can be succeptible to bugs. Identified elements for upcoming developments are :
- Parallel requests to answer to
/calsrequests - 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