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 build
❄
👴🏼 Nix legacy users
nix-build
🐳
Docker users
Please be serious.
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 /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