#NotificationInboxRecipientProvider

#Import

1import { NotificationInboxRecipientProvider } from "alepha/api/notifications";

#Overview

The seam through which an app turns a contact into one of its users.

push({ contact }) hands one string to every channel. Email wants an address, and the inbox wants somebody to file a message under. This is how those two answers come from the same string without the notifications module learning what a user is.

The framework owns the gate, the app owns the identity: the same split NotificationPreferenceProvider already states, and the reason this exists rather than an import of alepha/api/users, which would couple two modules that share nothing today.

The default returns null, so an app that has not implemented it gets a skipped receipt with the reason unresolved-recipient rather than a crash - the same posture as an unimplemented preference provider allowing everything.

#The contact arrives normalized

Trimmed and lower-cased, the way NotificationSuppressionService already normalizes before it looks anything up. The sender hands the channel payload.contact raw, and an implementation looking users up by an address somebody typed with a capital letter would find nothing. Normalize on the way in as well: what is stored in users.email is not guaranteed to be normalized either.