synchronize user-caused chat state changes across devices

[link2xt]

Various user-actions are not synchronized across devices. For example, you need to accept/block contacts on each device.
There is already some logic to synchronize QR-codes, hidden behind SendSyncMsgs config. It was added in PR #2669. The plan is to extend it to synchronize the following user actions accross devices:

• [x] 1:1 chat status (blocked/contact request/accepted)
• [x] archived/pinned status of chats
• [x] mute-status of chats

Recursion needs to be safely prevented for all syncs, e.g. that an arriving sync message changing chat state causes a "back" sync message.

[iequidoo]

As for archiving, pinning and muting chats, i'd add "device groups" to allow devices to have different settings. By default a device belongs to a group "default", but it can be changed in the settings. If we don't want more settings right now, we can at least add this to the synchronisation protocol. Different devices may be used for different purposes, f.e. i could mute "work" chats on my phone and so on

[hpk42]

On Thu, Oct 12, 2023 at 19:10 -0700, iequidoo wrote:

As for archiving, pinning and muting chats, i'd add "device groups" to allow devices to have different settings. By default a device belongs to a group "default", but it can be changed in the settings. If we don't want more settings right now, we can at least add this to the synchronisation protocol. Different devices may be used for different purposes, f.e. i could mute "work" chats on my phone and so on

No, let's please not add settings/complications to core unless there is an agreed UX/UI use for it. Adding "device groups" has ASFAIK never been discussed on forum or among the UX/UI leads so there is no need to consider this feature for the purposes of this issue.

[link2xt]

Different devices may be used for different purposes, f.e. i could mute "work" chats on my phone and so on

This might also be solved differently in the future, e.g. by having a "work" and "personal" folders that are synchronized across all devices.

[r10s]

yip, let's keep things simple for now, in the vast majority of cases, it will be just fine to synchronise contact-request/blocked/archive/mute/pin.

this is also what other messengers are doing at the first place - and it is a clear UX with clear expectations.

for sure, there will be some user that complain, this is always the case on changes 🤠 archived-in-chatlist, accounts-running-in-bg, online-indicator - there were also quite some discussions about switches and end-of-the-world-otherwise, but at the end, things calm down, also without lots of options. and with the win of ease and simplicity, plus easier maintainability

(surely, one can argue for the need of every option. and adding options is always a supposedly simple solution. however, the gist of delta chat is also to not introducing options wherever possible. introducing "device groups" at the current stage would not only make development harder, but also communication about this feature, there will be more options, more corner cases, more things that can go wrong. but also in the future, i do not have the feeling that "device group" matches the overall gist of delta chat, but let's see that then :)

[Simon-Laux]

start with 1:1 chat status (blocked/contact request/accepted) there is no question there.

archived/pinned status of chats and mute-state need to be synchronised together, if people complain that we sync them once we released a version that does, then we can think about adding settings, but no device groups, just a simple key value setting store that is also synchronised that says disable synchronisation of archived/pinned and muted state on all devices or on no devices.

[iequidoo]

As for "device groups", no new settings are needed right now, i just suggest to maybe add this to the protocol so that this functionality is possible. Of course better suggestions are welcome. And as for the settings, anyway a setting "sync chat states for this dev" is going to be added not to break the current UX. F.e. if it is set, a devgroup "default" is passed on wire, otherwise sync messages are disabled/ignored.

Anyway, i'm asking for the setting "sync chat states for this dev" because now i intentionally use this. I have (almost) all chats muted on my laptop except 1:1s and some important groups so that they don't bother me while i'm coding. On my phone i have (almost) all chats unmuted, but w/o sound/vibration, and just check notifications from time to time. But for me it's ok to have some advanced "developer-mode" setting. It could an env var on Desktop, but i'm not sure for Android. First of all, DC should be at least usable for us, then it should be convenient for users

[iequidoo]

just a simple key value setting store that is also synchronised that says disable synchronisation of archived/pinned and muted state on all devices or on no devices.

This way all devices are either synced or unsynced. A per-dev option "sync chat states for this dev" is more flexible and maybe even easier to understand (for me, not sure as for others)

[r10s]

i'm asking for the setting "sync chat states for this dev" because now i intentionally use this

let's still not do or plan that now. we are not doing this simplicity primary for us developers, having special wishes anyways :) also @hpk42 wishes a different pinning-behaviour, and i would also have quite some things differently. let's really just go for the simple thing first

i just suggest to maybe add this to the protocol so that this functionality is possible

well, iirc, the underlaying format is json, we can always add fields there and enhance functionality.

let's start getting things synced unconditionally to move on. that may already be complicated enough. all options are out of scope of this issue and the initial implementation (also as that again raises other discussions of different ways to do it already :)

if in doubt, as @Simon-Laux pointed out, start with chat-requests/accept/block that is more clear and we already get a first grip on the sync stuff.

[Simon-Laux]

just group all devices into one group, Multi-device with more that 2 devices is rare anyway and our target audience is not nerds that are willing to learn how settings work.

Anyway, i'm asking for the setting "sync chat states for this dev" because now i intentionally use this. I have (almost) all chats muted on my laptop except 1:1s and some important groups so that they don't bother me while I'm coding

we can allow toggling what should be synced and what not, I'm just against allowing multiple device groups because that is complex and not easy to put into an intuitive UI. so just one device group and every device is part of it and can neither join nor leave.

[link2xt]

There is already a setting SendSyncMsgs, this one we will expose in the UI under experimental features at first, like location streaming. If it is disabled, no sync messages are sent and received sync messages should be ignored.

Feel free to add config options like "sync chat states for this dev" toggling reception of this part of updates off, they may useful for tests and finding code parts responsible for update application with grep anyway. But they should default to "enabled" ("1") and it is not decided yet whether we want this kind of "Firefox Sync" lots-of-checkboxes UI or not:

But for me it's ok to have some advanced "developer-mode" setting.

You can then switch this option directly in SQLite database.

[iequidoo]

It's not the first time when the capability of developer-mode settings is discussed. On Desktop we actually have them -- any setting can be changed via an env var. On Android it's less convenient, one should use either SQLite cmdline or CLI client. Maybe it needs to be automated. Ok, it's off-topic, i'm glad that at least in the core we can have the necessary setting, this "sync chat states for this dev" is likely just ~10 lines of code.

UPD: I'm unsure that any synchronisation should be enabled by default as it can affect existing users. Maybe enable it only for new installations. At least it shouldn't be enabled while being an experimental feature

[iequidoo]

Done in #4843