NW.js Notification API floods users with alerts — where should throttling live?

I am building a desktop app on NW.js (assume a recent 0.8x release; I will confirm the bundled Chromium version via nw.process.versions) that surfaces background events from the Node context — file watcher hits and scheduled sync results — as desktop notifications using the standard HTML5 Notification constructor in the window context.

The design concern is noise. When a watcher fires dozens of events in a few seconds, users get a stack of identical pop-ups. NW.js appears to offer no built-in rate limiting or notification channels, so any batching, collapsing, or summary-counter logic has to be implemented in app code. I am also weighing the Tray API (nw.Tray) as a passive status channel, reserving pop-ups for actionable events, but I am unsure where the community draws that line in practice.

A second uncertainty is user control: since NW.js delegates display to the OS, I cannot reliably detect or override OS-level do-not-disturb settings, so an in-app quiet-hours option would only suppress what my code sends, not what the OS shows.

Should throttling live in the Node event layer before messages reach the window context, or in the DOM layer where notifications are constructed? Is a tray-icon-plus-tooltip pattern considered sufficient for passive status, or do users expect a notification history? And is an in-app quiet-hours toggle worth building given the OS delegation limits?