Orbot Push Notifications Enhancement Proposal

[05nelsonm]

Orbot Push Notifications Enhancement Proposal

Posting this to generate some dissucsion, thoughts, ideas, etc. This is not a fully flushed out idea, so please beat it to a pulp so the best possible product can be had in the long run.

Problem:

Going FLOSS only on an android device (flashing AOSP) requires living without some conveniences; one of them being Google Cloud Messaging (GCM). There are alternatives out there to restore such functionality (microG), but come at a cost (I will leave that discussion untouched).

GCM provides an extremely convenient service for push notifications that is a primary driver for people to either:

1. Not flash an AOSP rom and continue running Google Play Services
2. Flash a modified AOSP ROM that contains microG which isn't a great solution, and is beyond most peoples' technical abilities.

Solution:

Build into Orbot a push notification services such that app developers can implement the necessary code into their app which will enable Orbot the ability to act as a push notification service, if the user chooses to do so.

Benefits:

1. Provides developers and users an alternative, no root, fully open source solution to GCM.
2. Having several apps polling every X seconds can be battery draining, nor is it practical with calls, or "right that second" needed notifications. Running Orbot from boot as it is, this service may actually improve battery performance if you're only running 1 app (in our case, Orbot) that is capable of handling all of this.
3. Cross platform compatibility. My desktop application can ping my HS to display a generic, custom notification w/o having the need to build an application and rely on a middle man server. Imagine a Bitcoin Core plugin that can notify you that you received payment.
4. Potential to pickup more Tor relay servers while device is charging, on unlimited data/WiFi, and between the hours for when the user sets (sleep time).
5. All of the p2p decentralization.

Rough Concept, or Flow:

• In Orbot, user chooses to enable the Orbot Push Notification service.
• User selects Custom or Android App
• Custom option: can be used for desktop applications, and user can configure the notification message they want displayed
• Android App option: Orbot prompts the user what compatible app they would like to set it up with, to obtain the app's package name.
• Orbot sets up a v3 Hidden Service (if one does not already exist for the notification service) and provides a generated keypair for client authorization (I believe the max is 300 client auth pairs per HS).
• Maybe a button that copies the necessary information for the .auth_private file to the clipboard, and then sends an intent to open Nextcloud Talk.
• User navigates to settings and clicks some option to enable Orbot Push Notifications.
• User pastes the information for the .auth_private file to be generated serverside
• The user's Nextcloud server will do magick with more Tor magick.
• Enabled
• Nextcloud server now pings the Orbot HS, and based off of the client auth keypair that was used, Orbot can identify which application the user should be notified about (in our case, Nextcloud Talk).

Additional thoughts/ideas (Again, using NC Talk as example):

Thought 1:

Because app developers would have to modify their app to be compatible
anyways, would is be possible to do the same thing that the Orbot Helper
method call does in allowing Orbot to open the Nextcloud Talk app up to
the settings activity and inject the needed information right then and there
(sort of like how the Android Settings app works when sending an intent to
open up Accessibility Settings for example)?

Thought 2:

When Orbot is generating the data for the .auth_private keypair to be input
in the compatible application, it could also generate a token which could be
sent to the Nextcloud Talk app during the setup process, and saved.

This token could be used in the notification that Orbot generates for the user,
such that when the user clicks on it, it sends a broadcast and opens the app
to the necessary activity.

Could also be such that Orbot can standardize the ping with use of an
enum ("Message", "Call", "VideoChat") so that when the Nextcloud server pings
the HS, Orbot knows what to do (Display a notification for received new
message, or open the NC talk app using the generated Token to the call
activity because the user has an incoming call, etc).

There could potentially be several types of enums to differentiate between
notifications which could standardize things, so that other app developers can
choose what they would like their app to do when they recieve a broadcast intent
that contains which enum, and if it has the proper credentials.

I'm digging through the Briar app right now, as they have this setup already.

Please share thoughts, ideas, concerns, etc.!!!

[SkewedZeppelin]

battery

Orbot sets up a v3 Hidden Service

https://code.briarproject.org/briar/briar/issues/1263
https://code.briarproject.org/briar/briar/issues/769
https://code.briarproject.org/briar/briar/issues/44

on topic:
https://gotify.net/
seems fairly polished
you'd need apps to actually adopt it which would be extremely difficult
you could even then add Orbot support to Gotify and still connect via a hidden service (client->server seems to have far less impact on battery)

[Sorunome]

Lately there have been lots of effort to create an open, standardized protocol for push notifications without fcm, called UnifiedPush. It is the spiritual successor of OpenPush. Orbot could follow the open UP specification, making it interoperatable with existing apps implemnting UP etc.