Tox distributor

[KOLANICH]

Project description

Moved from irungentoo/toxcore#1614 and open-source-ideas/ideas#57

When a user uses Tox, his device has to maintain a lot of connections anyway (and the battery is drained extremily quick, at least when using Antox). I think Tox can be used to transport these notifications to devices instead of centralized services. An endpoint is just a Tox address. Any service wanting to send pushes should install an own Tox impl and trigger its API instead of triggering HTTP API of a third-party service, using the Tox address uploaded by apps.

The is not to optimize client-side Tox impls itself in terms of power and traffic consumption, but to untie other apps on a phone from centralized services used to deliver pushes. It is intended that the only proper way to send a Tox-based push is to have Tox impls on all server and clients.

[MayeulC]

Hi @KOLANICH,

I am not sure what you are aiming at with this issue, but this is more or less exactly what UnifiedPush aims to solve.

It is not exactly distributed in the sense that UnifiedPush still relies on a client-server paradigm, but it is distributed in the sense that anybody can create a UnifiedPush implementation, server, and distributor.

I think Tox can be used to transport these notifications to devices instead of centralised services

Are you suggesting to transport UnifiedPush notification over Tox? That would make Tox a UnifiedPush distributor, per our definitions. The Conversations Android XMPP client does exactly that over XMPP. It can be done, but requires an HTTP endpoint that does HTTP -> Tox.

[Tox] has to maintain a lot of connections anyway (and the battery is drained extremily quick, at least when using Antox)

It would seem the more appropriate course of action would be to use UnifiedPush to send notifications to Antox, to wake it up so that it can re-establish its energy-intensive connections. This is what push notifications are for: avoiding the need to maintain persistent connections that use a lot of battery.

The TRIfA Android client supports UnifiedPush this way, if you install the companion app. It is listed in the list of compatible applications on the UnifiedPush website.

I also note that usually tokens are not required for UnifiedPush, one could imagine a client sending UnifiedPush notifications when it wants to wake up another client, almost completely p2p.

[KOLANICH]

I am not sure what you are aiming at with this issue, but this is more or less exactly what UnifiedPush aims to solve.

Just a wild idea, not very practical, but kinda beautiful.

It would seem the more appropriate course of action would be to use UnifiedPush to send notifications to Antox, to wake it up so that it can re-establish its energy-intensive connections. This is what push notifications are for: avoiding the need to maintain persistent connections that use a lot of battery.

Yeah, I know. The problem is it'd require an external server. Maybe one can set up a server on a wireless home router for this purpose (not sure though if hardware of most routers fits well for it), but when doing so, Tox on a phone no longer becomes "serverless". If one has to rely only on one's phone, then battery drain is inevitable.

I know that this idea is not very practical for now and has minor value because noone would want to drain one's battery, but in fact everything is tradeoff. For example when a phone is on charging, it may be OK to waste power from the charger and use Tox serverlessly. And when we are already wasting energy, why not at least to have some benefit from it, such as reduced dependence on centralized services.

It can be done, but requires an HTTP endpoint that does HTTP -> Tox.

I guess it can cause additional power drain, if this server is hosted locally on phones. It may be better for a Distributor to interact directly to a Tox network client app via its API or maybe even integrate the distributor directly into the Tox network client app.

The TRIfA Android client supports UnifiedPush this way, if you install the companion app. It is listed in the list of compatible applications on the UnifiedPush website.

Thank you for the info.

[MayeulC]

I guess it can cause additional power drain, if this server is hosted locally on phones.

Power drain is not the main issue, it should be negligible. The main issue is exposing a publicly accessible HTTP endpoint, despite (CG)NAT your phone is usually behind, plus your carrier's firewall. There are no open/forwarded ports, the only way to "open" ports is usually to rely on an external "STUN" server, and that's ephemeral.

One could imagine distributing push notifications through a DHT or an overlay network like yggdrasil, and that's doable, but the UnifiedPush specification assumes HTTP everywhere as a baseline. You can still implement your distributor and make it return, for instance, an i2p: address, but most servers will not be compatible with that.
This is something a future IPv7 could address, but not much can be done regarding this.

[KOLANICH]

Power drain is not the main issue, it should be negligible. The main issue is exposing a publicly accessible HTTP endpoint, despite (CG)NAT your phone is usually behind, plus your carrier's firewall

Now I get what you meant. You meant the public gateway to which an URL can be generated and given to a third party to use that URL to send pushes.

I meant not that, having a public gateway and using it defeats the purpose of "serverlessness" - not to depend on the central servers and so operate even if central servers go down. The idea was not to optimize Tox itself in terms of power consumption, but to untie other apps on a phone from centralized services used to deliver pushes. It was meant that the only way to send a Tox-based push is to have 2 Tox clients, one is on phone and another one on the server sending a push (so

but most servers will not be compatible with that.

applies and is by design, one cannot make an app decentralized without building such capabilities into an app), not via HTTP at all, but using a local Tox impl on server to send push through p2p directly without any external gateways. The client maintains the connection to p2p and receives the push from p2p. It drains battery, but it is inevitable if phone end user uses fully p2p apps.

[p1gp1g]

If I understand correctly, you wish a p2p distributor. The issues #2 and #12 are related then. Maybe renaming this issue "Tox distributor" ?

Regarding the issue your mentioning in the first message "A decentralized push notification service" : this is exactly what UnifiedPush is :)