* Rename SiteConfig * More renaming * Update spec * Update mandatory settings mapping * More renaming * e2e test fixes * You have a rename, and you have a rename * Spec fix * More changes * Temporarily disable specs * After-merge update * Undo rename for migration * undo rename of DUS * Fix DUS * Fix merge problem * Remove redundant DUS * Fix specs * Remove unused code * Change wrong class name * More cleanup * Re-add missing values to constant * Fix constant * Fix spec * Remove obsolete fields * Add accidentally removed field * Update spec * Move methods from Settings::General to ForemInstance * Remove unneeded model * Change mentions of 'site config'
1.1 KiB
| title |
|---|
| Push Notifications |
Push Notifications Delivery
Forem instances rely on Rpush to deliver push
notifications. This decision was heavily influenced by the desire to provide as
much flexibility as possible to Creators. In order to do this, Forem instances
can register and configure a ConsumerApp.
These consumer apps represent mobile applications that users use to browse and
consume content on a Forem. Authenticated users of a specific Forem instance can
register a Device associated to a ConsumerApp. With these pieces we are able
to deliver push notifications to users devices.
The ConsumerApp configuration page can be found at
/admin/apps/consumer_apps. The official Forem apps are supported by default
and require their secret credential to be provided via ENV variable.
Rpush Implementation
We use Rpush's rpush-redis implementation (read
this thread for
the reasons why), hence all Rpush models are persisted in Redis. More details
about how this works here.