Calendars and scheduling

Nixt Server keeps people’s calendars and address books beside their mail, and serves them over CalDAV and CardDAV. Connecting mail apps covers adding an account to a calendar or contacts app. This page covers what happens after that: meeting invitations, busy time, sharing, and what an administrator decides.

The examples use the vsx shell function from the Quick start.

Meeting invitations

A person invites people by adding them to an event in their own calendar app. The server works out who needs to hear about it and carries each message.

Inside the organisation

An invitation to a colleague is in their calendar, waiting for their answer, as soon as the organiser saves the event. Their answer is in the organiser’s copy as soon as they give it.

• Moving the event asks everybody again.
• Cancelling it takes it out of everybody’s calendar.
• Inviting a group invites each of its people.

Outside the organisation

Anybody else is sent the invitation by mail, from the organiser: a readable summary of the event, with the invitation attached in the form every calendar app understands. It goes out as the organiser’s own mail does, so it is filtered, counts toward their sending limits and is signed for their domain. Answers come back the same way.

Somebody in another organisation on the same server is outside the organisation too, and is reached by mail.

Invitations that arrive by mail

When mail with an invitation or an answer in it arrives, the server offers it to the recipient’s calendar as it files the message. It changes a calendar only when the mail really is from the person it speaks for:

• An invitation, a change or a cancellation counts only when it comes from the event’s organiser.
• An answer counts only when it comes from the person answering.
• Either way, DMARC must have passed for the sender’s domain. Mail sent by somebody of the organisation through this server counts too.

An answer taken into an event is filed as read, since the event already says what it says. The mail itself is always delivered.

Whether a proved invitation from outside is added to the person’s calendar by itself is the organisation’s choice:

An event the person already has follows its organiser’s changes either way. An invitation nothing proves is never added: invitations are a known way to put a stranger’s link in somebody’s calendar.

On the console this is Add invitations from outside to people’s calendars, on the Calendars card under Settings. From the command line:

vsx admin org calendar-invitations authenticated
vsx admin org calendar-invitations never

Busy time

A calendar app finds a time to meet by asking when people are busy. The server answers with blocks of time only, never what they are for:

• Only the calendars a person counts toward their busy time are asked.
• Declined invitations are left out, and invitations not answered yet are shown as tentative.
• The availability a person set in their app, such as their working hours, is taken into account where their app supports it.

Who may ask is the organisation’s choice:

Nobody outside the organisation is shown anybody’s busy time. On the console this is Who may see when people are busy, on the same card. From the command line:

vsx admin org free-busy organisation
vsx admin org free-busy nobody

Sharing a calendar or an address book

A person shares one of their calendars or address books with a colleague, or with a group of the organisation, from their calendar or contacts app. What the other person may do:

• Apps that share by invitation, such as Apple’s Calendar, send the colleague a sharing invitation. It waits among their notifications until they accept it, and then the shared calendar appears beside their own.
• Other apps set who may see the calendar directly, and the share is there at once.

A share ends when the colleague declines or removes it, or when the owner stops sharing. Nothing is shared outside the organisation, and nobody can pass on what was shared with them.

When the organisation shows busy time to nobody, the people a calendar is shared with still see it.

A delegate who manages a calendar

A delegate given Manage calendar sees and changes every one of the owner’s calendars, from their own calendar app, beside their own. They answer invitations as the owner, and the answer says who gave it.

On the console, the person’s page has Manage calendar among what a delegate may do. From the command line:

vsx admin people delegate ada@example.com bob@example.com --calendar
vsx admin people delegate ada@example.com bob@example.com --read --calendar

people delegate gives that delegate exactly the options named, so name every right they should keep.

An address book for a group

An administrator can make an address book that everybody in a group has among their own, for suppliers, customers or a team’s contacts. It is kept in the group’s own home, so it stays when people join or leave. Members may read it, or read and change it.

On the console it is Address book for the group, on the group’s page. From the command line:

vsx admin group address-book sales@example.com --name 'Suppliers' --access read
vsx admin group address-books
vsx admin group remove-address-book sales@example.com

Removing a group’s address book removes every card in it.

Rooms and equipment

A room or a piece of equipment given booking rules answers each invitation as it arrives: it accepts when the time fits its rules and is free, and declines with the reason otherwise, such as “already booked 2026-09-28 10:00–11:00 UTC” or “longer than 4 hours”. Two requests for the same hour at once book it once.

