NotifyBC Documentation

The Redis setup for NotifyBC depends on the deployment method:

• Helm Chart: Redis configuration is handled automatically.
• Docker: Redis is provided by default via the Redis In-Memory Server.

NotifyBC ensures secure and reliable message delivery through:

• Encryption: Support for end-to-end encryption.
• Authentication: Multiple strategies are supported, including client certificates for server-to-server communication and OIDC (OpenID Connect) for user-to-server communication.
• Availability: The system is designed to be resilient to node failures.

NotifyBC provides a versatile notification system supporting the following features:

• Subscription Types: Supports both anonymous and authenticated subscriptions.
• Delivery Methods: Provides push notifications, in-app pull notifications, and push channels via Email and SMS.
• Messaging Types: Supports both unicast (single recipient) and broadcast (multiple recipients) messages.
• Filtering: Broadcast push notifications can be filtered using rules specified by either the sender or the subscriber.
• Automation: Supports automatic notification generation from RSS feeds.

The Notification API applies different permissions based on the requester's identity:

• Admin Requests (Authorized Server Applications): Full CRUD (Create, Read, Update, Delete) operations are permitted.
• Authenticated User Requests: Limited to retrieving a list of in-app pull notifications targeted to the current user and updating the state of those notifications.
• Unauthenticated Requests: No API access is permitted.

NotifyBC is a RESTful API server designed to manage subscriptions and dispatch notifications without imposing constraints on the UI frontend. It supports multiple notification services (topics), allowing users to subscribe to one or more services across various delivery channels.

Key capabilities include:

• Notification Types: Supports in-app pull notifications (messages/alerts) and push notifications (Email, SMS).
• Message Delivery: Supports unicast and broadcast types, as well as future-dated notifications.
• In-App Management: Tracks read/deleted states and message expiration; deleted messages are retained for auditing.
• Broadcast Push: Supports sync and async POST API calls (with optional callback URLs) and can be auto-generated from RSS feeds.
• Filtering: Allows custom filter rules evaluated against notification data or subscription data.

Dynamic configurations are stored in the database and take effect immediately without requiring a restart. They are managed via the REST configuration API. No dynamic configurations are required during the initial installation.

Dynamic configurations are used for:

• Defining service-specific settings, such as message templates.
• Sharing configurations across multiple nodes in a deployment (typically generated by the primary node).

The Subscription API handles the lifecycle of push notification subscriptions. The workflow differs based on the request source:

1. User Requests: Subscriptions are initially 'unconfirmed'. NotifyBC generates a confirmation code (based on channel-specific regex) or receives one encrypted by a trusted third party via the user's browser. NotifyBC sends this code to the user's notification channel. The subscription is only marked as 'confirmed' once the user echoes the correct code back to the API.
2. Admin Requests: Authorized servers have full CRUD privileges and can set a subscription state to 'confirmed' immediately, bypassing the confirmation process.

For multi-provider trust domains, a third-party server can encrypt a confirmation code using the NotifyBC instance's public RSA key, allowing a user to confirm their channel once for multiple services.