search

almindor / harbour-jTox

Sailfish OS native tox implementation for Jolla
GNU General Public License v3.0
12 stars 4 forks source link

Goes offline unpredictably #5

Open 7heo opened 7 years ago

7heo commented 7 years ago

Once the screen is locked, it is impossible to predict when the application will go offline (because it is killed by SailFish). The UI and the connectivity part should be decoupled in order to allow the messaging service to perform as such.

almindor commented 7 years ago

Do you mean introducing a service? I plan to do that but not before 1.1.0 with other missing features like "offline" sends.

Will add to 2.0.0

7heo commented 7 years ago

Yes I meant to introduce a system service. The UI and the service should be independent, so the app can be online at all times, much like the SMS and email app do. Also it is important that the app does not go offline unpredictably, since there is no information retaining feature for offline users in the protocol (AFAIK).

7heo commented 7 years ago

Also, the offline sending queue is a feature I was gonna request in a separate issue. Should I do so, or is it fine here?

almindor commented 7 years ago

Opened up issue #7

7heo commented 7 years ago

To work on this issue, the major question is: what is the network requirement to "stay online"? Is it sending packets (heartbeat) to the network? is it listening to incoming packets? Or both? In the case it is "listening", can we listen on a port without keeping the device "alive"?

7heo commented 7 years ago

I found this (and then that) so far. Not encouraging but also not a complete show stopper. I'll try to spend more time to read about the Tox protocol when I have some time.

almindor commented 7 years ago

Yes, tox (the protocol itself) is not exactly "ready" yet.

It's the most open one out there so far tho and the only one 100% community operated. That's why I made jTox.

People need to understand they are using alpha level technology right now. That's why I have the experimental warning on the app itself (about) and in the github readme.

7heo commented 7 years ago

Yeah, that's fair; but that's not what I meant. What I meant is that the issue at hand can not be fixed without spawning the problem "preemptive application termination" is supposed to solve in the first place: battery and network hogging. So this is one of the "bug masking a bigger one". And therefore it's not clear to me if an effort should be made to solve the bug in jTox or if the protocol needs work first.

Now, about what you answered: regardless of the protocol's current state; its inherent P2P nature, and the technical implications of that fact, may not be apparent to most users, let alone the massive network usage. And I'm not convinced that the current warning(s) is(are) sufficient: I saw no warning in the store description, and none while opening the app. Also the only warning I saw (the one you mentioned) in the about page does not warn about network usage, only about security (not the privacy implications). And I think it is less bad to risk not gaining users fir now by being honest about it, than getting a nasty reputation (and project involved, Tox, jTox, etc) by being silent about the issue. If it's open, we owe users transparency, or we've already lost.

almindor commented 7 years ago

I've added a more specific warning to the README here. I'll also change the about in-app warning and add a warning to the store description on the next release.

If you want to help PRs are welcome.

7heo commented 7 years ago

Unfortunately, I do not have enough time to help on this issue. It is an issue that will bring up more problems once it is fixed, unless the protocol has a way to work in a way similar to push notifications, without using the P2P network.

almindor commented 7 years ago

So what I meant by help is not that you fix the protocol issues/networking and/or security. That's too much for any one person. What I meant was help with making the warning messages better.

You can:

  1. Improve the readme file (did some of that now)
  2. Improve the about warning in app (only basic programming knowledge required)
  3. Improve by adding a warning screen on first run in-app (a bit of knowledge required)
  4. Improve by making an issue documenting known tox protocol issues (link to toxcore github issues and explanations).
7heo commented 7 years ago

Hey, thanks for the clarification. I didn't expect you to want help with the protocol, as it is a different project; but with the implementation of the solution in jTox (daemon and such - which is something that IMHO should be deeply discussed first, since it can lead to data-plan-draining and battery-draining problems on mobile).

For writing documentation and warnings, I might help; but I have literally zero knowledge of Harbour/sailfish. Is there a documentation somewhere about QML and Sailfish apps?