vsx admin room add board@example.com --name 'Board room' --capacity 12 --location 'Floor 3' --max 4h --ahead 90d --hours 'mon-fri 08:00-18:00 +01:00'
vsx admin room booking board@example.com --booking approval --approver facilities@example.com
vsx admin room show
vsx admin room stop board@example.com

room booking changes only the options it is given. Approvers see the room’s calendar as a calendar delegate does. Calendar apps find rooms by searching for people and places, and can ask for their busy time. Nobody signs in as a room.

On the console, a room’s page has a card for its booking rules.

The organisation’s address book

Everybody has two address books they did not make:

• Organisation: the organisation’s people, groups and rooms, with their names, addresses, and, where the directory has them, titles, departments and phone numbers. It is read-only, and drawn fresh each time an app reads it, so somebody added, renamed or removed is there at the app’s next sync.
• Recent: the addresses the person has written to in the last year, which apps fill addresses in from. A card deleted from it is gone; deleting the whole book turns it off.

What the organisation’s book shows is the organisation’s choice:

vsx admin addressbook show
vsx admin addressbook fields title,department
vsx admin addressbook hide ceo@example.com
vsx admin addressbook scope set scopes.json

fields chooses which of title, department and phones are shown. Somebody hidden is never listed, though mail still reaches them. Scope rules say who sees whom, the first rule that matches winning; with none, everybody sees everybody. On the console these are on a card under Settings. Titles, departments and phone numbers come from the directory, including from SCIM.

Publishing a calendar

A person can publish one of their calendars as a secret link that anybody holding it can subscribe to in their own calendar app. The link shows the events, never who else is invited; a private event appears only as busy time. The link is shown once, when it is made. Making it again replaces it, and taking it back closes it.

What may leave the organisation is the organisation’s choice, with the runtime setting calendar.publishing:

It applies to every link at once. On the console it is on the Calendars card under Settings. From the command line:

vsx admin org calendar-publishing freebusy
vsx admin calendar published ada@example.com
vsx admin calendar unpublish ada@example.com work

An administrator sees the links a person has and can close one, for a link that leaked or somebody who has left.

Subscribing to a calendar

A person can subscribe to a calendar published elsewhere, such as public holidays, a sports fixture list or a team rota, at its https or webcal address. It appears in their calendar home as a read-only calendar, kept in step every four hours. Its alarms and attendees are left out, and it does not count toward the person’s busy time.

The server fetches it only from public addresses, on the standard port, following redirects only within the same host, at most 5 MB in 20 seconds. A calendar that cannot be read is refused with the reason, and nothing is kept. A person may have up to 50 subscriptions.

A server that must reach calendars on a private network, such as a company intranet, says so in its configuration file, and can trust a private certificate authority for them:

[calendar_subscriptions]
allow_private = true
trust = "/etc/versealx-server/intranet-ca.pem"

Turn allow_private on only where everybody who can subscribe is trusted as much as the server’s operator: with it on, a subscription can point the server at anything on its own network, such as a cloud metadata service or the admin API. trust adds a certificate authority and never turns checking off.

Contacts over JMAP

JMAP apps, the Nixt Office apps among them, read and write the same address books that phones sync over CardDAV: a card changed by either is the other’s at its next sync. The organisation’s book and Recent are there too, read-only.

Calendars over JMAP

JMAP apps, the Nixt Office apps among them, read and write the same calendars that phones and desktop apps sync over CalDAV. An event changed by either is the other’s at its next sync, and JMAP apps are told of the change at once.

An event written over JMAP is scheduled exactly as one written over CalDAV: colleagues are invited directly, rooms answer, and people outside the organisation get their invitation by mail. Calendars somebody has shared with a person, and those they manage as a delegate, appear under their owner’s name, with the rights the share gives. Busy time over JMAP follows the same busy time setting as CalDAV.

Nixt Server follows the JMAP for Calendars specification from the IETF’s JMAP working group, with JMAP Sharing (RFC 9670) for principals and availability.

A JMAP app names an event’s time zone, such as Europe/Berlin, without describing it. The server adds the zone’s full definition to the event from its built-in copy of the IANA time zone database (release 2026e), so every calendar app, over CalDAV or JMAP, shows the event at the same moment, before and after the clocks change. A time that happens twice when the clocks go back is its first occurrence, and one skipped when they go forward is read as if the clocks had not yet changed: 02:30 on the day clocks jump from 02:00 to 03:00 is 03:30.

Over the API