Events: for administrators

What events add to a Catodon server, and what an administrator may want to know or change. For how events work for users, see Events; for what other servers do with them, Events: federation notes.

Who may post events

• Can create events, a role setting, on by default. Turn it off in a role (or the base role) to keep those accounts from posting events. It also hides the Event item in their post form.
• Only moderators can post events, in each local forum's settings, on by default. While it is on, only server moderators and administrators can post events in that forum, because an event in a forum presents the forum as its organizer (Mobilizon allows group events only from group moderators too). Turn it off to let everyone who may post in the forum post events there.

Answering events, and reading them, needs no setting.

Database

Eight migrations, all additive: nothing is dropped or renamed, in keeping with the promise that a Catodon database can go back to Sharkey (see Downgrading a Catodon instance to Sharkey).

The partial index on note is small, but building it reads the whole posts table once, and new posts wait until it is done. It took 1.7 seconds on a test database of three million posts. The others are on new or small tables.

Queues

A new queue, eventReminder, holds one delayed job per event that someone is going to, for the reminder a day before it starts. It is in Control Panel > Job Queue with the others. A job moves when the event's start moves and goes when the event is deleted.

Another, eventDmUpdate, sends the messages that tell people who said yes by message of a change to the event (see "When an event changes" below).

Maps and address search

The event editor's address search and map are fetched by the server, never by the user's browser. They use OpenStreetMap unless you name other services in Control Panel > Integrations > Maps:

