Push notification API

[markg85]

Use cases

If you develop a user driven site in IPFS you might need some way of informing the users about something. For instance of a new mail message, an admin approval, a blocked whatever. IPFS currently has no such system (to my knowledge). But for a true distributed application it is vital to be able to send some form of notifications. For users that are on the IPFS network a simple pub/sub mechanism could work. For users that are wholly offline that won't cut it either.

Joining the Google and Apple push notification API's?

Well, their API's might not be a bad thing, but their services might be an issue. It means that you still eventually enter a centralized environment. Aka, their API endpoints. That might not be the best thing.

Suggestion: Make a very lightweight Andoid and iOS app that can receive push notifications

The distributed nature of IPFS is wonderful, it should stay that way. Even with push notifications. Therefore a lightweight client that can connect to the IPFS network and handle push notifications should probably be developed. A user should install that on their phone.

Note that these applications should be a bridge between whatever app someone made on IPFS and the user that is trying to be reached. This means that push notifications received should be - for the user - identifiable to the application that had send it. So not the push notification app itself, but the web application. In other terms, the web application developer should be able to set the name, title and icon which makes it identifiable for the user.

Please don't try to make the push notification clients part of the IPFS network as a whole. IPFS, while it's awesome, is also very resource intensive. The notifications clients should just be nodes that are known in the network to deliver push notifications too. The notification clients themselves should not participate in the broader scope of IPFS. Just notifications. KISS :) The phone apps should probably connect to at most 10 peers or so.

Don't forget the desktop! Desktop notifications.

The IPFS desktop client should probably gain a way to handle push notification too. On the desktop client side that should then be hooked into something that is native to the pc it runs on. On Linux for example, it should eventually show a message using the "notification-daemon" and be done.

API concept

When one makes a web application using IPFS they should have access to "a to be made up" API for sending push notifications. A minimal API should:

• Allow for an application name to be set
• Text to set
• Icon to set
• user hash to send the notification too
• sender hash of the application that had send the push (this should not be an API entry to set, it should be forced)
• Add a "pin --till-delivered" option. The message is pinned till delivered to a client that handled the push notification and showed it to the user. Note that you could also extend the use of this flag for one-time downloads. It doesn't need to be specific for push notifications, it can be generic.

Prevent spam!

Now the above description makes it very easily possible to spam anyone in IPFS. That is most certainly not my intention! I do not envision a system where you first send a push message to ask permission if <hash> is allowed to send you push notifications. As that too can then be abused by others to just spam users with loads of requests. This system might work though.

A more secure way i can think of is PGP. The push notification system in the web application asks the user (on the website, not the push notification app) if a user wants to receive push notification. If it does, then push notifications for that user will be encrypted with the user's public key. In the push notification app that message is then decrypted with the users private key. And only then when it all passes the message is shown.

This does have a downside of (in the case of someone spamming intentionally) that a phone can be crippled by decrypting messages that will never show as they are not signed by the one receiving them. Oh well, that's an issue for you very smart devs out there to try and prevent :)

---

If you ignore the pinning part then most of this seems to be all in place already. Mostly under pub/sub. Only push notifications could outlive pub/sub so that might be something that still has to be implemented if the IPFS devs go and implement this idea.

I hope you folks like this idea. I certainly do :)

I'm looking forward to hearing your thoughts. Please do note that i am a developer but am not likely going to implement this. I merely share the thought. The Go language is still quite alien to me.

Cheers,
Mark

[Stebalien]

Really, I think we want two things here:

1. A low power mode. That is, some mode where we reduce the number of connections to some minimum (possibly funneling them through a single relay) and tell all connected peers to "shut up".
2. Trusted pubsub relays that do all the heavy lifting.

However, this is going to be a ways off. We'll need to:

1. Significantly improve the libp2p daemon. I expect phones will run a single, global libp2p daemon, not an ipfs daemon.
2. Implement this pubsub relay service. Basically, it'll act like a normal pubsub service except it will auto-subscribe to topics whenever a peer subscribes to the topic.
3. Add "shut up" messages to our protocols.