Write a custom "Firebase Cloud Messaging" backend using IPFS?

[markg85]

Hi,

This is going to require a bit of explanation so bear with me, please.

First a really quick explanation of IPFS for those that don't know. IPFS is the "InterPlanetary File System", a peer-to-peer network that addresses content by their hash instead of their name. Everyone can host a node and be part of the network and access any file on the network. It is considered to be the backbone of Web3.

One of it's features is a PubSub network (optionally enabled as it's still considered experimental) based on the gossipsub specification.

With PubSub it's easy to send messages from peer x to peer y. These messages could very well be handled as notifications. Now there needs to be a lot more logic here as PubSub is a generic mechanism. And these "notification" messages would just be some of the messages flowing over PubSub.

On Android there is realistically only one way of sending notifications. That's through Firebase Cloud Messaging (FCM). It feels like a vendor lock-in though.

What i would really like to have is: (note, just a braindump, none of it exists)

• On top of IPFS's PubSub a "FCM" compatible way of sending messages
• Within MicroG an option to install a different FCM implementation that would use the IPFS PubSub layer.

Ideally the FCM implementation would handle both FCM as is and the additional IPFS PubSub layer.

All of this is just an idea. Probably many months of coding would be required to get this working.

So my questions for the MicroG folks:

• Is something like this technically even possible?
• Where in the codebase of MicroG would be a good starting point to look at this?
• Is there some pluggable architecture for notification backends?
• How would you folks do this?

Lastly, i'm not planning on making any of this anytime soon as i'm already working on some hefty IPFS projects that need to be done first before starting something new. I am interested in taking this on after that therefore i'm already trying to figure out some of how this works on a technical level.

Your feedback would be much appreciated!

Best regards, Mark

[mar-v-in]

1. Using a complex peer-to-peer networking solution for push notifications is contrary to the idea of using push notifications. We use push notification systems because we want to reduce the number of active network connections to save battery. A complex peer-to-peer network will likely cause more battery drain than having each application with its own connection.
2. You can't change how messages are delivered when apps use FCM. However, apps can decide to not use FCM and instead use a system like UnifiedPush. You could probably create a UnifiedPush-distributor based on gossipsub, but that is certainly out of scope for microG.

[markg85]

1. Using a complex peer-to-peer networking solution for push notifications is contrary to the idea of using push notifications. We use push notification systems because we want to reduce the number of active network connections to save battery. A complex peer-to-peer network will likely cause more battery drain than having each application with its own connection.
2. You can't change how messages are delivered when apps use FCM. However, apps can decide to not use FCM and instead use a system like UnifiedPush. You could probably create a UnifiedPush-distributor based on gossipsub, but that is certainly out of scope for microG.

Thank you for your response! Regarding point 1. I fully agree that IPFS - as it works now - is not the best choice for delivering push notifications due to it's excessive peer communication scheme and just high resource footprint in general. But this isn't how it should be done in my opinion anyhow. A potential better alternative would be kinda akin to bluetooth mesh network. There you have a "low power" mode that is a node that doesn't know anything. It just occasionally pops up and knows how to communicate to a "friend" node who is a bit more resource heavy and does the message delivering. This same concept can be done here too. The on-phone node would then just know a handful of nodes it can connect to and deliver messages via those.

Anyhow, that's all very hypothetical and mostly thought up as i wrote it. It's possible for sure. But that's just in an attempt to convince you that it doesn't have to be a resource heavy kind of thing.

Regarding point 2. That's awesome! I didn't know about that at all! Thank you so much for pointing me in that direction :)

With that i suppose there isn't much more on the microG side for this thus closing this issue.

[ale5000-git]

With these you can use a self-hosted server for push notifications: https://f-droid.org/en/packages/com.github.gotify/ https://github.com/gotify/server

Maybe can be integrated in microG as alternative. @mar-v-in: what do you think?

[coxtor]

With these you can use a self-hosted server for push notifications: https://f-droid.org/en/packages/com.github.gotify/ https://github.com/gotify/server

Maybe can be integrated in microG as alternative. @mar-v-in: what do you think?

I was also thinking about this, could this not work similar Mike microg works woth mapbox: exchange calls to FCM with e.g. gotify stubs?

[ArchangeGabriel]

It cannot work, apps have to implement it, because the server side needs to support it as well.