diff --git a/src/Core/Platform/Push/README.md b/src/Core/Platform/Push/README.md index 68ed7f0598..59a7e1a28e 100644 --- a/src/Core/Platform/Push/README.md +++ b/src/Core/Platform/Push/README.md @@ -29,8 +29,8 @@ await pushNotificationService.PushAsync(new PushNotification ## Extending If you want to extend this framework for sending your own notification type you do so by adding a -new enum member to the [`PushType`](./PushType.cs) enum. Assign a number to it that is 1 above the next -highest value. You must then annotate that enum member with a +new enum member to the [`PushType`](./PushType.cs) enum. Assign a number to it that is 1 above the +next highest value. You must then annotate that enum member with a [`[NotificationInfo]`](./NotificationInfoAttribute.cs) attribute to inform others who the owning team and expected payload type are. Then you may inject [`IPushNotificationService`](./IPushNotificationService.cs) into your own service and call its @@ -40,10 +40,10 @@ You should NOT add tests for your specific notification type in any of the `IPus implementations. They do currently have tests for many of the notification types but those will eventually be deleted and no new ones need to be added. -Since notifications are relayed through our cloud instance for self hosted users (if they opt in) it's -important to try and keep the information in the notification payload minimal. It's generally best -to send a notification with IDs for any entities involved, which mean nothing to our cloud but can then be used to get -more detailed information once the notification is received on the device. +Since notifications are relayed through our cloud instance for self hosted users (if they opt in) +it's important to try and keep the information in the notification payload minimal. It's generally +best to send a notification with IDs for any entities involved, which mean nothing to our cloud but +can then be used to get more detailed information once the notification is received on the device. ## Implementations @@ -56,19 +56,18 @@ before its returned task completes. Used when the application is hosted by Bitwarden in the cloud. This sends the notification to the configured Azure Notification Hub, which we currently rely on for sending notifications to: -- Our mobile clients, through the Notification Hub federation with mobile app notification systems, and +- Our mobile clients, through the Notification Hub federation with mobile app notification systems, +and - Our clients configured to use Web Push (currently the Chrome Extension). -mobile clients and any clients configured to use Web Push (currently Chrome Extension). - This implementation is always assumed to have available configuration when running in the cloud. ### Azure Queue -Used when the application is hosted by Bitwarden in the cloud, to send the notification over web sockets (SignalR). This sends the notification to a Azure -Queue. That queue is then consumed in our Notifications service, where the notification is sent -to a SignalR hub so that our clients connected through a persistent web socket to our notifications -service get the notification. +Used when the application is hosted by Bitwarden in the cloud, to send the notification over web +sockets (SignalR). This sends the notification to a Azure Queue. That queue is then consumed in our +Notifications service, where the notification is sent to a SignalR hub so that our clients connected +through a persistent web socket to our notifications service get the notification. This implementation is registered in DI when `GlobalSettings:Notifications:ConnectionString` is set to a value.