Threema Web losing connection

[bziemons]

Referencing to #151 and others: Although the bug with reconnecting is fixed (thanks a lot by the way), the reason for losing connection was not yet identified, I think.

Just to give my go at it: I know for a certain that my ISP (Unitymedia it is) does close TCP connections after two minutes of inactivity. Although I think that is hardly what an ISP should do to cleanup old connections, thats what they do. I do have the very same problem with SSH, IRC, VPN, you name it. I suspect the same problem could apply here.

My solution to that problem is to setup keepalive packets in the application. SSH and my VPN software do have those options. Sending a packet every 30 seconds or so (preferably configurable) does not hurt and is much better than a full TCP/TLS reconnect every two minutes.

I do suspect some ISP do that to free ports on shared IPs. Unitymedia does give a shared IPv4 address (for new contracts) and they call it DS Lite. That, of course, means all ports on that IP are shared as well and need to be routed correctly. At some point they actively close TCP connections that are inactive, because they want to free ports. I suspect mobile providers to do the very same, because phones often share a single IPv4 as well.

Just a little heads up, as I haven't known this existed before I was a customer of Unitymedia.

[lgrahl]

Although I can confirm that Unitymedia has some really wonky connection handling, this isn't a concern with WebRTC. There will be lots of keep-alive packets in the background, don't you worry. And most of the time you will not even leave your local network, so it can't be an issue with Unitymedia. What we see is more likely a bug in libjingle's data channel code and/or Android freeing up resources. Probably both.

[lgrahl]

@theZorro266 You can improve the situation by keeping a charger on your phone and having the Threema app active (the screen can be turned off). This significantly reduces the amount of connection losses for me.

[nilsrie]

