New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement push notification infrastructure #350

Closed
nicksellen opened this Issue Aug 25, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@nicksellen
Copy link
Member

nicksellen commented Aug 25, 2017

There are three issues that discus notifications in some way [1] , they are mostly about when to send notifications, this issue is about how to send notifications, specifically about sending them via mobile/browser push technologies.

The assumption is that we want them, so this is about how to implement them in the backend.

The main scenario for this is when there is a mobile app, this could be a cordova wrapped web app (like I have done for a POC in the cordova branch in the frontend), or a native app, or other. It doesn't really matter so much from this perspective.

At the moment there is a ChannelSubscription model which holds information about active websocket sessions. Originally I thought generalizing this (POC in generalize-subscriptions branch) was the way to go, but then I felt that they don't have so much in common:

  • websocket subscriptions
    • somewhat short lived
    • only active when the user is active
    • arrives in short time (a few ms)
    • not much sense to opt in/out - they are there because that is how to app gets data
    • does not need API endpoints - created on connection, removed on disconnection/cleanup
  • push notification subscriptions
    • stay around for some time (so long as the user has the app installed)
    • used when the user is not active
    • has high latency (seconds, or minutes is fine)
    • need controls over opt in/out to not spam the users
    • needs API endpoints to add/remove

So, I would propose to create a new model PushSubscription for this case, and the corresponding API endpoints.

As for the technology for push, I think it is a no-brainer to just use Google FCM - see my explanation of it for when I implemented it for trustroots. Note that they later added support for Expo notifications too, which is only needed if you are using Expo for react-native stuff.

When to send a notification? Initial I would just send a push notification on every chat message. There are some potentially fiddly bits around not overwhelming the user with millions of notifications for active chats (like batching up, replacing old notifications with new aggregate ones etc), but given we do not have active chats, I would just do the simple case, 1 message, 1 notification for each participant/pushsubscription.

Other things I would not care about right now are:

  • how to show a list of notifications in the web ui notifications section (which require a list of notifications to be in the database)
  • user configuration of notifications
  • other kinds of notifications

[1] yunity/karrot-frontend#577 yunity/karrot-frontend#363 yunity/karrot-frontend#257

@nicksellen

This comment has been minimized.

Copy link
Member

nicksellen commented Aug 25, 2017

Ping @tiltec @D0nPiano for comment :)

@nicksellen

This comment has been minimized.

Copy link
Member

nicksellen commented Aug 25, 2017

Also, to note there is a django library that implements most of this already https://github.com/xtrinch/fcm-django - I would evaluate it a bit more before deciding, but I think it might be better to implement our own models for the data, and just use the underlying fcm lib.

@tiltec

This comment has been minimized.

Copy link
Member

tiltec commented Aug 25, 2017

Thanks for initiating the discussion on this - the trustroots implementation looks nice and using plain FCM seems like a good choice.

The main reason to separate push notifications from websocket subscriptions is this:

need controls over opt in/out to not spam the users

I agree, they should always need explicit agreement from the users. But we can implement this later. A sane default for development would be to implement to all platforms where the user registered (app, web)

You don't want to create a model that contains "sent notifications" yet? Based on:

Other things I would not care about right now are:

  • how to show a list of notifications in the web ui notifications section (which require a list of notifications to be in the database)

I agree to just use the python fcm lib instead of fcm-django. We can use some inspirations from django-fcm though.

@nicksellen

This comment has been minimized.

Copy link
Member

nicksellen commented Sep 1, 2017

Merged!

@nicksellen nicksellen closed this Sep 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment