← All privacy impact assessments

PIA: connected groups and targeted event invitations

Amended 30 October 2026: deleting a group. An owner can delete a group. Members are told at once, and the group is deleted seven days later unless the group's owner cancels; meanwhile anyone can export their own data or leave. Deleting removes everything the group holds for everyone in it, children included: messages, photos (sealed or not), lists, routines, baby records, the group's inbox and its attachments, and its keys. Our backups expire within 90 days and a deleted group is not restored from them. A star rating a member gave stays, with no group attached. Copies of the group's events in connected groups say the group no longer exists.

Status: Built. Written before implementation on 24 September 2026; revised before the second version was built on 25 September 2026 (§1A). Written: 24 September 2026 · Last revised: 30 October 2026 (deleting a group); 25 September 2026 Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 Dec 2026).

1. Purpose and scope

What it is for. Families, households and teams often have enduring relationships with another group — such as extended family (grandparents and cousins), regular carpool households, or collaborating community groups. Previously, sharing an event required generating an ephemeral six-character code for every individual event and manually sending it through an external chat or text message. Furthermore, an adult who is a member of multiple groups had to share a code to themselves and manually switch groups to enter it.

This feature adds two capabilities:

  1. Direct own-group attendance: An adult who belongs to multiple standing groups can directly add an event from one of their groups onto another of their groups' calendars, confirming adult and child headcounts in a single action without an out-of-band code.
  2. Connected groups: Two groups can establish an ongoing bilateral connection through an explicit mutual handshake approved by an adult administrator on both sides. Once connected, adult members of either group can send targeted event invitations directly to the other group without bearer codes.

In scope:

Out of scope:

1A. Revision, 25 September 2026: requests addressed by group name and admin email

The first version connected two groups with a single-use code that one admin generated and passed to the other outside the app. The second version replaces that with a request an adult admin addresses to a specific adult admin of the other group, by entering the other group's name and that admin's email address. The code path is kept only so that codes already issued can still be redeemed until they expire; the app no longer offers to create new ones.

What changes, and why each change is safe:

Change How it works Why
Email is an identity lookup, never a message The address is resolved, on our server, to exactly one account whose address is confirmed. Nothing is sent to that address: the recipient finds the request in the app, and the only notification is a generic phone push. No sign-up invitation is created. An email to a stranger's inbox is an outbound channel with none of the app's safeguards. The request stays inside the app, where age and role checks run on every read and write.
Both details must match The account must be an active adult admin of exactly one standing group whose name matches what was typed (ignoring case and extra spaces). Two groups with one name, a wrong name, an unconfirmed or unknown address, a member who is not an admin, or an under-18 account all produce the same neutral answer. Requiring both a name and an email means neither alone can be used to find a group, and one identical answer means a miss reveals nothing about which detail was wrong.
The address is never stored The request records who it was addressed to and a version number for that person's email binding. The typed address is compared and discarded. If that person later changes their email, the version changes and the request stops being answerable. There is nothing to leak later.
Only the addressed admin can answer Another admin of the same group can see that a request is waiting, but only the person it was addressed to can accept or decline it. Each answer carries the request's version number, so an out-of-date card or screen is refused rather than acting on a request that changed. The sender chose whom to ask. Letting any admin answer would widen that choice without the sender knowing.
Withdrawing is not declining The sending group can cancel a pending request. A cancel starts a one-hour pause before the same pair can send again; an expired request starts none; a decline or a disconnect starts the existing seven-day cooldown, including for someone who administers both groups. A cooldown exists to stop a declined request being repeated at someone. It should not punish a sender for withdrawing their own, but a short pause stops cancel-and-resend being used to notify the same person over and over.
Answers about an existing relationship come from the group name alone If the sender's group is already connected to, has a live request with, or is cooling down with a group of that name, the form says so without looking at the email address at all. Otherwise a sender could type different addresses against a group they already know and learn which ones belong to its admins.
The assistant can do the same things Members can ask the in-app assistant to send, cancel, accept, decline or disconnect a connection. The assistant calls the same server actions as the screens, with the same checks. An incoming request also appears as a card in the addressed admin's assistant. One set of rules, whichever door is used.

The push respects the recipient's choice. The notification to the addressed admin is skipped if they have turned off invitation notifications in their account settings; the request still waits in the app.

Rate limits. Every attempt is recorded before it is checked, matched or not: an admin can make at most 10 attempts an hour, and a group at most 30 a day. Attempt records keep only who tried, from which group, and when, and are deleted after 31 days.

What a successful request reveals. A request that is created tells the sender that the details they typed belong to an adult admin of a group with that name. That is the purpose of the feature, and it is the same residual risk the direct group invitations assessment accepts. It is bounded by needing both details, by the rate limits, and by the recipient being free to decline or ignore the request, which expires after seven days.

