Group Notifications

Group hosting protocol · Client–relay notifications · Group subscription methods

Notifications go only to valid device-session connections subscribed to the group. Sending follows Atomic commit and persistence rules. Arrival may be out of order; filtering, coalescing, and catch-up follow Notification handling rules.

For initial loading or reconnection, clients may follow Group synchronization and recovery. Post-subscription event catch-up follows group.subscribe.

group.timeline.changed

After new events, the relay sends this to subscribed connections with current read permission.

Notification Parameters

Processing Rules

When catch-up is needed, call group.sync from the locally completed position; obtain missing epoch material under group.key.sync.

group.application.changed

Send to subscribed current owners and administrators when pending applications change through creation, replacement, approval, rejection, deletion, or invitation invalidation.

Notification Parameters

Processing Rules

Refresh pending applications with group.application.list as needed.

group.member.recovery.changed

When pending resets change through creation, replacement, withdrawal, approval, rejection, deletion, or expiry, send to subscribed request-owner accounts and current owners/administrators authorized to process at least one request.

Departure, removal, banning, or an owner's member-key change during client-secret rotation MUST also trigger this notification if successful commit actually deletes a pending reset. Recipients of deletion hints MUST still have group access: the current owner receives them; administrators receive them if authorized to view at least one deleted request before deletion; request owners receive them if they still have group access.

Notification Parameters

Processing Rules

To refresh visible pending resets, call group.member.recovery.list and validate returned records under that method.