Push notifications via Firebase API #21
Conversation
| const _logger = baseLogger.extend(config.socket.id) | ||
| _logger.debug(`Initializing push notifications WS event handlers`) | ||
|
|
||
| async function handleSendPushNotifications( |
There was a problem hiding this comment.
I think it would be easier to port this into an independent server for p2p-only users if we implemented this as an https endpoint. We don't really need web socket features for this afaik. I recognize it's probably easier to just use the qss socket for now though since you can just copy the existing pattern though.
mcginty
force-pushed
the
feat/20-push-notifications
branch
2 times, most recently
from
40d837e to
d1fb4d0
Compare
|
@adrastaea this is now rewritten to offer QPS up as an HTTP API based on the rough spec in the Notion doc including the UCAN token generation. The Firebase Admin API code is hooked up, but I've been testing on a mock service that can be enabled in local dev environments, so still a bit more to be done there and to make sure the payloads for the |
mcginty
force-pushed
the
feat/20-push-notifications
branch
from
e0fc9e3 to
dea4aea
Compare
QPS provides the ability to deliver push notifications to devices using Quiet, using the Firebase Cloud Messaging API to support both Android and iOS service. This adds an HTTP API with two endpoints: - `POST /v1/register` will register a device notification token and the server will respond back with a UCAN token to indicate. - `POST /v1/push` will send a single notification to a single device, based on the provided UCAN token. Includes a tool to test WebPush notification via Firebase. TODO: - Still finalize data structures for notification payload.
mcginty
force-pushed
the
feat/20-push-notifications
branch
from
dea4aea to
815be0e
Compare
| /** | ||
| * Mock implementation for testing without Firebase credentials | ||
| */ | ||
| private sendMock(deviceToken: string, payload: PushPayload): PushResult { |
There was a problem hiding this comment.
I might be missing something, but is there a reason why this is actual code in the service rather than using jest.mock in the unit tests? My concern is production code carrying test-only logic complicating reasoning about the code.
There was a problem hiding this comment.
Yeah, I kept it available outside of tests so that one can poke at it locally via the client - it will refuse to allow this mock mode when the environment is production, but I can also just put this in test code only before we merge this.
| apns: { | ||
| payload: { | ||
| aps: { | ||
| contentAvailable: true, |
There was a problem hiding this comment.
I think we need mutableContent: true in order to allow the NSE to modify the notification based on what it pulls and decrypts
There was a problem hiding this comment.
Nice, will do - this data structure as-is is currently a "placeholder" since I wasn't sure what all was needed for our uses.
2 participants
This supports both Android and iOS push services, and will allow for the forwarding of encrypted notifications from clients that the targets can decrypt in the background before displaying a more useful notification from the payload.
Closes #20
Closes TryQuiet/quiet#3086