Skip to content
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

Push notifications #5

Open
manton opened this issue Aug 23, 2018 · 8 comments

Comments

@manton
Copy link

commented Aug 23, 2018

I blogged here about how Micro.blog could provide push notifications for third-party apps like Icro. Here are some additional thoughts on it:

  • @hartlco would generate push certificates via Apple's developer program and send them to me to store on Micro.blog servers.
  • Icro would be updated to call into Micro.blog to register the client app when the app launched. I'm thinking this might be a "last app wins" approach. So if you open the official Micro.blog app, it switches push notifications to target that app. If you then open Icro, it switches to sending notifications to Icro.
  • Micro.blog currently only sends notifications for @-mentions. Later it could be updated to send silent notifications when any new posts arrive, for a more real-time experience.

Feedback welcome, of course. Whatever we do here can be a template for other apps.

@PaulVittorino

This comment has been minimized.

Copy link

commented Aug 23, 2018

Silly question: why not allow multiple applications to receive notifications?

@nitinthewiz

This comment has been minimized.

Copy link

commented Aug 23, 2018

I would agree with Paul about multiple apps, so that people can decide how many notifications...

Wait, no. Manton's got a cool idea. That's what should be the right way of sending notifications. Unless the user selections an option to NOT get notifications in a particular app during onboarding (@manton that scenario needs to be handled in app and on m.b servers), or if the app implements a setting for "don't steal notifications from other apps for me".

@pyrmont

This comment has been minimized.

Copy link

commented Aug 24, 2018

Using a 'last app wins' approach would be inconsistent with the way notifications work in other apps and would be counterintuive to users. If I have multiple e-mail clients installed, I get notifications as set on a per-app basis.

I do think there should be some way for apps to expose some sort of filtering to the user so that particular notifications can be toggled. If I have Icro and Sunlit installed, for instance, I would prefer if notifications relating to posts I'd made with Sunlit did not trigger a notification in Icro. I'm not familiar enough with notification payloads but is there some way to pass data to an app that indicates the 'type' of notification?

@hartlco

This comment has been minimized.

Copy link
Owner

commented Aug 24, 2018

I'm a big fan of @manton's suggestion here.

I have the feeling it will keep the complexity on the App and micro.blog's backend in a manageable size. Having fine granular push settings might easily require an own backend-infrastructure and that's something I don't even want to consider.
Having every App that registered for the users pushes receive all the pushes might increase micro.blogs backend load and cost, but I can't judge this.

Regarding @nitinthewiz suggestion: The Apps can have a setting if the user want's to register for pushes or not. If the users decided not to have pushes for Icro, the App would not send the updated information to micro.blog and the "push right" stays with the old "winner".

@manton : Do you have a timeframe when this could be ready from your side? I. think this would be a tremendous improvement for all the 3rd party clients!

@hartlco hartlco added the enhancement label Aug 28, 2018
@danieldickison

This comment has been minimized.

Copy link

commented Aug 30, 2018

I like the idea of a single push target app, but it might not work so well if/when there are silent notifications for all new timeline posts — since these don’t require user permissions, many apps may decide to register tokens with micro.blog at launch/login without asking for permission in order to get “streaming” updates. To support that behavior, the backend would need to allow for multiple push targets per user anyways. It would however save the work of storing and managing notification settings per multiple user device, though.

@michaelfransen

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2018

I agree with @danieldickison in regards to the trouble this solution could present with silent notifications. My other concern is that all clients are dependent on micro.blog for their notification format and taking advantage of some of the new features in iOS 12. While I like the idea of 3rd party apps not having to have servers, it really does limit the flexibility/creativity of notifications for 3rd party apps. In addition to this, I don't think users expect apps to work like this and might think a particular app is broken if they aren't getting the notifications from it. I think it is less confusing to the user to not be handing off push notification responsibilities from app to app.

@manton

This comment has been minimized.

Copy link
Author

commented Sep 12, 2019

I've updated Micro.blog to support sending push notifications to multiple apps, and @vincentritter has tested it in Gluon. @hartlco, I can add Icro's cert whenever you want to look at this.

I'm going to update the Micro.blog help soon, but in the meantime I wanted to document everything here. There's an API call you can make on app launch to register a device for push notification.

POST /users/push/register

  • Send the Bearer auth token for the user as normally for any request.
  • Parameters "device_token" = "ABCDEFG…" and "push_env" = "production" (there's no public dev test server yet).
  • Also parameter "app_name" = "Icro". I'll use this to switch to the correct certificate.

When a notification is delivered, in addition to the text of the message, there's some additional information for who sent the notification and who it's for:

{
  "from_user": {
    "username": "manton"
  },
  "to_user": {
    "username": "someone"
  }
}

That's it! Let me know if you have any questions or if there's anything I can help with in the iOS code.

@hartlco

This comment has been minimized.

Copy link
Owner

commented Sep 15, 2019

This is super exciting! @manton I sent you a mail with the Icro certificate attached. I can't wait to implement this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.