Push notification options

[AndreaDiazCorreia]

Push Notifications for Privacy-Focused Flutter/Nostr Apps: Implementation Guide

The fundamental reality: No single push notification solution works across all three platform scenarios (iOS, Android with Google Services, Android without Google Services). You must implement a multi-backend architecture with intelligent fallback strategies.

Critical Platform Constraints and Best Solution

iOS requires APNs - Apple provides no alternatives for App Store applications. All iOS push notifications must route through Apple Push Notification service, which means Apple will see notification metadata (timing, device identifiers, IP addresses) even if you encrypt content.

Android with Google Play Services: FCM works universally but requires Google infrastructure. Google can see notification content unless you implement end-to-end encryption yourself (FCM provides no built-in E2E encryption).

Android without Google Services (GrapheneOS, LineageOS): FCM fundamentally doesn't work without Google Play Services. The best solution is UnifiedPush, an open-source decentralized protocol with mandatory encryption that's gained significant adoption in privacy-focused apps.

Recommended architecture for your use case:

• iOS: APNs (via FCM for easier integration, or direct APNs)
• Android with Google Services: UnifiedPush with embedded FCM distributor fallback
• Android without Google Services: UnifiedPush with user-installed distributor (ntfy, NextPush, etc.)

This approach gives privacy-conscious users maximum control while maintaining functionality for mainstream users.

How Firebase Cloud Messaging Actually Works

Privacy Characteristics

FCM has significant privacy implications that conflict with privacy-focused app goals:

What Google can see by default:

• Notification content in plaintext - FCM uses TLS for point-to-point encryption (your server → Google → device) but provides NO end-to-end encryption
• All metadata: IP addresses, device information, Firebase Installation IDs, timestamps, message frequency patterns
• User correlation: Connection between device tokens and notification patterns
• Analytics data: Messages sent, opened, notification interaction patterns

Recent academic research (arXiv 2024, "The Medium is the Message") found FCM enables extensive metadata tracking, and many "secure messaging" apps inadvertently leak sensitive data to FCM in plaintext.

Platform Support Matrix

Platform	FCM Support	Privacy Reality
iOS	✅ Works via APNs bridge	Content passes through both Google AND Apple servers
Android (with Google Play Services)	✅ Full support	Google has visibility unless you implement E2E encryption
GrapheneOS	⚠️ Only with sandboxed Play Services	User must install Play Services (defeats degoogling purpose)
LineageOS/degoogled Android	❌ Doesn't work	Requires Google Play Services or microG (still uses Google servers)

Making FCM More Private

If you must use FCM, implement these mitigations:

1. End-to-End Encryption (Essential)

// Use data messages only (not notification messages)
// Encrypt payload before sending to FCM
// Decrypt in app - notification never shows content until decrypted
// Consider using Google's Capillary library for E2E encryption

// Or implement custom encryption with user's Nostr keys

2. Empty Wake-Up Messages

// Send minimal data via FCM as wake-up signal only
// App fetches actual content from your server/relay
// Sensitive data never transits through FCM
// Drawback: Latency - app has limited time to fetch before backgrounding

3. What Still Leaks Even with perfect E2E encryption implementation:

• Timing of notifications (metadata)
• Frequency patterns
• IP addresses
• Device identifiers
• Correlation between users

For a privacy-focused Nostr app with NIP-59, relying solely on FCM contradicts your privacy goals.

UnifiedPush: The Privacy-Preserving Alternative

What It Is

UnifiedPush is an open-source, decentralized push notification protocol that allows users to choose their push provider. It's the only viable solution for truly degoogled Android and has gained significant adoption in privacy-focused apps.

Architecture:

• Distributor app (ntfy, NextPush, Conversations): Maintains single persistent connection
• Your app: Registers with distributor, receives messages
• Push server: Your backend or third-party service
• Protocol: WebPush-compatible (RFC8030/8291/8292) with mandatory end-to-end encryption

Privacy Advantages Over FCM

