# How Meetily's Notification System Handles User Preferences and OS Integration

> Discover how Meetily's notification system manages user preferences and OS integration. Learn about its layered architecture and reliable delivery through Tauri.

- Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily)
- Tags: how-to-guide
- Published: 2026-07-13

---

**Meetily's notification system uses a layered architecture that checks user preferences, consent, and Do-Not-Disturb settings before delegating to Tauri-based OS notifications via `NotificationManager` and `SystemNotificationHandler`.**

Meetily, the open-source meeting assistant from Zackriya-Solutions, implements a privacy-first notification system that balances granular user control with seamless cross-platform delivery. The system stores preferences in JSON files and validates every notification against consent, permissions, and Do-Not-Disturb modes before reaching the OS level. This architecture ensures that users maintain complete control over which notifications appear and when.

## Architecture Overview

Meetily's notification system operates through three coordinated layers: user preference storage via `NotificationSettings`, consent management through `ConsentManager`, and OS-level delivery via `SystemNotificationHandler`. The `NotificationManager` in [`frontend/src-tauri/src/notifications/manager.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/notifications/manager.rs) orchestrates these components, ensuring every notification respects both user preferences and system constraints.

## User Preference Management

### NotificationSettings Structure

In [`frontend/src-tauri/src/notifications/settings.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/notifications/settings.rs), the `NotificationSettings` struct defines user-configurable flags including `recording_notifications`, `time_based_reminders`, and `respect_do_not_disturb`. A nested `NotificationPreferences` struct allows fine-grained control over individual notification types such as `show_recording_started` and `show_meeting_reminders`.

The settings also track the user's manual DND choice (`manual_dnd_mode`) and whether they have granted consent (`consent_given`) or system permission (`system_permission_granted`).

### ConsentManager and JSON Persistence

The `ConsentManager` handles persistence using the platform's config directory (`dirs::config_dir()`). On first launch, `initialize_on_first_launch` creates a default [`notifications.json`](https://github.com/Zackriya-Solutions/meetily/blob/main/notifications.json) file. The manager provides async methods including `has_consent()`, `set_consent()`, `has_system_permission()`, and `set_system_permission()` to track both user consent and OS-level permissions. All changes persist through `save_settings` and reload via `load_settings`.

## Cross-Platform OS Integration

### SystemNotificationHandler Implementation

Located in [`frontend/src-tauri/src/notifications/system.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/notifications/system.rs), the `SystemNotificationHandler` bridges Meetily to the operating system's native notification center. It uses Tauri's `notification()` plugin to build notifications that display consistently across Windows, macOS, and Linux.

### Tauri Notification Plugin Usage

The handler constructs notifications using Tauri's builder pattern:

```rust
let builder = self.app_handle.notification().builder()
    .title(&notification.title)
    .body(&notification.body);
builder.show()?;

```

Before displaying, the handler checks `should_respect_dnd` to determine if the current Do-Not-Disturb mode should block the notification. Critical notifications with `NotificationPriority::Critical` bypass these restrictions.

### Permission Handling

On supported platforms, Tauri auto-grants notification permissions, making `request_permission` a no-op that returns `Ok(true)`. The system tracks this state in `system_permission_granted` within the settings.

## Centralized Coordination via NotificationManager

### Initialization Flow

When `initialize()` is called, the `NotificationManager` loads existing settings via `ConsentManager` and requests system permissions if not already granted. This ensures the notification pipeline is ready before any UI components attempt to display alerts.

### The Notification Validation Pipeline

Every public method like `show_recording_started()` or `show_meeting_reminder()` triggers a private `should_show_notification` check that enforces three conditions:

1. **Consent verification**: Both `settings.consent_given` and `settings.system_permission_granted` must be true
2. **Do-Not-Disturb evaluation**: If `manual_dnd_mode` is active, only `Critical` priority notifications proceed
3. **Per-type filtering**: The method matches the `notification.notification_type` against the user's `notification_preferences`

### End-to-End Recording Notification Example

When a recording starts, the flow executes as follows:

1. The UI invokes `notification_manager.show_recording_started(meeting_name)`
2. The manager reads `settings.notification_preferences.show_recording_started`
3. If enabled, it creates a `Notification` instance (defined in [`frontend/src-tauri/src/notifications/types.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/notifications/types.rs)) and runs `should_show_notification`
4. Assuming all checks pass, the manager calls `self.system_handler.show_notification(notification).await`
5. The `SystemNotificationHandler` builds the Tauri notification and displays it via the OS native notification center

## Summary

- Meetily's notification system uses a four-file architecture ([`types.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/types.rs), [`settings.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/settings.rs), [`system.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/system.rs), [`manager.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/manager.rs)) to separate concerns between data structures, persistence, OS integration, and orchestration
- User preferences store in JSON format at the platform config directory, tracking both granular notification types and global DND settings
- `ConsentManager` provides async methods for consent and permission tracking with automatic persistence
- `NotificationManager` validates every notification against consent, permissions, DND status, and per-type preferences before delegating to the system handler
- Critical notifications bypass Do-Not-Disturb restrictions while respecting user consent
- Cross-platform delivery relies on Tauri's native notification plugin, ensuring consistent behavior across Windows, macOS, and Linux

## Frequently Asked Questions

### Where does Meetily store notification preferences?

Meetily stores notification preferences in a JSON file located in the platform's configuration directory (`dirs::config_dir()`), managed by the `ConsentManager` in [`frontend/src-tauri/src/notifications/settings.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/notifications/settings.rs). The file initializes with default values on first launch and persists changes through the `save_settings` method.

### How does Meetily handle Do-Not-Disturb mode?

The system checks `manual_dnd_mode` in `NotificationSettings` before displaying any notification. If DND is active, only notifications with `NotificationPriority::Critical` bypass the block. This logic executes in `should_show_notification` within `NotificationManager` before delegating to the OS handler.

### Can users disable specific notification types while keeping others enabled?

Yes. The `NotificationPreferences` struct in [`settings.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/settings.rs) contains individual boolean flags like `show_recording_started` and `show_meeting_reminders`. The `NotificationManager` checks these per-type preferences against the incoming notification type before showing anything.

### Does Meetily request notification permissions from the operating system?

Meetily tracks OS-level permissions through `set_system_permission()` and `has_system_permission()`, but Tauri's notification plugin auto-grants on supported platforms. The `SystemNotificationHandler` in [`system.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/system.rs) handles permission requests, though `request_permission` typically returns `Ok(true)` immediately on Windows, macOS, and Linux.