Identifiers typed into the assistant. If a member asks the assistant to connect with a group and types an admin's email address into the chat, that message is processed by the assistant's model provider like any other message, under the group's privacy level: in Australia at the default level, overseas only if the group chose a global level, and not at all in a Device-only group (which has no server assistant). The assistant's replies and our server logs never repeat the address, and it is not stored on the request. The on-screen form is the way to connect without the address passing through the assistant.

2. Data involved

Kind Whose Children's? Sensitive? Free text?
group_connections: group IDs, status (connected/disconnected), generation counter, timestamps The two participating groups No No No
group_connection_invites: single-use Crockford-32 credential, stored hashed (sha256), origin group ID, expiry. No new ones are created since 25 September 2026 The issuing group No No No
Addressed request: which admin it is addressed to, their email binding version, a request version and a retry identifier, expiry. Not the email address The two groups and the addressed admin No No No
Request attempts: sender, sending group, time. Deleted after 31 days The sending admin No No No
Each member's attendance on an accepted event (Going, Not going, no answer) The receiving group's members Yes: children's attendance is recorded, set by a guardian or admin No No
event_group_invitations: host event ID, target group ID, sender ID, status, expiry, version Host and target groups No No No
Event details across the boundary: title, start time, timezone, duration, location The host group Sometimes (e.g. "Maya's 7th Birthday") No Yes (title and location)
Response details: responding adult display name, headcount counts (adults, children), optional response note The responding group and responding adult Headcounts describe children without naming them Possibly (dietary notes/allergies) Yes (the response note)
Disconnected mirror event: local copy on recipient group calendar with disconnected status marker Recipient group No No No

What is NOT collected or shared:

3. Flows and locations

Data Device Supabase (Sydney, ap-southeast-2) Push Service (APNs/FCM) Model Provider Region
Connection credentials (older path) Displayed once when they were created Hashed (sha256) at rest Never Never Australia
Addressed connection request The sender types the group name and email; the addressed admin sees the requesting group's name Stored without the address Generic line, titled with the recipient's own group name Only if typed into the assistant (§1A) Australia
Member attendance Shown in the Other Groups tool to the group's adult members Stored on the group's own copy of the event Never Never Australia
Group names (connections) Rendered in admin settings Stored in groups table Generic group name Never Australia
Event invitation offers Rendered in schedule inbox Stored in database Generic notice only Never Australia
Response notes & headcounts Entered by responding adult Stored in event RSVP table Never Never Australia
Calendar mirrors Rendered on group calendar Stored in schedule events Never Never Australia

Cross-group disclosures:

  1. Connection handshake:
    • For an addressed request, the addressed admin sees the requesting group's name and decides. Other admins of the addressed group see that a request is waiting.
    • For an older code, the recipient admin who redeems it sees only the origin group's name and initial badge. Upon redemption, the origin group's administrators see the recipient group's name and initial badge to decide whether to confirm or decline.
  2. Targeted event offers:
    • When an offer is sent, eligible adults in the target group see the host group's name, the event title, scheduled time, location, and host's first name.
    • When an adult accepts, the host group sees the responder's display name, attendance status, headcounts, and note.

Push notification privacy: Push notifications carry no event titles, no personal names, and no response notes. The push payload consists exclusively of opaque identifiers and the receiving group's name, directing the recipient to open the app where access control is enforced. A connection request push is titled with the addressed admin's own group, never the requesting group, and only the admin who sent the request can trigger it.

4. Legal basis and consents

  1. Connection establishment:
    • Establishing a connection requires affirmative authorization from an active adult administrator in both groups.
    • In single-user linking (where one person administers both groups), the admin confirms the link with explicit disclosure of what connecting does.
    • In cross-admin linking, the sending admin addresses a request by group name and admin email, and the addressed admin accepts it (§1A). Older codes: the origin admin generated a code, the recipient admin enters it, and an origin admin confirms the named group.
  2. Event participation consent:
    • The individual responding adult records an affirmative consent under the existing cross_group_events consent ledger purpose upon their first cross-group RSVP.
    • The consent notice explains that the host will see their display name, attendance count, and note, and that the event will appear on their group's shared calendar.

5. Risks and mitigations

