Notifications, restrained

The premise

The notification channel is the loudest surface a mobile app owns. Getting it right is the single biggest lever a social network has over the health of its relationship with the person on the other end of the phone. Getting it wrong is also the single biggest reason people uninstall.

Seldeo's notification policy is the direct expression of this: only notify for things a real person on the account would want a real interruption for.

What we notify you about

• A direct message from a friend. With the sender name and the first few words (subject to your message-preview setting).
• A call from a friend. Ringing through, with CallKit or ConnectionService integration.
• A comment on your post, or a reply to your comment. Once per post per notification window; a burst of comments batches into a single notification.
• A friend request. Delivered as a single notification; no bumping if declined.
• A step-up prompt for your own account. When one of your paired devices requests a step-up for a high-risk action.
• A security event on your own account. New sign-in from an unrecognised device, new passkey added, recovery request opened.
• The safety-team acting on a report you filed. So the reporter knows their report was reviewed.

That is essentially the whole list.

What we don't notify you about

• Someone posted for the first time in a week. No.
• A friend's story is about to expire. No.
• A friend just became active. No.
• You haven't opened Seldeo today. No.
• You have a "streak" going. No — we don't have streaks, and we're not going to.
• A stranger reacted to a post you have public. No; this batches into an in-app badge, not a push.
• A sponsored post you might like just landed in your feed. No, and this is a bright line.

The pattern: the notifications that fire are triggered by a deliberate action from a real person you know, or by a safety/security event on your own account. Nothing else reaches the OS notification channel.

Batching

Bursts of legitimate notifications (five comments on the same post in an hour, a run of messages in a conversation) batch into a single notification with a count. The notification opens the app to the same place regardless of whether the count is 1 or 15.

Batching cannot be gamed. The batching happens on the server before any per-user timing decisions, so an account that tries to send fifty messages in a minute to force fifty notifications ends up producing one.

The "wake up your phone" bar

Not every notification is created equal on iOS or Android. There are notification channels with sound + vibration ("critical"), silent notifications (delivered to the tray without waking the screen), and passive notifications (collected until the user opens the app).

The mapping we use:

• Calls — critical, always.
• Direct messages from friends — critical by default, silent for friends whose conversations you have muted.
• Comments and reactions on your posts — silent.
• Friend requests — silent.
• Security and step-up events — critical.
• All other in-app-only events — passive.

You can override any of these under Settings → Notifications, at the per-channel granularity iOS and Android's own settings surface.

Quiet hours

Seldeo's notification service honours OS Do Not Disturb schedules, and also has its own "quiet hours" setting where you can define a nightly window during which even critical notifications from Seldeo are held back until morning. The one exception is calls: quiet hours never suppress incoming calls, because the calling API integrates with the OS calling stack, which has its own DND behaviour.

Notification permissions

Seldeo does not ask for notification permission on first launch. We ask when the first notifiable event happens on the account — for example, when you receive your first direct message — and we ask with clear context: "Seldeo would like to send you a notification because just messaged you." Users who understand what a permission is for grant it at a much higher rate than users who are prompted at cold start with no context.

Users who decline can grant permission later from Settings → Notifications, or from the OS settings screen.

Notification suppression on our side

We suppress our own notifications when:

• The user is currently in the app at the surface the notification would open to. Fewer double-ringing effects.
• The user is on a call. Every non-call notification waits until the call is over.
• The device is registered as memorialised. No notifications to a memorialised account, ever.
• Under-18 accounts, during in-region school hours. A region-configurable schedule that dampens social-app interruption during school hours. Off by default, opt-in by the account holder or the parent.

What we don't do

• We don't send "growth" notifications. We do not send push notifications to inactive accounts to lure them back to the app.
• We don't send marketing. No product announcements via push. Product announcements live in News, and users open News when they want to.
• We don't send behavioural nudges. No "your friend just posted a photo — go react?" No FOMO engineering.
• We don't A/B test on notification volume. We do not run experiments where one arm of users receives 20% more notifications than the control arm to measure daily active user impact.

The line we don't cross

The notification channel belongs to the person, not to us. The rules above are the rules we operate under regardless of engagement metrics or growth targets. If Seldeo ever sends you a push notification that violates one of these rules, notifications@seldeo.com is the right address, and we will treat it as a bug.