A self-hostable web app that monitors iCalendar feeds and notifies you when your schedule changes — new events, time/location changes, cancellations. Built for students who want to know when a class moves, gets canceled, or changes room.
InTheKnow is a full-stack web application written in .NET and Svelte, designed to monitor iCalendar feeds and notify users about changes in their schedule. The .NET backend runs the checks and the HTTP API, and the SvelteKit frontend is the web interface people use.
This app was mainly built for me (Wjouter) out of frustration, because my university constantly changes my schedule without letting anyone know (even the teachers). This project is tailored for use with Semestry MyTimetables (the scheduling software my university uses). I cannot guarantee that it will work for other calendars / schedules, but effort is made to keep it useful for as many people as possible. Some features will be specifically made for Inholland.
| Feature | What it does | Spec |
|---|---|---|
| Change detection | Checks each calendar feed on a schedule and records every added, removed, moved or changed event. Several people with the same timetable share one check. | 001 |
| Change filters | Per calendar: rules that show only some changes, hide them, or mark them low priority. Sensible defaults hide noise such as changes to events that already ended. Rules can be saved as presets; admins make presets for everyone. | 002 |
| Notifications | One email digest per batch of changes, filtered as above, in English or Dutch and in your time zone. One-click unsubscribe. | 003 |
| Accounts | Sign-up with email confirmation, password reset, optional two-step verification with an authenticator app, and session management. Admins control who may sign up (open, allowed domains, invites) and manage accounts. Optional bot check (Cloudflare Turnstile or reCAPTCHA). | 004 |
| Web interface | Every feature above in the browser, in English and Dutch, on phones first: the changes feed as plain sentences, calendars, filters and presets, notifications, account and security settings, and the admin pages. The browser only talks to the frontend; the session token stays in an HttpOnly cookie. | 005 |
New here? QUICKSTART.md walks through a local development setup step by step.
Needs the .NET 10 SDK and Docker (or Podman) with Compose.
docker compose up -d db
export ConnectionStrings__Default="Host=localhost;Username=intheknow;Password=intheknow;Database=intheknow"Run the tests (they create and drop their own databases on the compose server):
export INTHEKNOW_TEST_DB="Host=localhost;Username=intheknow;Password=intheknow;Database=postgres"
dotnet testInvites, sign-up confirmations, password resets and notifications are sent by email, so configure an SMTP server before you start. For local development, start Mailpit and read the emails at http://localhost:8025:
docker compose up -d mailpit
export InTheKnow__Notifications__Email__Host=localhost
export InTheKnow__Notifications__Email__Port=1025
export InTheKnow__Notifications__Email__StartTls=false
export InTheKnow__Notifications__Email__FromAddress=intheknow@localhost
export InTheKnow__Notifications__PublicBaseUrl=http://localhost:5000
export InTheKnow__Notifications__FrontendBaseUrl=http://localhost:5173Start the API, the background checker and the notifier. The database is migrated at startup:
dotnet run --project backend/InTheKnowMake the first admin while the server runs. The command prints invite queued, and the server emails an invite;
the admin routes unlock once that account turns on two-step verification:
dotnet run --project backend/InTheKnow -- make-admin you@example.nlStart the web interface in a second terminal. It needs Node 24 or later, and talks to the API at
http://localhost:5000:
cd frontend
npm ci
npm run devOpen http://localhost:5173. The links in account emails (to FrontendBaseUrl) open its pages, so the admin invite
from make-admin ends on "Accept your invite".
For IDE runs, copy backend/InTheKnow/Properties/launchSettings.example.json to launchSettings.json (ignored by
git). It has the settings above. Its variables override the ones you exported.
Production runs as the container stack in DEPLOY.md. A non-container install follows the same proxy rules and the 005 configuration contract.
Every feature has a spec, a quickstart with a manual walkthrough, and contracts for its API and configuration:
- 001 iCal change detection — API, configuration
- 002 Change filters — API, rules
- 003 Notification channels — API, configuration
- 004 Accounts and login — API, configuration
- 005 Web interface — pages, API additions, configuration
- Deploying to production: the container stack, reverse proxy, upgrades and backups
Since 004, the API routes of 001 to 003 live under /api/me/… (your own data) and /api/admin/… (admins), and
every request sends Authorization: Bearer <session token> from sign-in.