1. User Choice: Users select which push provider to trust (or self-host) 2. Mandatory Encryption: RFC8291 encryption required - push servers cannot read content 3. Decentralization: No single surveillance point (unlike Google's monopoly) 4. Data Minimization: Distributors don't need app lists or advertising IDs 5. Compartmentalization: Single-purpose apps with minimal permissions (vs. Play Services' system-level privileges)

Platform Support - Critical Limitation

Android: ✅ Excellent - works perfectly with or without Google Play Services iOS: ❌ Not supported - Apple's restrictions prevent background distributors

iOS doesn't allow persistent background services required for UnifiedPush distributors. This is an architectural impossibility, not a missing feature. There is no workaround without jailbreaking.

Flutter Implementation

Package: unifiedpush (pub.dev, version 6.0.2)

• Active maintenance (last updated 3 months ago)
• 140/150 pub points
• Supports Android and Linux only

// Initialize UnifiedPush
UnifiedPush.initialize(
  onNewEndpoint: (PushEndpoint endpoint, String instance) {
    // endpoint.url contains the push URL
    // endpoint includes encryption keys for WebPush
    // Send this to your Nostr relay/backend
    sendEndpointToServer(endpoint.url);
  },
  onMessage: (PushMessage message, String instance) {
    // Message is already decrypted (RFC8291)
    final content = message.content;
    showLocalNotification(content);
  },
  onRegistrationFailed: (String instance) {
    // No distributor available - guide user to install one
    showDistributorSetupDialog();
  },
  onUnregistered: (String instance) {
    // Registration revoked
  },
);
// Try to use existing or default distributor

final success = await UnifiedPush.tryUseCurrentOrDefaultDistributor();
if (success) {

await UnifiedPush.registerApp();

} else {

// Get available distributors

final distributors = await UnifiedPush.getDistributors([]);

if (distributors.isEmpty) {

// Guide user to install ntfy or similar

guideUserToInstallDistributor();

}

}

Embedded FCM Distributor (Best of Both Worlds)

For Android apps that want to support both mainstream users AND privacy-focused users:

// In your Android build.gradle
dependencies {
    implementation 'org.unifiedpush.android:embedded-fcm-distributor:{VERSION}'
}

This provides:

• Automatic FCM fallback when no external distributor is installed
• Same UnifiedPush API for both scenarios
• User choice: Power users can install external distributors (ntfy, etc.)
• Seamless UX: Regular users automatically use FCM without knowing

Available Distributors

Production-ready distributors for users:

1. ntfy - Most popular, lightweight, self-hostable, works with public ntfy.sh server
2. Sunup - Quick and easy, no account needed
3. NextPush - Nextcloud integration
4. Conversations - XMPP client that doubles as distributor

Users install ONE distributor, and ALL UnifiedPush-enabled apps share that single connection (battery efficient).

Real-World Adoption

35+ apps support UnifiedPush, including:

• Amethyst (Nostr client) - October 2023
• Element, FluffyChat, SchildiChat (Matrix)
• Tusky, Fedilab, Pachli (Mastodon)
• Molly (Signal fork) - October 2023
• Mercurygram, Nagram (Telegram forks)

The protocol is stable, production-ready, and actively maintained with funding from NLnet/European Commission.

Alternative Push Solutions

ntfy.sh - The Most Practical Self-Hosted Option

Key Features:

• HTTP-based pub-sub (simple PUT/POST to send notifications)
• Self-hostable (Docker, binary, packages) or use free ntfy.sh
• iOS support via ntfy.sh gateway (limitation: can't use fully self-hosted on iOS)
• Android app on Play Store (FCM-based) and F-Droid (FCM-free)
• UnifiedPush compatible (works as distributor)
• No signup required for basic usage

Privacy:

• ⭐⭐⭐⭐⭐ when self-hosted
• Minimal metadata (topic names, IPs only)
• No tracking or analytics
• Optional application-level encryption

Flutter Integration:

// Use ntfluttery package (pub.dev)
// Or implement WebSocket/HTTP connection directly
final ws = await WebSocket.connect('wss://ntfy.sh/your-topic');

ws.listen((message) {

// Handle notification

showLocalNotification(message);

});
// Or use UnifiedPush protocol with ntfy as distributor

Battery Impact: 0-1% over 17 hours with instant delivery (tested by ntfy developers)

Limitation: iOS still requires ntfy.sh infrastructure (can't use fully self-hosted due to Apple's APNs requirement)

Gotify - Android-Only Self-Hosted

Key Features:

• Open source (MIT), written in Go
• WebSocket-based real-time delivery
• Self-hosted only (no managed service)
• Built-in web UI for management

Critical Limitation: No iOS support - Apple prohibits WebSocket background connections

Use Case: Good for Android-only apps or internal tools, but not viable for cross-platform consumer apps

WebSocket and Polling Alternatives

WebSocket Persistent Connection:

• ✅ Android: Works with foreground service
• ❌ iOS: Not possible in background
• Battery: 1-2% daily (reasonable)
• Requires user to exempt app from battery optimization

Polling:

• Works on all platforms but inefficient
• 15-minute intervals: ~5-8% battery impact
• 1-hour intervals: ~2-3% battery impact
• Use as last resort only

Recommendation: Don't rely on polling or WebSockets as primary solution - use UnifiedPush or push services

How Nostr Apps Handle Push Notifications

Damus (iOS) - APNS with Privacy Preservation

Architecture:

Damus iOS App → notepush Relay → APNS → Device

Key Implementation Details:

• notepush: High-performance Rust-based Nostr relay specifically for APNS
• Repository: github.com/damus-io/notepush
• NIP-98 authentication for secure device token registration
• Checks user mute lists before sending notifications
• No message content in push payload - only event IDs
• Device fetches and decrypts content after notification arrives

NIP-59 Handling:

• Push notification triggers on gift wrap arrival
• App must fetch full event and decrypt locally
• Push server never sees decrypted content
• Mute list checking happens before push (prevents spam)

Code Pattern (from Damus):

// PushNotificationClient.swift
let (data, response) = try await make_nip98_authenticated_request(
    method: .post,
    url: url,
    payload: json_data,
    payload_type: .json,
    auth_keypair: self.keypair
)

Amethyst (Android) - Multi-Strategy Approach

Primary Strategy: Local notifications with relay subscriptions (WebSocket connections)

Optional Push: Year+ old push notification spec with NIP-98 auth

Configuration:

// Users can register device tokens with push servers
// Supports multiple Nostr accounts in single registration
// Filter options: "follows", "wot" (web of trust), or "all"
// Event kinds to notify about (configurable)
// Token lifecycle managed automatically

Pokey Integration: For degoogled Android users

• Pokey (github.com/KoalaSat/pokey): Pull-based notification service
• Runs as Android foreground service
• Maintains persistent connections to Nostr relays
• Multi-account support
• Broadcasts events to other apps via Intent system
• Hell thread detection (skips excessive tag events)

NIP-59 Gift-Wrapped Events and Push Challenge

Three-Layer Architecture:

1. Rumor: Unsigned event with actual content (deniability)
2. Seal (kind:13): Signed by sender, encrypted to receiver, no p-tag
3. Gift Wrap (kind:1059): Signed with ephemeral key, has p-tag for routing

Push Notification Challenge:

• Gift wraps intentionally hide recipient metadata
• Push servers cannot decrypt without private keys
• Routing to correct device becomes complex
• Can't filter spam without decryption

Current Solutions:

1. Routing by p-tag in gift wrap - Slight metadata exposure but necessary for push
2. Trusted inbox relays - Relay operators can offer push services (already trusted for DMs)
3. Empty notifications - Trigger fetch, app decrypts locally
4. WoT-based filtering - Web of trust to filter spam at relay/push server level

Proposed NIP PR #1528: Push Notification Event Watcher API

Status: Open PR, based on Amethyst's year-old implementation

Key Features:

• HTTP POST /register endpoint with NIP-98 auth
• Event-watching servers monitor relays for user-relevant events
• Configurable filtering (event kinds, authors, WoT)
• Support for multiple device tokens per user
• Gift wrap support for privacy
• Users choose which push servers to trust

Not yet finalized but demonstrates emerging standardization efforts

Recommended Architecture for Your Flutter/Nostr App

Multi-Backend Strategy (Required for Cross-Platform)

// Abstract interface for notification providers
abstract class PushNotificationProvider {
  Future<void> initialize();
  Future<String?> getToken();
  Stream<RemoteMessage> get onMessage;
  Future<bool> isAvailable();
}
// Factory to select appropriate provider

class NotificationFactory {

static Future<PushNotificationProvider> createProvider() async {

if (Platform.isIOS) {

// iOS: Must use APNs (via FCM or direct)

return APNsPushProvider();

} else if (Platform.isAndroid) {

// Check Google Play Services availability

final hasGPS = await _checkGooglePlayServices();
  if (hasGPS) {
    // Prefer UnifiedPush with embedded FCM fallback
    return UnifiedPushWithFCMProvider();
  } else {
    // Degoogled Android: UnifiedPush only
    final upProvider = UnifiedPushProvider();
    final available = await upProvider.isAvailable();
    
    if (available) {
      return upProvider;
    } else {
      // No distributor installed - guide user
      throw NoNotificationProviderException();
    }
  }
}
throw UnsupportedError('Platform not supported');

}

}

iOS Implementation (APNs Required)

Option 1: FCM for ease (routes through Google → Apple)

// Use firebase_messaging package
await Firebase.initializeApp();
final messaging = FirebaseMessaging.instance;
// Request permission

await messaging.requestPermission(

alert: true,

badge: true,

sound: true,

);
// Get token

final token = await messaging.getToken();

// Send to your Nostr relay/backend
// Handle messages

FirebaseMessaging.onMessage.listen((message) {

// Never include NIP-59 content in push payload

// Use event ID only, fetch and decrypt in app

fetchAndDecryptNostrEvent(message.data['eventId']);

});

Option 2: Direct APNs (more control, more complexity)

// Use 'push' package (github.com/ben-xD/push)
// Supports APNs directly without FCM intermediary
await Push.instance.requestPermission();
Push.instance.addOnNewToken((token) {

// APNs token - send to your backend

registerAPNsToken(token);

});
Push.instance.addOnMessage((message) {

// Handle foreground messages

handleNostrNotification(message);

});

Privacy Recommendation: Use data-only messages, encrypt with user's Nostr keys, send only event IDs in notifications

Android with Google Play Services

Use UnifiedPush with Embedded FCM Distributor:

// pubspec.yaml
dependencies:
  unifiedpush: ^6.0.2
  flutter_local_notifications: ^17.0.0
// Android build.gradle

dependencies {

implementation 'org.unifiedpush.android:embedded-fcm-distributor:2.1.1'

}
// Initialize

await UnifiedPush.initialize(

onNewEndpoint: (endpoint, instance) async {

// Send WebPush endpoint to your backend

await registerEndpoint(endpoint.url);

},

onMessage: (message, instance) {

// Message arrives encrypted and is auto-decrypted

handleNostrNotification(message.content);

},

onRegistrationFailed: (instance) {

// Should rarely happen with embedded FCM

log('Push registration failed');

},

);
// Register app

final success = await UnifiedPush.tryUseCurrentOrDefaultDistributor();

if (success) {

await UnifiedPush.registerApp();

}

Benefits:

• Regular users: Automatically uses embedded FCM (seamless)
• Power users: Can install ntfy or other distributor for full privacy
• Same codebase handles both scenarios
• No Google services required if user installs distributor

Android without Google Play Services (GrapheneOS/LineageOS)

Require UnifiedPush Distributor:

Future<void> setupDegoogledNotifications() async {
  // Check if distributor is installed
  final distributors = await UnifiedPush.getDistributors([]);
if (distributors.isEmpty) {

// Show setup dialog

await showDialog(

context: context,

builder: (context) => AlertDialog(

title: Text('Push Notifications Setup'),

content: Text(

'This app requires a UnifiedPush distributor for notifications. '

'We recommend ntfy (open source, privacy-focused).\n\n'

'You can self-host or use the free ntfy.sh service.'

),

actions: [

TextButton(

child: Text('Install ntfy'),

onPressed: () {

// Open Play Store or F-Droid

launchUrl('https://f-droid.org/packages/io.heckel.ntfy');

},

),

TextButton(

child: Text('Learn More'),

onPressed: () {

launchUrl('https://unifiedpush.org/users/distributors/');

},

),

],

),

);

return;

}
// Distributor available - register

await UnifiedPush.initialize(/* ... */);

await UnifiedPush.registerApp();

}

User Experience Flow:

1. App detects no Google Play Services
2. Checks for UnifiedPush distributors
3. If none found, guides user to install ntfy (F-Droid link)
4. User installs ntfy, configures server (ntfy.sh or self-hosted)
5. Returns to app, automatically detects distributor
6. Registers and starts receiving notifications

Detecting Google Play Services

import 'package:google_api_availability/google_api_availability.dart';
Future<bool> hasGooglePlayServices() async {

try {

final availability = await GoogleApiAvailability.instance

.checkGooglePlayServicesAvailability();

return availability == GooglePlayServicesAvailability.success;

} catch (e) {

// Not available

return false;

}

}
// Use in your initialization

Future<void> initializeNotifications() async {

if (Platform.isIOS) {

await setupAPNs();

} else if (Platform.isAndroid) {

final hasGPS = await hasGooglePlayServices();
if (hasGPS) {
  await setupUnifiedPushWithEmbeddedFCM();
} else {
  await setupUnifiedPushOnly();
}

}

}

NIP-59 Encryption and Push Notification Privacy

Never Send Decrypted Content

Critical Rule: Push notification payloads must NEVER contain decrypted NIP-59 content

Backend Implementation:

// Your backend / Nostr relay
async function sendNostrNotification(giftWrapEvent, userEndpoint) {
  // DO NOT decrypt the gift wrap
  // Send only event ID and metadata
const payload = {

eventId: giftWrapEvent.id,

kind: giftWrapEvent.kind, // 1059 (gift wrap)

timestamp: giftWrapEvent.created_at,

// NO content, NO decrypted data

};
// For UnifiedPush: Send to WebPush endpoint with encryption

await webpush.sendNotification(

userEndpoint,

JSON.stringify(payload),

options

);
// For FCM: Send data message

await admin.messaging().send({

token: userToken,

data: payload,

// NO notification object (prevents system from showing content)

});

}

Client-Side Handling:

void onMessage(PushMessage message) async {
  // Parse notification payload
  final eventId = message.data['eventId'];
// Fetch full event from Nostr relays

final event = await nostrClient.fetchEvent(eventId);
// Unwrap NIP-59 gift wrap

// 1. Decrypt gift wrap with user's private key

// 2. Extract seal

// 3. Decrypt seal

// 4. Extract rumor (actual content)

final decryptedContent = await nip59Unwrap(event, userPrivateKey);
// NOW show local notification with content

await flutterLocalNotificationsPlugin.show(

0,

decryptedContent.title,

decryptedContent.body,

notificationDetails,

);

}

Privacy Tradeoffs

What Push Servers Can See (even with proper implementation):

• Timing of notifications
• Frequency patterns
• User's push endpoint or device token
• Event IDs (but not content)
• IP addresses (unless using VPN/Tor)

What Push Servers CANNOT See (with proper implementation):

• Message content
• Sender identity (gift wraps use ephemeral keys)
• Recipient identity (no direct pubkey linkage)
• Relationship graphs (gift wraps break correlation)

Best Privacy: Pokey-style pull notifications (Android only)

• No push server involved
• Direct relay connections
• Complete user control
• Cost: Battery drain, persistent notification

Implementation Roadmap

Phase 1: MVP (2-3 weeks)

Week 1: iOS Foundation

// Implement APNs via FCM
// Data-only messages with event IDs
// Local notification display after decryption

Week 2: Android with Google Services

// Implement UnifiedPush with embedded FCM
// Same backend API as iOS
// Test on standard Android devices

Week 3: Android without Google Services

// Guide users to install ntfy
// Test UnifiedPush with external distributor
// Implement fallback strategies

Phase 2: Privacy Enhancements (1-2 weeks)

NIP-59 Integration:

• Ensure gift wrap content never sent in push
• Implement efficient unwrapping
• Add mute list filtering
• WoT-based spam prevention

Self-Hosting Documentation:

• Guide for users to self-host ntfy
• Server setup instructions
• Privacy benefits explanation

Phase 3: Advanced Features (1-2 weeks)

User Controls:

• Notification preferences by event type
• WoT filtering configuration
• Push server selection (for UnifiedPush)
• Battery optimization guidance

Monitoring:

• Track notification delivery rates
• Monitor backend reliability
• User feedback on notification quality

Technical Implementation Details

Flutter Packages Required

# pubspec.yaml
dependencies:
  # Core notification handling
  flutter_local_notifications: ^17.0.0
For iOS and Android with Google Services
firebase_core: ^2.24.0

firebase_messaging: ^14.7.0
For degoogled Android
unifiedpush: ^6.0.2
Platform detection
google_api_availability: ^5.0.1
Nostr protocol
(your existing Nostr packages)

Complete Multi-Backend Service

// notification_service.dart
class NotificationService {
  static final NotificationService _instance = NotificationService._internal();
  factory NotificationService() => _instance;
  NotificationService._internal();
PushNotificationProvider? _provider;

final FlutterLocalNotificationsPlugin _localNotifications =

FlutterLocalNotificationsPlugin();
Future<void> initialize() async {

// Initialize local notifications

await _initializeLocalNotifications();
// Select and initialize push provider
try {
  _provider = await NotificationFactory.createProvider();
  await _provider!.initialize();
  
  // Register endpoint/token with backend
  final token = await _provider!.getToken();
  if (token != null) {
    await _registerWithBackend(token);
  }
  
  // Listen for messages
  _provider!.onMessage.listen(_handleMessage);
} catch (e) {
  // No push available - offer alternatives
  _handleNoPushAvailable(e);
}

}
Future<void> _initializeLocalNotifications() async {

const androidSettings = AndroidInitializationSettings('@mipmap/ic_launcher');

const iosSettings = DarwinInitializationSettings(

requestAlertPermission: true,

requestBadgePermission: true,

requestSoundPermission: true,

);
await _localNotifications.initialize(
  const InitializationSettings(
    android: androidSettings,
    iOS: iosSettings,
  ),
  onDidReceiveNotificationResponse: _handleNotificationTap,
);

}
Future<void> _handleMessage(RemoteMessage message) async {

// Extract event ID from notification

final eventId = message.data['eventId'];

if (eventId == null) return;
// Fetch full Nostr event from relays
final event = await NostrClient.instance.fetchEvent(eventId);
if (event == null) return;

// Decrypt NIP-59 gift wrap
final decryptedContent = await _unwrapNIP59(event);

// Show local notification with decrypted content
await _showLocalNotification(decryptedContent);

}
Future<Map<String, dynamic>> _unwrapNIP59(NostrEvent event) async {

// Implement NIP-59 unwrapping

// 1. Verify it's a kind:1059 gift wrap

// 2. Decrypt with user's private key to get seal

// 3. Decrypt seal to get rumor

// 4. Return rumor content

// (Implementation depends on your Nostr library)

}
Future<void> _showLocalNotification(Map<String, dynamic> content) async {

const androidDetails = AndroidNotificationDetails(

'nostr_messages',

'Nostr Messages',

channelDescription: 'Private messages and notifications',

importance: Importance.high,

priority: Priority.high,

);
const iosDetails = DarwinNotificationDetails();

await _localNotifications.show(
  DateTime.now().millisecondsSinceEpoch ~/ 1000,
  content['title'] ?? 'New Message',
  content['body'],
  const NotificationDetails(
    android: androidDetails,
    iOS: iosDetails,
  ),
);

}
void _handleNoPushAvailable(dynamic error) {

if (error is NoNotificationProviderException) {

// Show dialog to guide user to install ntfy

// Or explain they need Google Play Services

}

}

}

Backend Server Implementation

Your Nostr relay or backend needs to support multiple push formats:

// Example Node.js backend
const admin = require('firebase-admin');
const webpush = require('web-push');
// Initialize FCM

admin.initializeApp({

credential: admin.credential.cert(serviceAccount),

});
// Initialize WebPush for UnifiedPush

webpush.setVapidDetails(

'mailto:your@email.com',

vapidPublicKey,

vapidPrivateKey

);
// Send notification

async function sendNotification(user, nostrEvent) {

const payload = {

eventId: nostrEvent.id,

kind: nostrEvent.kind,

timestamp: nostrEvent.created_at,

};
// Determine user's notification provider

if (user.pushType === 'fcm') {

// FCM for iOS or Android with Google Services

await admin.messaging().send({

token: user.fcmToken,

data: payload,

apns: {

payload: {

aps: {

'content-available': 1,

alert: {

title: 'New Message',

body: 'You have a new Nostr message',

},

},

},

},

});

} else if (user.pushType === 'unifiedpush') {

// UnifiedPush for Android (via WebPush)

await webpush.sendNotification(

{

endpoint: user.unifiedpushEndpoint,

keys: user.webpushKeys,

},

JSON.stringify(payload)

);

}

}

Self-Hosted vs Managed Trade-offs

For Your Privacy-Focused Nostr App

Self-Hosted (Recommended):

• ✅ Complete data control - aligns with Nostr philosophy
• ✅ No third-party notification tracking
• ✅ Users can verify no logging
• ✅ Complements self-hosted relays
• ⚠️ Requires infrastructure maintenance
• ⚠️ iOS still requires APNs (Apple's servers)

Managed (Pragmatic):

• ✅ Easier initial deployment
• ✅ Reliable infrastructure
• ✅ Faster time-to-market
• ❌ Third-party visibility into notification patterns
• ❌ Contradicts privacy messaging
• ⚠️ Can migrate to self-hosted later

Hybrid Recommendation:

1. Start with FCM for iOS (no alternative)
2. Start with UnifiedPush + embedded FCM for Android (easy)
3. Document self-hosting instructions for users
4. Eventually offer self-hosted ntfy server option
5. Let users choose: convenience (FCM) or privacy (self-hosted UnifiedPush)

Key Recommendations

Architecture

Implement multi-backend from day one - retrofitting is painful:

abstract class PushProvider {
  Future<void> init();
  Future<String?> getToken();
  Stream<Map<String, dynamic>> get messages;
}
class IOSPushProvider implements PushProvider { }

class AndroidFCMProvider implements PushProvider { }

class AndroidUnifiedPushProvider implements PushProvider { }

Privacy Priorities

1. Never send decrypted NIP-59 content in push payloads
2. Use data messages only (no notification objects with content)
3. Implement E2E encryption for any content that transits push servers
4. Send event IDs only, fetch and decrypt in app
5. Document metadata that push services see in privacy policy
6. Offer UnifiedPush option for Android users who want full privacy

User Experience

Be transparent about trade-offs:

• "iOS requires Apple servers for notifications (Apple's restriction)"
• "Android users can choose: convenience (Google) or privacy (UnifiedPush)"
• "Self-hosting available for maximum privacy"

Guide degoogled users:

• Detect no Google Play Services
• Friendly dialog: "Install ntfy for notifications"
• Link to F-Droid
• Explain benefits (privacy, no Google)

Testing

Test on actual devices:

• ✅ Stock iOS (latest and older versions)
• ✅ Standard Android with Google Services (Samsung, Pixel, OnePlus)
• ✅ GrapheneOS (critical for your use case)
• ✅ LineageOS without Google apps
• ✅ CalyxOS (includes microG)

Test scenarios:

• ✅ App in foreground
• ✅ App in background
• ✅ App force-closed
• ✅ Device restart
• ✅ Network changes (WiFi ↔ cellular)
• ✅ Battery optimization enabled

Conclusion: Practical Path Forward

For your privacy-focused Flutter/Nostr app with NIP-59, here's the pragmatic implementation path:

Minimal Viable Push (MVP)

iOS: Use FCM → APNs (only option, be transparent about this) Android: Use unifiedpush package with embedded FCM distributor Backend: Support both FCM tokens and UnifiedPush WebPush endpoints

This gives you:

• ✅ Full platform coverage
• ✅ Works for mainstream users immediately
• ✅ Privacy-focused users can use external UnifiedPush distributors
• ✅ Single Flutter codebase
• ✅ 2-3 week implementation time

Privacy-Enhanced (Future)

Add Pokey integration: For Android users who want zero push servers Document self-hosting: Guide for ntfy server setup WoT filtering: Reduce spam without server-side content access Tor support: For users who want IP privacy

What You CANNOT Avoid

• iOS will always route through Apple (no technical workaround)
• Cross-platform requires multiple implementations (iOS ≠ Android)
• Some metadata leakage is unavoidable with push notifications
• Trade-off between convenience and privacy exists

What You CAN Control

• Never send NIP-59 decrypted content in notifications
• Give users choice (UnifiedPush vs FCM on Android)
• Document exactly what metadata is visible
• Support self-hosting for maximum privacy
• Align implementation with Nostr's decentralization principles

The UnifiedPush + embedded FCM approach is the sweet spot for your use case - it balances privacy (for those who want it), convenience (for mainstream users), and practical development effort.

[AndreaDiazCorreia]

@grunch this is the research from claude