Events
An event is a time, a roster and the records you ride. It is how EpicRide answers the question a route file cannot: who is coming, when, and what are they riding?
It is deliberately one idea at four sizes. A trip you are planning alone, a Sunday ride with friends, a tour operator taking clients out, and a rally with waves and time controls are the same object with different vocabulary and different capabilities — not four products.
Starting one
The desktop client opens on your Dashboard, which shows three things in the order they matter: invitations waiting for your answer, what is running right now, and what is coming up.
From there, New event asks for a title and a preset. Nothing else is required — no date, no roster, no route. A trip of one should not cost more than saving a route does; everything else is a later decision.
| Preset | What it is |
|---|---|
| Trip | A ride you are planning. A roster of one is fine |
| Group ride | Friends riding together, with a leader and regroups |
| Tour | An operator taking clients out, with guides and sweeps |
| Rally | Waves, classes, numbers, checkpoints and time controls |
There is a shorter path still. Anywhere the Library is on screen, a saved route offers Attach to event, and that dialog's first button is New trip from this: the route names the trip, the trip points at the route, and you land in its console. One click, from a line on the map to something people can be invited to.
The console
Every event has its own URL, and so does every part of it — /e/{id},
/e/{id}/roster, /e/{id}/schedule, /e/{id}/plan, /e/{id}/docs. Organising
is a sharing activity, so a link to the roster lands someone on the roster.
Overview is what the event is: title, description, when it starts and ends, who can see it, and a count of the roster, the attached records and the stops.
Roster is who is coming. Invite by username, or straight from your friends list. An invitation is an ask, not an enrolment — people appear as invited until they answer, and answering is theirs alone to do.
Schedule is where you stop and when. Each stop is a place already in your library given a role: briefing, start, fuel, food, regroup, finish — and, for a rally, checkpoints and time controls with opening and closing times.
Route and Documents are where library records become part of the event.
Live is the wall — see below.
The live wall
/e/{id}/live is where you watch the event happen. It answers one question
for every person on the roster: where are they now, and should I be worried?
The roster says who is expected. The live plane says who is visible. The wall shows the gap between them, because that gap is the information:
| State | What it means |
|---|---|
| Riding | A fix in the last minute and a half. This is where they are |
| No fix | We had a position and it stopped arriving. This is where they were |
| Not sharing | On the roster, sharing nothing we can see |
| Not coming | They declined or withdrew. Dark on purpose, and not a worry |
Rows are ordered by attention, not alphabetically: a rider whose fix stopped ten minutes ago sits above twelve riders moving normally. Anyone visible to you who is not on the roster still appears, marked as a guest — hiding a rider you can see would be the wall lying about its own map.
Selecting a rider centres the map on them and opens their details: speed, heading, last fix and position. Note what the wall will not do, which is guess: a rider with no position may not be sharing with you, or may be out of signal, and it says exactly that rather than picking one.
:::info One wall, every size The same screen serves five friends, twelve tour clients and three hundred competitors. Density and the role filter are the only things that change. There is no second, "serious" wall. :::
Positions arrive over the push socket when it is connected, and the wall says which it is using. If the socket is unavailable it asks every 15 seconds instead, and nothing else about the screen changes.
The same ladder, four vocabularies
There is one role ladder underneath — owner, organiser, staff, participant, spectator — and it never changes on the wire. What changes is what you read:
| Ladder | Trip | Group ride | Tour | Rally |
|---|---|---|---|---|
| owner | Organiser | Organiser | Operator | Promoter |
| organiser | Co-planner | Co-leader | Tour manager | Clerk of the course |
| staff | — | Sweep | Guide | Marshal |
| participant | Rider | Rider | Client | Competitor |
What each role may do is decided by the server, which sends the list with every event it hands you. The client renders that list and never works it out for itself, so revoking someone's role takes effect on their next request rather than whenever their browser next reloads.
Two rules follow from the ladder. Publishing and cancelling belong to the owner alone: an organiser who could cancel is an organiser who can call off someone else's event. And an organiser may only assign roles below their own, so they can never mint another owner.
Attaching is not copying
:::info A reference, never a copy An event stores which library record it uses and how — route, roadbook, waypoints, briefing, GPX pack, media, result track. It does not take a copy. :::
This is the same rule sharing follows. The record stays yours, in one place, with one owner, so fixing the route the night before the ride fixes it for everyone who has the link — nobody is riding last week's file.
A rally is the exception, and the server handles it: when a rally is published, the documents it hands out are frozen at that version. An organiser has to be able to prove what a competitor was given. A weekend trip is better served by a correction reaching everyone at once, so trips, group rides and tours stay live references.
Where an event can be in its life
The console only offers moves that exist. Calling an event off is cancelled, which leaves the roster something to read; deleting is for a draft made by mistake, and is the owner's alone.
The alert lane
Above the map, the wall keeps a short list of what needs an organiser's attention, worst first. An organiser who has to scan a rider list to notice a crash is being asked to do the computer's job.
| Alert | Raised when |
|---|---|
| SOS or crash | A rider raised an alarm or their phone detected a crash, and they share alerts with this event |
| Off the route | They are more than 500 m from the route the event is riding |
| Behind the field | They are more than 20 km behind the middle of the field, so one fast rider does not make everyone else late |
| Not moving | Stationary for ten minutes — long enough that a fuel stop, a photo and a sandwich have all been ruled out |
| No position | Their fix stopped arriving |
Two honest limits, stated rather than hidden.
Off the route and behind the field are worked out here, from the event's own route and the positions on the map. They are not a sensor on the bike. If the event has no route attached, neither can fire.
"No position" is only ever information, never a warning. A tunnel, a flat battery and a crash look identical from a desk, and dressing that up as an alarm would teach an organiser to ignore the lane — which is the one outcome worth avoiding.
A rider gets at most one alert. Someone who crashed is also off-route and also stopped, and three rows for one person buries everybody else.
If something goes wrong
An organiser running an event has a duty of care, and the app already detects crashes and raises SOS alerts. Joining a roster does not connect those two things.
:::caution Your crashes are yours to share When you accept an invitation you are asked, in the invitation itself, whether this event's organiser should be alerted if you crash or raise an SOS. It is off unless you say otherwise. Being on a roster never exposes it. :::
If you say yes, staff for that event see your incident and where it happened, in the same place they watch the ride. If you decline, or later withdraw from the event, they see nothing — and they are not told that you declined, because a list of people who chose not to share their crashes is itself the thing those people declined to share.
An organiser can override this. Running an event carries a duty of care, and on some events an organiser needs to know a rider is down whatever that rider ticked. So an owner or organiser — not staff — can turn crash alerts on for a rider who did not agree.
:::caution You are always told An override is never silent. The event tells you, in plain words, that the organiser has turned crash alerts on for you. Who did it and when are recorded. Your own answer is left untouched underneath, so if the override is released you go back to what you chose, not to what was forced. :::
Who can see it
| Visibility | Who |
|---|---|
| Private | Only the roster knows it exists |
| By invitation | Anyone with the link can ask to join |
| Listed | Findable, and spectators may follow it |
Anything you may not see answers 404, not 403 — whether an event exists is itself part of what was shared.