replace field of message head

[Dragos]

Hi,

Is the replace field from pub head used(https://github.com/tinode/chat/blob/master/docs/API.md#pub)  ? I can't find anything than just some css clases in teh react app.

For my app the server stores all replace messages in the original message as edits: [] and the first edit data(content, attachments, etc) is displayed. I feel this is super wrong.

What would be a better way to do it ? I am thinking about replacing the message data(content ,attachments, etc) of the replace: seq message with the new data so when the messages are requested the edited message already has thew new data. Like a PUT request.
Is it better ? Are there better solution ?

Thank you.

[Gene]

On Thursday, December 8, 2022 at 3:04:53 PM UTC-8 Dragos wrote:

Hi,

Is the replace field from pub head used(https://github.com/tinode/chat/blob/master/docs/API.md#pub)  ? I can't find anything than just some css clases in teh react app.

It's used in the SDK.

For my app the server stores all replace messages in the original message as edits: [] and the first edit data(content, attachments, etc) is displayed. I feel this is super wrong.

We are adding the message editing feature right now. It's already present in https://github.com/tinode/webapp/tree/next

You can try it. 

 

What would be a better way to do it ? I am thinking about replacing the message data(content ,attachments, etc) of the replace: seq message with the new data so when the messages are requested the edited message already has thew new data. Like a PUT request.
Is it better ? Are there better solution ?

Just take a look at the code in next (both the app & the SDK).

 

Thank you.

[Dragos]

I see that the sandbox doesn't have the edit function active so I tried to run the next branch locally.

I can not run the next branch of the react app. It says the  "tinode-sdk": "^0.21.0-beta1", doesn't exists when I ran npm install.
Also the master branch of the Go server, windows pre build, works with the edits from the above branch ?

[Gene]

On Friday, December 9, 2022 at 7:09:11 AM UTC-8 Dragos wrote:

I see that the sandbox doesn't have the edit function active so I tried to run the next branch locally.

I can not run the next branch of the react app. It says the  "tinode-sdk": "^0.21.0-beta1", doesn't exists when I ran npm install.

 npm install won't do anything useful. Install the server, then drop 0.21.0-beta1 into 'static' folder. First see what's in there, then replace contents with the same content from 0.21.0-beta1

Also the master branch of the Go server, windows pre build, works with the edits from the above branch ?

Yes, it will work with 0.21.0-beta1. 

[Dragos]

I see that you have a list with all the messages that have head.replace, edits. When a message whose seq is found in the list, it will be replaced with the edit.
I find some problems with it
1. Privacy, users can see the content of the old message in the network tab of dev tools. This problem is present in my solution too.
2. If I send a message, seq = 1. Then send 24 edits, seqs from 2 to 24. Then send one more message, seq 25. Considering the app request 24 messages I will not get the first message and considering that these are the first messages there is no scroll top action that will request older messages. The only way to get the first message is to make my window small enought so I can have a scrollbar.  Didn't tried but something similar might happen to replies.

Considering these problems from above, why not just PUT/PATCH the message data: content and attachments ?  Would't it be both simpler and easier to just change the data of the original mesasge and not keep the head.replace message around ? I could give it a try if you point me where to look in the code.

Also I found another bug, if you edit a reply it will brake it's styles and it would look like a normal message.

[Gene]

On Friday, December 9, 2022 at 1:09:35 PM UTC-8 Dragos wrote:

I see that you have a list with all the messages that have head.replace, edits. When a message whose seq is found in the list, it will be replaced with the edit.
I find some problems with it
1. Privacy, users can see the content of the old message in the network tab of dev tools. This problem is present in my solution too.

I disagree on privacy. Once the server delivers the message to the client, it's up to the client to decide what to do with it. Users can see what the client shows them. The current clients keep the older versions of the message but don't show them to the user. If you don't want to keep the old version, you can delete it in your client. Some applications may want to keep or even show edit history. 

 

2. If I send a message, seq = 1. Then send 24 edits, seqs from 2 to 24. Then send one more message, seq 25. Considering the app request 24 messages I will not get the first message and considering that these are the first messages there is no scroll top action that will request older messages. The only way to get the first message is to make my window small enought so I can have a scrollbar.  Didn't tried but something similar might happen to replies.

I'm not sure this scenario would cause a problem. I have not tested it, but I think the client would just show message seq=25 and that's it.

A different scenario would cause a problem, but it's highly unlikely to happen in real life:

You edit seq 10, the new version is seq 25. Then another client fetches messages  seq 5 to 15 without fetching 25. It would get only the old version of the message. None of the existing clients can do it, but technically API permits such use.

Considering these problems from above, why not just PUT/PATCH the message data: content and attachments ? 

First, message history. It's a required feature for example for financial institutions. 

Second, it would require substantial changes to notification protocol. When the client connects, it fetches the new messages by seqId: "get messages with seqId > N". It works fine with the current edit scheme. In case of replacing content of the old messages on the server, the client would need a way of knowing that some old message was edited.

[Dragos]

I don't mean the UI, but the dev tools. If you look in dev tools -> network tab -> ws -> select the tinode connection you can see messages between server and client. Somebody who knows can look here for the original message.  Let's not forget that somebody could get the keys from requests and make their own client and make it display anything that the server sends back.
For example Facebook Messenger doesn't allow downloading of voice messages from it's UI, but you can get the link and download them from the network tab from dev tools.

What about using another table where all edits are stored with a link to the original message in order to keep the edits and the original so the admin can see them but the clients don't.

Now it's pretty hard to change, I understand this.

[Gene]

On Friday, December 9, 2022 at 2:03:12 PM UTC-8 Dragos wrote:

I don't mean the UI, but the dev tools. If you look in dev tools -> network tab -> ws -> select the tinode connection you can see messages between server and client.

You can disable logging:

https://github.com/tinode/webapp/blob/master/src/config.js#L16

 

Somebody who knows can look here for the original message. 

Someone can ALWAYS lookup the original message. Always. The server sends the messages right away. Even if you later edit one of the messages, the original would have been sent already. There is no way to keep the original a secret *in principle*. Just not possible regardless of scheme.

 

Let's not forget that somebody could get the keys from requests and make their own client and make it display anything that the server sends back.

Correct. Once the client receives the original message, it does not matter how you edit it afterwards, the client can decide to keep the original. You cannot "un-deliver" the original without client's cooperation.

For example Facebook Messenger doesn't allow downloading of voice messages from it's UI, but you can get the link and download them from the network tab from dev tools. 

What about using another table where all edits are stored with a link to the original message in order to keep the edits and the original so the admin can see them but the clients don't.

Why? What would you get by doing it compare to the current scheme?

[Dragos]

Easyer to handle on the front end, would avoid problems regarding messages not being included in the request if there are a lot of edits and would hide the past edits and the original because only the latest version of the message would be sent to the client and others. Clients could still get the past edits with a dedicated getMeta request.

[Dragos]

There is this post https://groups.google.com/g/tinode/c/zMor7odNf6k . You haven't implemented edits in the sdk then, but now they are and the problem from there can happen with your implementation if you are going to implement a search function like Skype or Facebook Messenger has where the user would jump around the messages list. Like the origininal message is in the group you request but it's edits are not, so the user won't see the edits but the original.
Also by chaning the edit to a PUT/PATCH style update it could help the search function.

Do you think it would be a complicated change to do ?

[Gene Sokolov]

On Mon, Dec 12, 2022 at 12:17 AM Dragos <drag...@gmail.com> wrote:

There is this post https://groups.google.com/g/tinode/c/zMor7odNf6k . You haven't implemented edits in the sdk then, but now they are and the problem from there can happen with your implementation if you are going to implement a search function like Skype or Facebook Messenger has where the user would jump around the messages list.

It would jump only if the search is implemented incorrectly. 

 

Like the origininal message is in the group you request but it's edits are not, so the user won't see the edits but the original.
Also by chaning the edit to a PUT/PATCH style update it could help the search function.

Do you think it would be a complicated change to do ?

 Let me repeat:

--
You received this message because you are subscribed to a topic in the Google Groups "Tinode General" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tinode/eZ_9HXVmnPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tinode+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tinode/bcbdff2f-f9a6-43e5-9b43-24215bc5c81dn%40googlegroups.com.

[Gene]

On Monday, December 12, 2022 at 12:17:52 AM UTC-8 Dragos wrote:

There is this post https://groups.google.com/g/tinode/c/zMor7odNf6k . You haven't implemented edits in the sdk then, but now they are and the problem from there can happen with your implementation if you are going to implement a search function like Skype or Facebook Messenger has where the user would jump around the messages list. Like the origininal message is in the group you request but it's edits are not, so the user won't see the edits but the original.

Only if the client is implemented incorrectly or doing something unusual. None of the existing clients have this problem.