Direct, threaded messages between a guardian and their child's teacher — the private "quick question" channel that announcements and homework posts aren't built for.
Planned Not yet started — this page describes the intended design and build plan.
Overview
Everything Notipa does today is broadcast: a teacher posts, and guardians receive. There's no way for a
guardian to send something back privately — "can she stay in for lunch club today," "he's out sick,"
"can we talk about his reading level." Guardian ↔ teacher messaging adds a one-to-one threaded
conversation, scoped to a specific guardian and a specific teacher, tied to the student that connects
them.
This is the messaging feature the per-school on/off switch is built
for — schools that aren't ready to support real-time parent messaging (staffing, moderation, expectations
around response time) need to be able to turn it off entirely rather than have it forced on them.
How it will work
Thread scope. A thread exists between one guardian and one teacher, in the context of one shared student. If a guardian has children with two different teachers, those are two separate threads.
Starting a thread. Either side can start a conversation — a teacher from a student's profile, a guardian from that student's card in their own dashboard.
Plain text, with attachments later. The first version is plain text messages with timestamps and read receipts, consistent with the read-tracking Notipa already does on announcements. File attachments are a deliberate later step, not part of the initial build.
Off by default per school. Ships alongside the messaging toggle so a school explicitly opts in before either side can use it.
Development plan
1Data model & backend
New MessageThread model: FK to guardian, FK to teacher, FK to the shared student, school FK for scoping.
New Message model: FK to thread, sender, body text, sent-at, read-at.
Permission layer ensuring a thread can only be created between a guardian and a teacher who are actually connected through a shared student — no open messaging to arbitrary staff.
2Messaging toggle dependency
Build (or confirm) the per-school messaging switch first, since this feature and class group messaging both sit behind it.
All thread-creation entry points check the school's messaging setting before rendering.
3UI — inbox & thread view
A messages inbox for both teacher and guardian roles, listing threads by most recent activity, with an unread indicator.
Thread view with a simple composer, consistent with the app's existing visual language rather than a chat-app skin.
Entry points: "message the teacher" on a student's card for guardians, "message guardian" on a student's profile for teachers.
4Notifications & testing
New-message notification through the existing notification path (and, once built, the SMS fallback).
Permission tests: a guardian cannot message a teacher unconnected to their child; a teacher cannot see threads belonging to another teacher's students.
Load/UX testing with multi-guardian households and multi-child guardians to make sure threads stay clearly separated.
Technical considerations
No group DMs or open staff directory browsing — a thread only exists where a real guardian-student-teacher relationship already exists in the data.
Message content isn't moderated automatically; a school choosing to enable this feature is accepting the same responsibility it already has for any other parent-teacher channel.
Designed so the underlying thread/message model can later support class group messaging without a rewrite — group threads are a natural extension of the same schema.