Add message type for correction

[Diadlo]

This change is 

[Diadlo]

Does somebody know, why Messager.h defines its own message types instead of incude and using defines in tox.h?

[iphydf]

---

Reviewed 6 of 6 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[nurupo]

This is for correcting the last message, right? Why not utilize the message_id to be able to correct any message?

[sudden6]

Would it make sense? when allowing changes to any message, one could sneakily change the start of conversations.

[zoff99]

hashtag: persistent longterm message IDs
we will need those soon for other things aswell

[zoff99]

@Diadlo how is "last message" defined? messages have no guarenteed order of arrival (and sometimes arrive out of order)

so the sender thinks he deletes or corrects one message, while in fact another message on the receiver side is deleted/corrected

[Diadlo]

@zoff99 Same with writing normal messages. When you write message you are not sure, that friend already receive previous. Correction works the same way

ADDED: Last message := last received message

[Diadlo]

@nurupo I'm not too familiar with toxcore. So current implementation is easies way to create at least some way to edit messages. I will be happy if someone can implement message editing within ~session or something like this
@sudden6 I don't think, that "one could sneakily change the start of conversations" should be real reason to avoid implementation of this feature. Many other IM have this feature and it's very useful

[zoff99]

#548
now with 0.2.0 we have the chance to implement long term message IDs
but only once. otherwise we need to wait for 0.3.0 again

[Diadlo]

I'm not sure, that long term message ID is needed now

[zoff99]

the need has been there for a long time:
messages arrive out of order
messages are sent 2 or 3 times (with faux offline messaging)
messages receipts never arrive

[GrayHatter]

This is a mistake... it makes the code base harder to maintain (why are you using an enum inside of a define?). Requires clients to implement code/features in a similar manner, while also not providing any specifics as to how. Adds an additional level of required complexity for clients who need to prevent malicious use. Allows message history from two different clients to go out of sync, in an unreasonable way.

my general reaction to this pull http://i.imgur.com/iouyret.gif

[nurupo]

I'm not a big fan of this change either. Especially after zoff99 pointed out that the messages might not arrive in the right order, so you might correct the wrong message.

[Diadlo]

So, maybe revert this change then?

[Diadlo]

why are you using an enum inside of a define?

I did it by analogy with the previous value: PACKET_ID_ACTION

Requires clients to implement code/features in a similar manner, while also not providing any specifics as to how

Sorry, maybe I skip something, but where described how implement action message?

Allows message history from two different clients to go out of sync, in an unreasonable way.

Hm... AFAIK the history of two clients has never been synchronized

[iphydf]

Let's revert it for now. @Diadlo can you send a PR? We can keep the idea in mind and revisit it in the upcoming redesign.

[GrayHatter]

I'm not a big fan of this change either. Especially after zoff99 pointed out that the messages might not arrive in the right order, so you might correct the wrong message.

Messages WILL arrive in the order given to toxcore, or not at all. Zoff99 is incorrect when he said that.

why are you using an enum inside of a define?

I did it by analogy with the previous value: PACKET_ID_ACTION

Requires clients to implement code/features in a similar manner,>>while also not providing any specifics as to how

Sorry, maybe I skip something, but where described how implement
action message?

It says, in tox.h (or used to) "similar to an action message in IRC" or
something to that effect.

Also, you don't really need to do anything specific with an action
message, treating exactly the same as a standard message is perfectly
acceptable. Would you make the same assertion for a message correction?

What if I receive a message correction as the first message? How should
my client handle that?

Allows message history from two different clients to go out of sync,
in an unreasonable way.

Hm... AFAIK the history of two clients has never been synchronized

It's ALWAYS been synchronized. Now, if client A replaces the message
with the correction, and client B appends the correction. The two
histories will diverge. Additionally, what's to stop me from ONLY
editing the last message over and over. One client will have dozens of
messages, the other will have 1.

[GrayHatter]

On February 2, 2018 12:20:25 AM PST, Polshakov Dmitry ***@***.***> wrote: > why are you using an enum inside of a define? I did it by analogy with the previous value: `PACKET_ID_ACTION` > Requires clients to implement code/features in a similar manner, while also not providing any specifics as to how Sorry, maybe I skip something, but where described how implement action message?

It says, in tox.h (or used to) "similar to an action message in IRC" or something to that effect. Also, you don't really need to do anything specific with an action message, treating exactly the same as a standard message is perfectly acceptable. Would you make the same assertion for a message correction? What if I receive a message correction as the first message? How should my client handle that?

> Allows message history from two different clients to go out of sync, in an unreasonable way. Hm... AFAIK the history of two clients has never been synchronized

It's ALWAYS been synchronized. Now, if client A replaces the message with the correction, and client B appends the correction. The two histories will diverge. Additionally, what's to stop me from ONLY editing the last message over and over. One client will have dozens of messages, the other will have 1.

[GrayHatter]

Messages WILL arrive in the order given to toxcore, or not at all. Zoff99 is incorrect when he said that.

…

On February 1, 2018 7:19:03 PM PST, nurupo ***@***.***> wrote: I'm not a big fan of this change either. Especially after zoff99 pointed out that the messages might not arrive in the right order, so you might correct the wrong message. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #685 (comment)