Email or username:

Password:

Forgot your password?
Top-level
Григорий Клюшников

After reading through the docs for both FCM and APNS, I feel like the intermediary server isn't actually necessary, you can have each individual instance send its own push notifications directly to Google/Apple. If you instruct app developers to create separate API keys just for push notifications, no harm could be done with them because you'd also need a device token to actually send something.

11 comments
dansup

@grishka Yeah this is temporary using expo-notifications (docs.expo.dev/push-notificatio)

The long term goal is to match Mastodon in terms of the push notification API and use a generic app proxy

Григорий Клюшников

dansup, Mastodon does also require proxies, every app developer provides one for their own app. It can only send web push natively.

I'm contemplating push notifications for Smithereen (I'll have to have them with the API) but I don't want to require app developers to host a proxy, so I'm thinking about giving them the ability to include their FCM/APNS tokens in the app metadata. But they'll still have the option to use a proxy, of course.

Lyyn ☮️

@grishka @dansup Does Mastodon require a proxy in case of UnifiedPush? I had an impression it doesn't.

feld
@grishka @dansup

> If you instruct app developers to create separate API keys just for push notifications, no harm could be done with them

Is this allowed? And does Apple/Google allow you to share your keys like that?
Григорий Клюшников

feld, what do you mean by "allow"? They do both tell you to "keep them secure", but I can't imagine them revoking the keys that are useless without device tokens anyway.

dansup

@feld @grishka What are you talking about?

This is literally how every Mastodon/Pleroma app works, the developer uses a proxy server to forward requests from Mastodon/Pleroma/Pixelfed to APNS/FCM.

The API keys are for signed requests to my proxy server

dansup

@feld @grishka I want to further clarify that the ExpoToken that the app generates and sends to the server is useless unless you have our expo API key, so you can't abuse access to FCM or APNS

feld
@dansup @grishka I mean if I pull up the source of Husky or whatever on GitHub the key will be in there? I thought it was only in the officially built and distributed app
Григорий Клюшников

feld, no. That's not how it works with Mastodon (and Pixelfed). No currently existing apps do this.

The usual implementation of native mobile app push notifications involves three things:
- A server API key. It's hardcoded on the server that sends push notifications. It's used for authentication when making requests to FCM/APNS. Normally kept secret.
- A client ID. It's hardcoded in the app, used for getting a device token. Google calls it the "FCM sender ID", not sure if Apple has an equivalent or they just use bundle IDs. Mastodon Android app has it hardcoded here.
- A device token. Dynamically obtained by the app at runtime from the system, then sent to the app server. The server then passes this together with the server API key to the Google/Apple server when it wants to send a push notification to this particular device. So, the server API key and the device token together uniquely identify this particular app on this particular device. (The name "device token" might be misleading, because it's also unique per-app on the same device.)

Normally, this server API key is kept secret. I'm proposing to allow app developers to publish theirs to avoid the need for a proxy server whose primary purpose seems to be to keep that key secret (secondary being to not make Mastodon/Pixelfed/whatever implement all the proprietary push APIs).

feld, no. That's not how it works with Mastodon (and Pixelfed). No currently existing apps do this.

The usual implementation of native mobile app push notifications involves three things:
- A server API key. It's hardcoded on the server that sends push notifications. It's used for authentication when making requests to FCM/APNS. Normally kept secret.
- A client ID. It's hardcoded in the app, used for getting a device token. Google calls it the "FCM sender ID", not sure if Apple has an equivalent...

feld
@grishka @dansup there was a misunderstanding on my end; I agree with your description, that's how I understand it. We made a push proxy called Charisma for apps we were working on along side Pleroma so this is familiar.

if there was the ability to *not* have a push proxy run by the app developers it would be great. I strongly support your proposal.
Go Up