status-im
Group chat disappeared but notifications still came in
Bug Report
Description
Very weird bug that happened to me and Rick.
I opened the app and everything looked normal, but then I started seeing notifications come in for new messages (both OS and ephemeral depending on the focus state of the app), but none of my channel or communities showed the badge for new messages. I checked my muted channels just in case, and it wasn't that either.
Turns out, one of my private group chats just disappeared from the list. I could not see it at all, but I could still receive the messages and notifications. So the signals from status-go worked.
This means the issue is either in Nim or QML.
Closing and reopening didn't fix it.
We could fix it by kicking me out of the group and re-adding me. Then I could see the group and even the old messages.
Steps to reproduce
No idea. It happened seemingly randomly
Additional Information
- Status desktop version: 0.8.1
- Operating System: Ubuntu 20
Moving to 0.10, because it needs a bigger change, since it's related to the way our group chats behave. Since we auto accept group chats from mutal contacts, but NOT from non-mutual contacts, if the person that propagates the chat is a non-contact, it will not be set as active. To fix this, we'll probably show it in the AC as is done on mobile. We'll get designs in January.
Part of this has been fixed here https://github.com/status-im/status-go/pull/3037 With the above PR, if you still have your contacts intact or partially, the group chat should reappear, because we check if the owner is a mutual contact. We still need the activity center notifications for the case where your contacts are gone though.
@MishkaRogachev for this task, what we need is a AC notification that says that we have been added to a group but the owner is not our contact.
The user is not our contact usually because we re-synced our app and we lost our contacts, but we still receive the chat when someone chats in it. It could also happen if someone tries to spam us, but the AC would still act as a blocker.
Clicking Accept (checkmark) adds the group chat to our chats. Clicking Dismiss (X) removes the AC notification and the chat stays hidden and we also don't setup filters for it.
I studied how group chats used to work and why we decided to automatically add to group chats. The thing is that if we allow the possibility to join a group chat by invitation from a non-mutual contact, then such a chat will simply not work.
However, there is a problem if we create an account with a public key that is already in a group chat or if we synchronize a new device: the invitation may come before we add (or synchronize) the necessary contact.
What can be done? Add such a contact not explicitly or vice versa, when adding a contact additionally request groups where the current user and the contact - the admin of this group are present.
@osmaczko @iurimatias
However, there is a problem if we create an account with a public key that is already in a group chat or if we synchronize a new device: the invitation may come before we add (or synchronize) the necessary contact.
If we synchronize a new device or restore from backup, shouldn't we simply trust it and recreate group chat regardless if invitation was from not yet synchronized contact?
If we synchronize a new device or restore from backup, shouldn't we simply trust it and recreate group chat regardless if invitation was from not yet synchronized contact?
it might work, but it only solves one case out of two.
UPD: the possibility to create a new account based on the same seed phrase is a hack, which is not quite clear how to prohibit. Using this approach is fraught with a number of problems and is not directly related to this task.
Here we need to make the following fix: do not check a contact when restoring a group chat from backup
Сurrent status:
Group chats are restored normally on successful restore from backup or synchronization. We don't use the function we suspected when restoring, but use this one and i can confirm that it works well.
There is still a problem if the restore is not successful, but in this case the whole application is barely working and as far as we can't prohibit users from doing that we need to analyse/discuss how to minimise the damage.
It seems like this issue is mostly fixed.
However, I think there is still one scenario that would cause the problem:
A user re-imports their account and somehow nothing gets fetched, for whatever reason (no store nodes, account is too old, user selected the wrong option ie I am new to Status).
Then, they won't have their contacts and if they were in a group chat with other users, the group chat will not appear when a new message is sent, because it doesn't come from mutual contact.
Maybe it just doesn't show and it looks normal, but back when the issue happened to me, I would still receive a notification, which was super confusing.
So @MishkaRogachev , can you test if that scenario still happens?
If so, what we need to do is show the group "invite" in the AC when we receive that message. That way, the user can know that they received something and rejoin. Then they'll be able to re-add the others as contacts for example.
We need the AC and not just auto-join, because we want to mitigate spam.
A user re-imports their account and somehow nothing gets fetched, for whatever reason (no store nodes, account is too old, user selected the wrong option ie I am new to Status).
@jrainville yes, in this scenario it may happen i have already reproduced it. But this problem is the tip of the iceberg, if recovery is not successful not only group chats and contact requests (and I suspect many other things with shared state) are not working correctly.
And I checked with @saledjenic, there is no technical way to limit this right now.
Here I think we need to decide, if the application should function normally under this scenario, it is worth changing many flows
if recovery is not successful not only group chats and contact requests (and I suspect many other things with shared state) are not working correctly.
In theory, the account is still a functioning account after an import with no fetched back up. Of course, you'll need to re-add people to your contacts and rejoin communities, but I wouldn't say the account is broken beyond repair.
This scenario I outlined is one that can happen and is very bad. First, it's confusing, but also it completely blocks the use of that group chat. The only way to fix it right now from a user's perspective is to add back the people in the group chat, then get kicked from the group and re-added. This is not something that's intuitive.
So having the AC notification about the group is the best way to manage this. It also aligns with mobile (at lest they had that last year).
Here I think we need to decide, if the application should function normally under this scenario, it is worth changing many flows
Yes, we want to support an account recovered with no backups. And no, we don't need to change many flows, just the one with the AC notification for a new group chat received form a non-contact.
@xAlisher we do not have an existing notification that we were added to the group from an unknown contact Could you please provide a design for such a notification Here's how it looks like on mobile
