Goes offline unpredictably

[7heo]

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]

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]

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]

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]

Opened up issue #7

[7heo]

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]

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]

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]

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]

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]

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]

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]

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?