• Address search goes to nominatim.openstreetmap.org, at most one request a second for the whole server (Nominatim's usage policy). The limit is held in Redis, so it covers every worker. A search that can't get a turn within five seconds gives up and the editor says the search is busy. With Address search URL set to another Nominatim-compatible search (your own Nominatim, say), that one is asked instead, without the one-a-second limit. Results are kept in Redis for a day.
• Map tiles come from tile.openstreetmap.org, or from Map tiles URL (a URL with {z}, {x} and {y}; PNG, JPEG and WebP tiles are taken), through /map-tiles/… on your server. Only signed-in users can load them (a token valid for an hour), so the route is not an open proxy. Map credit is the text shown on the map with your own tile server; with OpenStreetMap's tiles the map always shows OpenStreetMap's credit. Tiles are kept on disk in a map-tiles folder inside the uploaded-files folder (mediaDirectory), in a folder per tile server, and only the tiles somebody looked at are stored. A tile is refetched after 7 days, as OpenStreetMap's tile policy asks; a stale one is served if the tile server can't be reached. The daily clean-up job removes tiles nobody looked at for a month.

In production the server refuses to fetch from private addresses, so a tile server or Nominatim on your own network needs its network listed in allowedPrivateNetworks in the configuration file.

Reading an event never contacts a map service: the card's map links only open when a user follows them.

Feeds and endpoints

• /@user/events.ics: an iCalendar feed of an account's public events, the ones to come and those of the last 30 days. Offered for the same accounts as their Atom and RSS feeds.
• ActivityPub: each actor has an upcomingEvents collection (/users/:id/collections/upcoming-events, FEP-8a8e), with the first 50 events inline and the rest in pages (first, then next). Each local event has an attendees collection (/notes/:id/attendees): its totalItems is public, its items are served to the organizer only.
• API: events/upcoming, events/rsvp, events/unrsvp, events/attendees, events/invitees, maps/search, maps/tile-token, and an event parameter on notes/create, notes/edit and notes/schedule/create.

The events account

Each server has an account @events.bot, named Events, for people on servers without events (Mastodon above all) to answer this server's events by private message. It is a system account like the server's own actor: marked as a bot, not explorable, and nobody can sign in to it. Moderators cannot suspend, freeze or delete it. Its handle is the same on every server and cannot be changed; nobody can register it, because usernames chosen at signup cannot contain a dot.

Catodon tries to create it the first time something needs it: another server looking it up, or an event that takes answers being sent out, since the event's text names the account (see Events: federation notes, "The event"; if the creation fails there, the event goes out without that sentence and the failure is logged). A server where neither has happened has none. It only ever replies: see "What it does with a message" below.

Its name and description are written by Catodon, not by anyone, and each start brings them up to the current release's wording. When that changes them, the account sends an Update of itself to the servers whose people have written to it (one person on each), since other servers keep a profile as they first fetched it and the account has no followers to tell. The Update is only queued for delivery; if the start fails before it is queued, the next start sends it.

What it does with a message

A private message to the account alone that says "yes" or "no" and names one of this server's events, by its link (https://<your server>/notes/<id>) or its id, records that answer, as a Join from another server would be. The two may come in either order. "going", "attend", "decline", "can't" and a few words in other languages work too; a word that means something else in another language (such as "ja", "ne" or "si") is not taken. The message is kept, visible to the account alone, until its sender deletes it, which takes the answer back as if it had never been given (the organizer is not told). Deleting a message whose answer a later message replaced changes nothing. The account gets no notification for a message: nobody reads the account.

The account then replies, in the message's thread, to its sender alone. Every reply is in English, since the server does not know the sender's language:

• Recorded: that they are going, or not going, to the event, with how many people are going (and of how many places), the event's link, and how to change the answer: reply "no" (or "yes") to that reply. A message that changes an earlier answer starts with "Updated:".
• A yes refused: the event is full, or is over or cancelled. Nothing changes: an earlier answer stands, and someone already going keeps their place. A no is taken there, as the event's own buttons take one.
• Refused, nothing recorded: the event takes no answers here (attendance turned off, or taken on another site), or is by invitation only.
• No such event: the link or id names nothing this sender may answer. An event the sender may not see, and one whose organizer blocks the sender or is blocked by them, get this same reply, so that nothing is learned about it.
• "maybe": that events here take "yes" or "no", not "maybe".
• No answer: that it found no "yes" or "no" in the message.
• No event named: "Which event?" and how to name it. A reply to one of the account's own replies needs no link: it is about the event that reply named.

Someone on this server who writes to it gets one line pointing them at the event's Attend and Can't go buttons, once: not again for a reply in that thread. Nothing is recorded.

When an event changes

When the organizer changes an event's start, end, place or status (a cancellation included), the people going who said yes by message are told by message, the way people here get an "event updated" notification. Each gets one message, in reply to the account's latest reply to the message they answered with: Mastodon shows a message from an account its reader does not follow only in such a thread. It says what changed (a new time, a new place, cancelled, no longer cancelled), when and where the event is now, its link, and that replying "no" says they are not going and stops these messages.

• Only a yes given by message counts. Someone who answered another way since (a Join from their server, say), who said no, or who now cannot see the event or is blocked by or blocks its organizer gets nothing.
• The messages wait two minutes after an edit, and further edits in that time join them, so a time fixed and then a place makes one message, from what the people last heard to what the event says when it is sent. Edits that undo each other send nothing.
• They go out fifty at a time, thirty seconds apart, through the eventDmUpdate job queue (Control panel → Job queue).
• The day-before reminder is not sent by message.

The account replies to nothing from a bot, so two such accounts cannot keep each other talking, and to at most ten messages at once from one sender, then one a minute, and sixty at once from one server, then twelve a minute. Past that, a message is kept and goes unanswered. It writes first only to tell of a change to an event, and only into a thread someone started, and it sends no ActivityPub answer (Accept): the organizer is on this server.

Following Mobilizon people

Mobilizon only accepts follows of groups and of the server itself, and never answers a follow of a person. Catodon refuses such a follow before sending it. Follow requests to Mobilizon people made before this release stay pending; the user can cancel them from the person's profile.

Known limits

• Attendee counts of events on other servers change when that server sends an update, and when a signed-in user opens the event or the Events page: then the server is asked again, at most once every ten minutes per event and one request at a time per server, while the event is still to come. Mobilizon sends no update when someone joins, so between those asks the count can be behind. Mobilizon's count (participantCount) leaves out the organizer.
• Gancio sends no time zone, so its events are shown in each reader's own time.
• Recurring events are not supported (FEP-8a8e leaves recurrence out too).
• Mobilizon's anonymous participation, and joining a Mobilizon group as a member, are not supported.