aniani/profanity
1
0
Fork 0
mirror of https://github.com/profanity-im/profanity.git synced 2024-11-03 19:37:16 -05:00
Code

xep-0308: Don't check whether receiving clients supports this feature

Browse Source 
XEP-0308 Version 1.1.0 (2019-05-15) states "It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages"

```
10:12:47 - jubalh: Do clients actually check whether other clients support xep0308 (LMC) before sending?
10:13:13 - pep.: not poezio, and I doubt anybody does. it's the "but carbons/MAM" argument
10:13:49 - jubalh: Profanity doesnt support this yet. So I always get the message twice. One time the message, and then the corrected ones. And I think that's right. But I understood xep0308 correctly it sais a
           client shouldnt sent a message with 'replace' if the client doesnt support it? I don't see why
10:14:50 - Ge0rG: jubalh: because you might also use Conversations and read the backlog from MAM on conversations
10:15:51 - jubalh: Ge0rG: sorry?
10:16:36 - Ge0rG: jubalh: when I'm sending you a message, I don't know which client you'll use to read it. So it doesn't make sense to limit the features I use
10:27:57 - jubalh: Yes. That's why I'm confused by thestatement in the XEP
10:28:13 - jubalh: "It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. "
10:28:37 - Holger: Yes, you're both saying the same thing.  And yes I agree, that part of the XEP is nonsense.  We have that "check whether the peer's client supports it" stuff in various XEPs that depend on
           recipient's features and it never makes sense as it doesn't cope with multi-device, MAM, groupchat.
10:28:53 - jubalh: First: You don't know if he is connected with several clients. Some supporting it and some not. Second: Why not just resend the new corrected message? Then he has both messages and no
           information is lost. If he only gets the first one information is lost
10:29:20 - jubalh: Okay
10:29:30 - jubalh: Then I won't implement it this way. Thanks guys!
10:29:34 - Holger: Well UX is a bit meh if the recipient doesn't support it (I'm an MCabber user and know what I'm talking about) but I see no better solution, yes.
```

So it makes more sense to just always send it. Non supporting clients will then get the message and the corrected message. So they get it "twice". Which is the right thing to do in my opinion.
This commit is contained in:
Michael Vetter 2020-02-12 10:31:12 +01:00
parent 11b6e1bfa0
commit 7ad2e4761b
1 changed files with 1 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
src/command/cmd_funcs.c
View File

@ -8700,22 +8700,7 @@ cmd_correct(ProfWin *window, const char *const command, gchar **args)
return TRUE; return TRUE;
} }
/* // send message again, with replace flag
char *session_jid = chat_session_get_jid(chatwin->barejid);
if (session_jid == NULL) {
win_println(window, THEME_DEFAULT, '!', "Cannot determine if recipeint supports last message correction.");
free(session_jid);
return TRUE;
}
if (caps_jid_has_feature(session_jid, XMPP_FEATURE_LAST_MESSAGE_CORRECTION) == FALSE) {
win_println(window, THEME_DEFAULT, '!', "Recipient does not support last message correction.");
free(session_jid);
return TRUE;
}
*/
// speciel send with replace tag
cl_ev_send_msg_correct(chatwin, args[0], FALSE, TRUE); cl_ev_send_msg_correct(chatwin, args[0], FALSE, TRUE);
return TRUE; return TRUE;
} }