Wire-webapp: Feature request: Implement a "Seen" marker in addition to "Sent" and "Delivered"

[maximbaz]

I would like to know which of my messages were seen by a receiving party.

I can see in the code that this information is already available in StatusType.coffee, and it only has to be consumed by the UI similarly to #281.

My questions to you are:

• Was it a deliberate decision not to show this information, or rather just a lack of time to do it?
• Would you accept a pull request that adds this functionality?

I can easily understand that some people would like to hide that they have seen the messages. For this Viber has a nice concept: a user can only see whether others have read his message if and only if he allowed to share his own status with them.
However, this idea requires adapting the server-side and adding an extra configuration, and I'm not really for this option due to lack of time and lots of more important feature requests that are on your plate.

But I would like to have the basic "Seen" marker, not configurable and available for everyone, and you have my offer to provide a pull request for it.

/cc @gregor @herrmannplatz

[gregor]

Not adding a seen/read message feature is mostly a deliberate decision at this time. Sharing this information on the recipients state of the message is leaking privacy relevant information. This could only be done in an opt-in manner in order to align with what Wire stands for.

We have been thinking about it but there is just no way to do that currently and provide a user experience that ads enough value as we suspect most users would not turn on the feature. In addition a feature like this should be roled out across platforms in sync to work. Because of this we most likely would not accept a PR for this at this time. But we have defintely had discsussion about this functionality internally and will re-evaluate in the future based on user feedback like yours.

[maximbaz]

I understand, ok, thanks!

[maximbaz]

Out of curiosity I had a closer look at this anyway (thought I might enable this feature only for myself :stuck_out_tongue_winking_eye:), but my assumption that this is a purely UI change proved to be wrong :blush:.

Which is good from the privacy perspective, but it means that a pull request even hypothetically cannot be provided without having access to the server code.

[gregor]

You will not need to touch server components for a feature like this. Just make use of the addtional flag our cross-client protobuf already provides and send a correct message to the correct recipients. Just check the z.conversation.ConversationRepository.send_confirmation. A message like this you will only want to send to all the devices of the sender.

Another reason we only have delivery receipts in one-to-one conversations is pure math. If you send one message in a maxed out group conversation this would result in up to 128 * 8 - 1 = 1023 receiving clients answering with a confirmation to each of your clients. A single sent message can thereby result in up to 8184 message that will have to be decrypted somewhere. In a 1to1 conversation this number goes down to 2 * 8 - 1 = 15 confirming clients that send 8 messages each -> 120 messages to decrypt. If you add a confirmation for read those numbers double. There are some optimization to decrease the numbers not much.

[maximbaz]

I see, so as I understood, if I hypothetically speaking wanted to add "delivered" markers for me and my friends, I would have needed not only to change my client to receive "SEEN" marker and draw it in the UI, but also to build custom clients for all my friends that would _send_ this marker along with the messages to my client. Server component is not touched, but the senders' clients have to be adapted.

Speaking of math, you are bringing up a very interesting point, thanks! I haven't considered at all the increasing load on the clients. It makes perfect sense to want to reduce the amount of encryption/decryption on the devices.

I think you named very valid reasons why this feature is not implemented, and while the team would probably re-evaluate it at some point, I'm fine with closing this github issue for the moment, unless you want to keep it open for tracking purposes. Up to you.

[Sopsy]

I'd say no thanks to this. If you are going to add it anyways, please at least make it possible to opt-out from it.

[someoneEsle]

I'd say yes to this feature, implemented in an opt-in fashion. As for the users "never turning it on" because they don't know they have such option, I see two solutions:

• (not a fan of this one) use one of those ad-looking messages within the app (phone clients) to advertise the new feature;
• (more preferably) add a small "NEW" red label to the settings so as to guide the users to discover the new function. If they like it, they'll turn it on. If they don't, they'll ignore it.

[bennycode]

As you can see there are very different thoughts on this topic. So we will stay with the implementation which we currently have in place (meaning no "seen" marker).

[TomSteinberg]

This feature is absolutely key to me, and I suspect that a long term decision to permanently exclude it will but a fundamental limit on Wire's growth. Please, please reconsider, if only for your own future success.