Risk Who is harmed Mitigation Structural or conventional? Residual
Stranger guessing a connection code A household receiving unwanted connection requests 6-character Crockford-32 code drawn from cryptographic random bytes (approx. 1.07B combinations); stored hashed (sha256); rate-limited to 5 failed guesses per account per 15 minutes; single-use only. Structural (database rate limiter and unique constraint) Attackers with compromised database dumps could brute-force offline; mitigated by short 7-day expiration.
Inadvertent cross-group exposure of children Children in either group Under-18 accounts cannot create or redeem connection credentials, list connections, preview unaccepted cross-group offers, or respond to cross-group invitations. Structural (server-side age checks in database RPCs) None. Children interact with events solely on their own group's calendar after an adult accepts.
Group directory harvesting / account enumeration All users No public directory or search exists. An addressed request needs both the group's exact name and an admin's confirmed email; every miss returns one identical answer; attempts are rate-limited per admin and per group and recorded before they are checked. Structural (single lookup function, identical refusal, database rate limit) A created request confirms that the typed details belong to an adult admin of that group (§1A). An admin holding an older valid code can see the issuing group's name.
A stale screen or assistant card acting on a request that has changed Both groups Every answer carries the request's version; a changed request is refused. Only the addressed admin can answer. An email change makes the request unanswerable. Structural (version check and identity check in the database) None.
Another member's attendance changed by someone who should not Members of the receiving group Only the member, a group admin, or a child's own guardian can set attendance, through one server action. The database refuses any direct change to attendance on a copied event. Structural (server action and trigger) Admins can change any member's answer; this is deliberate so that someone can keep a child's plans accurate.
Unwanted event spam from a connected group Recipient group Either group's administrator can disconnect at any time. Disconnecting immediately revokes all pending offers and suppresses new requests for 7 days. Structural (server-side connection state check) Accepted events prior to disconnect remain as standalone local copies.
Stale information after disconnection Guests attending an event that changes Disconnected calendar copies are stamped with an explicit disconnected indicator, alerting members that details will no longer update from the host. Structural & Conventional (status column and UI warning badge) Hosts cannot update guests after disconnection; manual coordination required.

6. Best interests of the child (exposure draft ss 12–13)

The child's interaction graph never leaves their family. In compliance with our child protection architecture:

7. Retention, erasure and export

  1. Connection credentials: Single-use connection credentials expire after 7 days and are pruned after 30 days.
  2. Addressed requests: A pending request expires after 7 days. Once a request is answered, cancelled or expired, the record of whom it was addressed to is cleared by a nightly job. Request attempts are deleted after 31 days.
  3. Pending event offers: Unanswered event offers expire with the event and are pruned after 30 days.
  4. Disconnection and erasure:
    • If a group is deleted, its connections and connection credentials cascade and are deleted.
    • If an account is erased, their display name on responses cascades, while group-level calendar records remain with the group.
    • When two groups disconnect, the connection is marked disconnected with an incremented generation counter, preventing replay attacks while preserving historical non-repudiation.

8. Impact on Online Safety Act (Under-16 Rules) Status

This feature does not alter the service's classification under the Online Safety (Age-Restricted Social Media Platforms) Rules 2025:

9. Structural vs conventional summary

Property Enforcement Why it matters
Under-18 restriction on connections and RSVPs Database trigger and RPC check (not is_under_18(auth.uid())) Conventional client hiding is insufficient; database prevents unauthorized calls directly.
Single-use connection credentials Atomic database consumption on redemption (revoked_at = now()) Prevents token interception and multiple groups connecting to the same credential.
Bilateral admin authority Transactional check of is_group_admin for both origin and recipient Prevents non-admin members from binding their group to external groups.
Isolated group encryption Cryptographic separation (distinct group symmetric keys) Connected groups cannot read each other's encrypted messages, notes, or media.
Push notification payload privacy Server edge function builds fixed generic messages without titles Notification networks cannot log sensitive event or family information.
Neutral answer for an addressed request One lookup function returns the same response for every miss Nobody can use the form to learn which accounts or group names exist.
Only the addressed admin answers Identity and version checked in the database on every answer The sender's choice of whom to ask cannot be widened.
Attendance on copied events Server action plus a trigger refusing direct changes A member's attendance is changed only by them, their guardian or an admin.
The address is not stored The request keeps an identifier and binding version, never the typed address Nothing to leak later; an email change withdraws the request.

10. Residual risk

  1. Addressed requests confirm a match on success: Creating a request tells the sender that the details belong to an adult admin of a group with that name. Accepted; bounded as described in §1A.
  2. An address typed into the assistant is processed by the model provider: Accepted and disclosed (§1A). The on-screen form avoids it.
  3. Display name sharing: When an adult responds to an event, their display name is shared with the host group. This is necessary for event coordination (so the host knows who responded) and is disclosed to the responder prior to sending.
  4. Event details on recipient calendar: Once accepted, the event title, time, and location become visible to all active members of the recipient group, including children. Adults must exercise ordinary judgment when accepting invitations containing private notes.
  5. Disconnection sync cessation: When groups disconnect, updates to existing events cease. If a host relocates or reschedules an event, disconnected guests will not receive automatic updates. The prominent UI warning on disconnected events mitigates this risk by prompting manual verification.

11. Sources