Version 1.1.0 made it a lot better, but I am still losing the connection all the time :(

[ontheair81]

Can confirm this, version 1.1.0 made it a lot better on local networks. There are still connection losses (about every ten minutes), but no need to type in the password again and again. But when on different networks, the connection drops often completely and I need to type in the password around 7 to 10 times per hour.

@lgrahl Thanks for the hint with having the Threema app active. This improves things a bit.

[bziemons]

@lgrahl thanks for the information. I tested your suggestion and it does help quite a bit. It also got better generally since around I posted this.

I would keep this issue open for a reminder of disconnects still happening. I might also be able to debug on my side, but I just did not have the time yet. If the devs feel like they should close this issue that's fine with me as well.

[ontheair81]

Its true that things are better now, but reconnects are still there - around 2-3 times per 15 minutes. Sometimes the password needs to be entered again, sometimes its just the orange bar, saying "reconnecting" (which also means that not-yet-sent messages need to be typed again). So things are better now, but not yet in a condition for regular use. I would suggest to keep this issue open.

[ontheair81]

Unitymedia does give a shared IPv4 address (for new contracts) and they call it DS Lite. That, of course, means all ports on that IP are shared as well and need to be routed correctly. At some point they actively close TCP connections that are inactive, because they want to free ports.

Just to mention, I also have this problem on "real" IPv4-connections on the webclient-side (no DSlite, not shared). And there is still the issue with a lot of disconnects / reconnects. Of course, I dont know exactly the situation on the mobile-side.

And most of the time you will not even leave your local network, so it can't be an issue with Unitymedia.

At least for me this is not true. When using Threema Web in the office, there are different networks (and even different ISPs) for the (company-)computers and for the personal / BYOD mobile devices. I think this is the normal situation in most companies, as they will not allow BYOD / personal devices in the internal company network.

But anyway, this is an issue which is really annoying. I am not a programmer, but if I can do something (provide informations or anything else), I really would be happy to help!

[lgrahl]

To all: I still don't believe this is a connectivity problem. There's a lot of keep-alive stuff running in the background (actually it's too much but that's another matter and not Threema's fault). It can either be that the App is being suspended or there's a bug in the implementation (WebRTC stack or the app).

@dbrgn: IIRC there was definitely a bug with improper data channel states. I'd have to crawl through our chat log though... Anyway, can you debug this and check whether this happens due to the app being suspended/killed? As far as I can remember, this wasn't an issue for the prototype... but the prototype acquired a wake lock. If this is the reason for the connectivity issues, I'd recommend adding an option to acquire a wake lock for the web client.

[dbrgn]

@lgrahl we still have the wakelock, there's no way around that. I don't really know why the connection fails so often, it also depends on the network (in one of the networks that I often use I have very stable connections, while the other fails every few minutes).

Maybe you could find out something with Wireshark? You're more familiar with the internal WebRTC connection handling.

[dbrgn]

Also note that if the connection fails, we cannot exchange ICE candidates anymore since our signaling channel is gone too. In many applications exchanging new ICE candidates would allow the application to reconnect transparently, while we have to do the entire handshake again. Maybe there's a bug that doesn't affect most applications in a bad way because they don't notice if it automatically reconnects on the ICE level.

[lgrahl]

Oh, fair enough, if there's a wake lock then this must be some kind of bug. My network should be stable enough but there are still plenty of reconnects. Can you check our chat log? I'm pretty sure there was some issue with the peer connection being detected as 'disconnected' but the channel was 'open' and everything worked just fine. I believe you opened an issue on Google's bug tracker for that. Let's make sure we work around this first and then look further.

In many applications exchanging new ICE candidates would allow the application to reconnect transparently

I don't think so. They face the same issues as we do. If the peer connection is gone, the signalling connection is gone as well as this 99% of the time means that internet is unavailable. But yes, the signalling procedure including the flaky push wakeup takes some time.

[dbrgn]

If the peer connection is gone, the signalling connection is gone as well as this 99% of the time means that internet is unavailable.

Only if the reason for the connection loss really is a network connection loss. But in the case of a data channel bug, a WebSocket based signalling channel would still be open.

[fichtennadel]

There's a lot of keep-alive stuff running in the background [...] It can either be that the App is being suspended or [...]

Android regularly suspends Threema on my phone: it's enough to change to another app and then forgetting to bring Threema in the foreground again. The connection is lost then.

What about showing a permanent notification on the phone to prevent this? Others apps take this approach, for example Tasker. This permanent notification can then be used to switch to Threema and disable/change Threema Web.

[rugk]

A permanent notification is already shown when you set a passphrase. So maybe use this as a workaround…

But a notification for "Threema Web" is also on the TODO list AFAIK…

[ontheair81]

I am not so sure if this helps in this case, but I noticed this:

Threema was never suspended by Android on my phone (stock ROM 6.0.1). I just ticked the flag for "no battery optimization on this app" and all was fine. But: Threema Web was loosing connection every 3 to 5 minutes (sometimes even more often). And also the automatic backups function was never working.

As this device was abandoned by the manufacturer (no Android updates anymore) I decided to install LineageOS, based on Android 7.1.2 with most current security patches. And since then I rarely have connection loss in Threema Web. Also the automatic backup function is working every night when the phone is charged.

So, for me it looks like connection loss is not so much a problem of the app itself, but also depends highly on the version of Android or its implementation by the manufacturer. Maybe there could be a way to make the app more robust against "not so good implementations" of Android of some manufacturers.

Again, Im not sure if this information is useful - I am not an Android developer - just wanted to share what I experienced.

[dbrgn]

@ontheair81 what OS by what manufacturer did you use previously?

Yes, there are a lot of implementation details on Android that affect things like connection loss, automatic backups, push notifications, etc. The more "battery optimized" a system is, the more options you have to consider that might affect connectivity. Especially on devices from Xiaomi, Huawei and newer Samsung.

Following the FAQ for resolving push notification problems may also improve the connectivity situation for Threema Web.

[ontheair81]

@ontheair81 what OS by what manufacturer did you use previously?

I am using OnePlus X. Previously with stock ROM OxygenOS 3.1.4 based on Android 6.0.1. Now I am using LineageOS 14.1-20170921 based on Android 7.1.2 on the same device.

The new OS solved most of the problems for me. This is not a solution, of course, as most users will never install a custom ROM.

[rugk]

I just ticked the flag for "no battery optimization on this app" and all was fine.

Note that Android still suspends apps with this setting. When they use too much RAM and RAM is needed for another app, or similar.

[ontheair81]

Of course! This could be a problem for devices with less RAM or for users with a lot of active apps in the background, or, or, or... Just wanted to say, that at least for me this was never a problem - in my specific usage scenario. And I am not sure if this is true, but: If Threema is running in the background for the web client, Android should not suspend it - because it is active and not idling. But maybe this also depends on the implementation of the Android version, I guess.

[rugk]

Android should not suspend it - because it is active and not idling.

The point is: should…

[EugenMayer]

@ontheair81 using a oneplus X myself, had oxygen ( horrible with threema ) not pure android 7.1.2 . Threema is still horrible and more or less it becomes such a bad experience that i will consider just switching away from threema after 3 years.

Threema was one of the last throwing in a web-application finally so i would have expected, they really designed it well. But they completely missed the whole point. The web app has the same experience as doing smartphone device mirror on your PC/MAC. You have to get your smarthphone, get it next to you and have it up and listening to get it working properly.

It completely missed the whole point and its more PITA then rather having none. It would have been better never releasing it in the first place.

Next thing they will introduce is, that you will only able to use your threema account one the device, when you have connected a dongle using USB - and your face is recognised and no 3G is used - and you have to keep you finger on the fingerprint sensor all the time. Your smartphone must have a 12 chars password, otherwise you cannot instal threema and only encrypted devices only. And you will only be able to chat 1 day with a red person, then you have to scan him, 2 days with orange.

Yes i can up with a lot more ideas to make it even more secure .. but that does not make it any better.

And when you done with that Threema, you can chat, with all the comfort, with the 5 people left in the network.

Security is a mix of convenience vs risk vs security. And you did not get it. Threema is more protected then a usual access to bank accounts. Great having a secure messenger but please god let people decide how you tight they want it to be.

You are not dealing with military based conversation channels once and for all.

[bziemons]

@EugenMayer keep your opinion to yourself - this issue was not created to dump such bs. You are not even keeping it factual.

[EugenMayer]

You mean i should have started with the point, that what threema has chosen to implement is completely against androids design principals and google is going to shut down those things wherever they can.

You can create activities as background services with proper hibernation/dehydration as much as you want - but google is dealing with that for a far longer time. That means they stopped apps exploiting the background services for non-stop engagement, they mesure activity in CPU cycles and network activity and will simply not cal you app even if they should be calling it, when its off the grid.

Thats why you have to activate the "non battery optimized" nonsense in the first place, so you have a bit softer rules - but that does not mean they remove all the rules. thats why you activate notification mode since that will force to wakeup the service in cycles.

So all we are dealing here with is not technical details, its hide and seek. The technical reasons are obvious. Android has a strict ruleset on when to hibernate ( even backrgound services ) AND even shutdown them, if anything else in the foreground is needing more resources. So yes, RAM is a huge factor, since if to many hibernated apps are running or someone with a number of background services is using threema web, it will fail, since the background services will be killed when the frontend cycles need more or just its too much overall.

Its not working, because its a horrible design in the first place. It has been limited more and more in Android, and will be limited more in the future. Devices get better specs, but Android applies harder rules on background service.

So yes, my rand above was sarcasm - but there is much more background to that. Threema has chosen to implement their web-service upon an exploiting factor.. have a joy fixing that.

[fichtennadel]

Despite I do not agree on the harsh style and exaggerated statements from @EugenMayer, there is some truth in it, at least from my point of view, so back on topic:

I also think that the decision to require a permanent network connection collides with the efforts of Android (and iOS) to consume less power and these "lost connection" incidents will never go away. All efforts to reconnect and keep the app active are just band-aid and no cure.

And although I really do like Threema Web a lot, I think its basic architecture is flawed, multi device would have been the road to go to avoid all these issues. The idea of using WebRTC was for sure alluring and technically interesting, but from the point of view of stability and user experience it was wrongheaded.

[rugk]

You maybe want to have a look on https://github.com/blizzard4591/openMittsu/.

But as for the web client, that's just how the system works. (And that also applies to any other webclient, whcih requires the phone, i.e. WhatsApp's one) It needs connection to the phone as a relay. For a standalone version you may use a VM on the desktop or openMittsu linked above.

[dbrgn]

There are some plans to transfer "early data" over the WebWocket based signalling channel even before the WebRTC connection is open. Also, @lgrahl has some early ideas how to reduce the signaling round-trips in a future SaltyRTC protocol version. Those changes would probably make reconnects a non-issue. It will require some updates to the SaltyRTC signaling protocol though.

We are aware of the tradeoffs. With multi-device, people would still want their conversations synchronized across all devices. That leads to architecture decisions like storing all conversations on the server. We don't want your data, not even in encrypted form. 🙂

(And yes, data could also be synced between devices. That leads to a host of other problems once you start to think it through. I'm pretty sure it would make usability much worse.)

[fichtennadel]

With multi-device, people would still want their conversations synchronized across all devices.

At least for me only up from the point in time when a new device joins. For me there's no need to propagate old messages to new devices.

That leads to architecture decisions like storing all conversations on the server. We don't want your data, not even in encrypted form.

You are already "holding" (to avoid the term "storing") the message in transit until it is delivered, do I get this right? Multi device would multiply these in transit messages up to given maximum of devices per ID, no need to store "all" messages.

[EugenMayer]

@fichtennadel the point is, sometimes somebody has take the mirror and point at the reality. And this can feel harsh - and i did it a harsh way, admitted. At some point a wake up call can be required though.

This issues is dated back to the 18. Mai and people do create new, and new philosophical reasons why this is the case and how this can be fixed in the future.

Might, should, could it be that that or this or maybe that.

While the developers of Threema already know, maybe from the start, that this is absolutely unavoidable giving the current architecture - but simply not telling it out how it is. More, they remain silent and sell it as the best, most secure thing of all messengers.

I am a Threema users from the first days, even on my Blackberry with pull notifications i was part of this. So its not like i am raging about something i did and do not value or know - its more i rant about this fooling.

So even if @theZorro266 is offended by my bs, i must admit, i just joined the same level of bs inside this issue already - i openly admit, it was offending and sarcastic - by design. Because without stomping on the ground sometimes just continue with the "alternative, most comfortable reality".

i mean, we are dealing with a scenario where Threema decided that a mobile device could be used as a plain dedicated server - always online, always available and always powered. Yes sure, just exactly what a mobile device has build for, right? Without your mobile device not doing exactly that, Threema Web is not working.

Lets ask Android or iOS developers how they think about that and how harsh they are trying to protect the user from those kind of things - just for protect their own business. "Android is so bad, battery lasts just half the day", "iOS..." - you cannot tell the user over and over again, that some apps they have installed are causing this .... OR you write guides like "how to build an app with battery usage in mind" for the developers.

They stopped to create those guides because of the very developer created this very interesting WebRTC app - people do not listen - they do not care. They rather exploit and sell it as the "new level architecture nobody has yet build" ( out of good reasons). So all we have here is a race against Android closing the doors for exploits like this - and they will.

So just step back and finally look at alternative. You do not want encrypted messages on your servers from the users? Or you noble ones - yes because you do not want to provide the infrastructure for that. Its not like we need to sync the conversations form "10 months ago" - 15 days would be enough. So you selling this because of the noble privacy protection reasons - which they arent.

IF we are talking about end to end encryption, you should not care. Why you even then transfer the messages through your server in the first place and not use P2P? Ah yes, its not practical.

So why in the world you build a messenger where you do not want to play the proxy for messengers for your users? Why would even ever consider this as a possible route to take.

So stop complaining about unavoidable things like this message histories to block obvious, reasonable technologies to be deployed to deal with this Web-App scenario the very same way you deal with it on the mobile device.

You think browsers are less secure then mobile devices? Why you do not let the user decide that - the one doing their banking with the browser, doing half of the business with the browser already - but cannot send private messages with exactly that technology.

I am all in for privacy protection - but please, keep it practical for a messenger app. You are not protecting nuklear codes. Or in the end we have the most secure messenger app in the world - but nobody to chat with inside.

[rugk]

1. How does WhatsApp handle this? Don't they have the same problem? Do you have any experience?
2. Maybe what you'd like is something, which has already been proposed in the forum: Having Threema on a RasberryPi (or similar) and connecting from all other devices (WebClient-like) to it.

IF we are talking about end to end encryption, you should not care.

I disagree. Threema has no Forward Secrecy on the e2e encryption level, i.e. when messages may be seized and one then gets the private key from one of the devices, one can decrypt the data, even if it is really old.

Why you even then transfer the messages through your server in the first place and not use P2P?

Metadata. Same as with VoIP now implemented, you leak your IP address to conversation partners.

Why you do not let the user decide that - the one doing their banking with the browser, doing half of the business with the browser already - but cannot send private messages with exactly that technology.

They do. I mean you have the web client: Use it or do not use it. Your decision. However, Threema should stay to it's vision, which basically is "security by default". You must not* let users do insecure things. (e.g. they could also offer a switch to disable e2e crypto, but nobody would appreciate this)

I am all in for privacy protection - but please, keep it practical for a messenger app. You are not protecting nuklear codes.

Strictly speaking what you transmit must not matter. If you use a special "supersecure device" for nuclear code transmission, anybody will see you just transmitted nuclear codes and prepare counterattacks. That's not useful… The whole point of privacy is that it should not matter what you transmit. Nobody should know. And you should not sacrifice security for convenience. That is hard, but Threema does a good job with it. So just you know: I can name you several things, why I would not use Threema for nuclear codes, that's again just pretty exaggerating what you do here. Threema has it's flaws/disadvantages, too. (open source, just to name one) There is nothing as "the most secure messenger app in the world".

but nobody to chat with inside.

Now that's certainly not a problem of the Web Client.… nor a problem, which would be solved by a different desktop client.

[EugenMayer]

Yeah, i totally admit. There are gazzilion of other systems which are still secure when you get the private key? Or none. If i get the private key i can read all your traffic anyway, why hacking the server? And beside that, i obviously have the phone (since i extracted the private key) - and if i have the phone, i do not need to fetch the messages from the server, i have them right in my hands - all of them.

beside that, i asked to save the history of the e.b. last 15 days since the last message transmitted.

What you describe can be done anytime, by listening the line and catching the message ( encrypted ) and then later, when i get the private key - what an unsensible thing - i can decrypt them. No need of a server hack, still.

P2P was sarcasm, its not practical in so many ways, pick Skype and its habbits. But there are many more.

The whole point of security is that if you make it completely inconvenient for the normal user, they do not use it at all, thus go without privacy at all. It must be practical so we can convince a broad mass to use a very secure client.

I was pulling so many people into Threema and i see them leaving, one by one. Going to more convenient solutions. Missing multi-device is one of those, they have phones and tablets (which they can type better one..surprise ) you need to do a backflip with threema to get this working, way to impractical.

A missing web-client is one too for those people, technicians, who "fight for threema" in the "people not caring about privacy" world, ppl convincing those and people trusted by them to have a good understanding of what is reasonable or not. And those people, all of you, use the web client due to having better keyboard and most probably due to having the smartphone as it is, the better tool on the road, but not thus at home. If you lose those, you lose the multipliers in a chat client which is nothing more then a tiny tiny network which does not drag people into it because "those people have threema" .. that hardly ever happens in this still very small user base.

[dbrgn]

Please stay on-topic and do not discuss the app design here. There are other places for general discussion, like the Threema Forum or Reddit (both of them inofficial). And if you have feedback or questions about the app itself, contact our support team.

Just some small notes about your comments.

15 days would be enough

If we'd just offer synchronization of the last 15 days, lots of people would complain about the conversations being incomplete. It might be enough for you, but not for others.

by listening the line and catching the message ( encrypted ) and then later, when i get the private key - what an unsensible thing - i can decrypt them

We provide forward secrecy on the transport channel. If you record messages on the network and would be able to crack an encryption key (and if you do, congrats, you should publish a paper), you have the encrypted messages for that session. Not all of them. Next, you'll need the private key of the recipient to actually get the message contents.

We try hard to provide a good user experience without compromising privacy, and all that with an independent, self-funded business model. If you wish to trade some privacy and some metadata about your communication patterns for more convenience (like always-in-sync multi-device support), then by all means, there are apps that offer just that.

We are open for constructive feedback. And now please get back to topic, I don't like locking threads.

[lgrahl]

I have already stated in another issue that we haven't even scratched the surface when it comes to optimising this application. With the biggest thing probably being that the permanent background connection is not necessary.

Trust me, I'm feeling the urge to respond to your rant in detail but honestly, I don't think it will go anywhere.

[ontheair81]

I dont want to add fuel to the flames, but I think @rugk asked a very interesting question:

How does WhatsApp handle this? Don't they have the same problem? Do you have any experience?

I dont use WhatsApp anymore, but I see this everyday at work in the office: Some of my colleagues connect the WhatsApp webclient as soon they arrive at work in the morning and they disconnect it in the evening. In the meantime they dont have any (visible / noticeable) connection losses. No matter if they use a 800-Euro-Samsung or a 60-Euro-ZTE-Blade-L110 (not joking!). Client and mobile device in different networks. So it looks like WhatsApp found a way to handle different implementations of Android very well, regardless of their specific limitations.

With the biggest thing probably being that the permanent background connection is not necessary.

Sounds like this could be the key for satisfied user experience, yes! I tested this with the colleague at the very cheap ZTE phone: Disconneting the network functionality for 30 seconds on the phone. There was no visible connection loss in the WhatsApp webclient. And it was immediately working again when the phone goes back to online.

From my simple user-point-of-view I would love to have the same experience with the Threema webclient. And maybe getting rid of the need of permanent background connection could solve most of the problems, as @lgrahl said.

[rugk]

I think WhatsApp may use some kind of GCM push messages again, even for the web client… That's the only thing I can imagine.

[fichtennadel]

With the biggest thing probably being that the permanent background connection is not necessary.

That's the key.

In the current implementation it's unfortunately not suitable for daily use by a broader audience: mobile and PC are in different networks (company VPN / WLAN): prone to connection losses; app gets suspended by Android: connection losses; reconnect is unreliable and a lost connection is not notified in web: your are "offline" without even noticing it.

That's the sad state of affairs and the reason why I currently don't recommend Threema to my friends anymore, who don't have the patience of us IT guys to cope with these hurdles.

I'm currently on "the other swiss secure messenger" for daily use and check the state of Threema every week and hope for the best to return.

[rugk]

Hmm, which other Swiss messenger? If you mean Wire, they host their servers all over Europe.

Also I don't really understand why you don't recommend Threema? Did you recommend it before the web client was introduced? My point is: Threema is perfectly usable without a web client. That's just an additional feature.

[fichtennadel]

Also I don't really understand why you don't recommend Threema?

I do recommend it for mobile-only, definitely.

But most people I communicate with ask for a "desktop/browser version" (read "use my real keyboard when I'm in the office"), and this is where Threema unfortunately is not yet where it could be. But I really do hope it will get there, we "just" have to get rid of this permanent connection requirement, which causes these instability (and battery) issues.

(yes, Wire)

[ranguwud]

I would like to back up the opinion of @fichtennadel. I can confirm that the unreliable Threema Web connection acts as a show stopper for the whole app for some people. Using a proper keyboard to type when you are at your computer is just so handy that friends of mine eventually stopped using Threema and now we are back at WhatsApp. Fixing this issue would contribute greatly to the user experience.

[fichtennadel]

I thought I'll try again with the new version of Threema Web: still not reliable.

Four connection losses in 6 hours, two of them with failed reconnects, no notification in browser, so I have been "offline" without even noticing it. Phone was connected to charger, Threema last opened app, Wifi.

This bug is now open for 7 months without any progress, is there anyone working on this or are we just wasting our time reporting bugs here?

[dbrgn]

The next app release will contain a change that might improve the failed reconnect situation. What may happen right now, is that the connection is lost temporarily (this can happen due to many different reasons), so a reconnect push is sent from the browser to the app. Depending on the ROM installed, it might take a few seconds until the phone notices that the connection is gone. If the push arrives when the phone still thinks it's connected, the wakeup is cached for 10 seconds. On some phones these 10 seconds were not enough, resulting in the phone not reacting to a wakeup request. We increased that timeout and hope that it will result in less failed reconnection attempts.

[rugk]

Can't the app just notice the connection failed by itself? And just try to reconnect? Only if the connection is properly closed, you may not trigger that.

[fichtennadel]

I don't get why you still insist on this error prone permanent connection. A mobile phone is not a server.

Mobile OSes will give you a hard time on your current approach and it will get harder. My Samsung even warned me about Threemas battery drain after just 10 minutes, and that's the only app I ever saw this warning for. There's obviously something wrong with your design.

@lgrahl already said:

I have already stated in another issue that we haven't even scratched the surface when it comes to optimising this application. With the biggest thing probably being that the permanent background connection is not necessary.

I've been using XMPP/Jabber for years on Android with yax.im, it worked flawlessy, didn't drain nearly as much battery as Threema, didn't use GCM and was "permanently connected". I don't know how they did it, but it was much more stable than Threema's permanent connection.

Why don't you change your architecture to either multi device or something event based and connect only when required?

[lgrahl]

There are also a lot of people using Microsoft's Edge

Come on... really? First of all, I don't believe Edge has a big market share. And secondly, just use Firefox. Edge will eventually jump onto the data channel train, too.

Nevertheless, @dbrgn and I have discussed an idea how this can be solved some time ago.

[dbrgn]

Currently we prefer to work on bringing users of other mobile operating systems to Threema Web, not users of the Edge browser. And that takes some time. Once we got there, we can work on making the entire system faster and more robust.

[ovalseven8]

Oh, I have removed my post immediately, seems like you saw it directly after I clicked the "Comment" button. :smile:

I hate those statements like "Just use Firefox" or "Then use X or Y". It does not solve the problem. Personally, I use Firefox, but it does not say anything about others. I know a lot of people who use Edge because it's pre-installed on Windows and a lot of people who don't like to deal with the computer just use the pre-installed software in general. If other messengers work and Threema does not, it's clear why they use WhatsApp & Co.

And it's nice to have an idea how some issues could be solved in future, it just does not matter at the moment. Do you believe users like to wait years until such "basic" things are solved? Threema Web has been deployed almost a year ago soon, and we still don't have Threema Web for iOS. Yes, I know, it is being worked on. I just want to make clear it DOES NOT MATTER when it does not work for the user - I can understand those, can't you?

[lgrahl]

You can bring this argument every single time to every single issue: "The user wants it to just work, so you'll have to deliver!"

Whereas what I see is this: Most people aren't fundamentally unwilling to install some piece of software if you explain to them why it's required (and what other advantages it may have).

Edit: It's not that we cannot support Microsoft Edge. It's just that this will take a lot of work hours. And until then this is the way to go.

[fichtennadel]

So, almost one year later and still no progress.

I stopped using Threema months ago because of this and the battery drain issue, but check back here regularly to see if the usability and architecture changed for the better and Threema Web might finally leave its beta phase and start being usable like Wire Web or WhatsApp Web. Unfortunately, it's not.

[ovalseven8]

@fichtennadel: Well, I am also not happy with the current state. However, I hope Threema can focus on improving things again once Threema Web for iOS is released. At the moment, they do heavy work on the iOS release.

[ontheair81]

@fichtennadel: Some weeks before there was an update of the app. Since then everythings works really fine for me, not a single disconnect since then. Maybe you did not noticed it as you stopped using Threema months ago. Maybe you want to give it a try again.

Sure, there is a still a lot of work to do in Threema Web: Most recent emojis are not synced, hidden chats can not be used, ballot message are not working. And of course missing features in the app such as invitation links, video chat, pinned and not just marked messages and so on...

But, of course, thats not the topic of this thread. Regarding to disconnects: That works perfect now, at least for me. And it consumes not much battery.

[rugk]

Hmm, recently I've often experienced these problems, where the connection in the app then shows a red "!". I cannot re-connect there, or so, I can only delete the entry and re-add the connection.