about summary refs log tree commit diff stats
path: root/src/xmpp/message.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix messages with receipt request not displayedWilliam Wennerström2020-07-021-1/+0
| | | | | | | | Messages from Conversations contains: <request xmlns='urn:xmpp:receipts'/> And would not be displayed in Profanity as it never reached _handle_chat(..).
* message.c: Put plugin handler code in helper functionMichael Vetter2020-07-021-7/+14
|
* message.c: Log invalid message typeMichael Vetter2020-07-021-14/+14
| | | | | So far we logged when we receive a message without a type. Which is actually quite common and makes no sense.
* message.c: Check for message typeMichael Vetter2020-07-021-8/+4
| | | | | RFC 6121 allows only few types. So we can also remove that check in _handle_chat().
* message.c: Remove handled cases form _handle_chat()Michael Vetter2020-07-021-7/+0
| | | | Both cases are tested before entering that function.
* message.c: Break out of _message_handler() after handling codeMichael Vetter2020-07-021-0/+4
| | | | | AFAIK it can only be one. Except at STANZA_NS_MUC_USER which is used in several cases.
* message.c: Parse incoming message stanzas according to typeMichael Vetter2020-07-021-31/+34
|
* message.c: Add pubsub helper functionMichael Vetter2020-07-021-13/+19
|
* message.c: Add XEP informationMichael Vetter2020-07-021-1/+6
|
* message.c: Add my copyrightMichael Vetter2020-07-021-0/+1
|
* message.c: Make several functions staticMichael Vetter2020-07-021-3/+3
|
* message.c: Adjust function formattingMichael Vetter2020-07-021-8/+12
|
* And ifdefs around new OX functionsMichael Vetter2020-06-301-7/+10
| | | | | Fix for some build cases introduced in 2c94ee5a88f64332a3f41f41a4d314fc52200e31 Fix https://github.com/profanity-im/profanity/issues/1376
* Feature request - XEP-0373: OpenPGP for XMPP (OX)DebXWoody2020-06-291-0/+170
| | | | | | | | | Basic implementation of XEP-0373: OpenPGP for XMPP. https://xmpp.org/extensions/xep-0373.html Command /ox Issue: #1331
* Fix possible segfault in xmpp/message.cDmitry Podgorny2020-06-161-1/+1
| | | | Check for pointer to be NULL before dereferencing it.
* Fix carbon loggingMichael Vetter2020-05-271-4/+6
| | | | Regards https://github.com/profanity-im/profanity/issues/1342
* Add and use connection_get_barejid()Michael Vetter2020-05-251-4/+4
| | | | Instead of connection_get_fulljid() and then creating a Jid from it.
* Fix typing notificationMichael Vetter2020-05-211-1/+1
| | | | | | | | | | | | | | | | | | | With d1d0ad8d1a8e28690aa8723566dd64c1ccdcf9d6 we set a timestamp to now for all messages upon receival. Even if the original message didn't contain any timestamp. So we can use the timestamp of retrieval for logging and displaying and don't get them at each of those location where they might differ. This means that timestamp will never be NULL. I don't see why we would want to check for the chat state only if timestamp isn't there. Probably because in XEP-0085 there is not timestamp defined. So if it thats stanza it's not there and we can parse quicker, but there is nothing forbidden it to be there. Related to https://github.com/profanity-im/profanity/issues/1339
* _handle_carbons(): fix potential memleakMichael Vetter2020-04-211-2/+4
|
* MAM: Correctly display incoming MAM chat messageMichael Vetter2020-04-111-7/+12
|
* Add to_jid field to ProfMessage structMichael Vetter2020-04-111-24/+32
| | | | | Is usefult in many cases if we want cleaner code. Hope this edit didn't break anything though ;-)
* First test with receiving MAMMichael Vetter2020-04-111-0/+27
|
* _handle_chat: return if no 'from'Michael Vetter2020-04-111-0/+3
| | | | Let's not crash :-)
* Don't crash if we get a message without from or typeMichael Vetter2020-04-111-1/+8
| | | | | | | | MAM messages don't have a type nor a from. If we detect a message without type let's log it and exit without continuing to try to parse it. Otherwise we go into _handle_chat() and crash on the no from.
* Add type field to ProfMessageMichael Vetter2020-04-061-4/+8
| | | | The mucuser boolean is not now needed anymore.
* db: log all incoming and outgoing messagesMichael Vetter2020-04-061-3/+3
|
* Rename PROF_MSG_ENC_PLAIN to PROF_MSG_ENC_NONEMichael Vetter2020-04-061-1/+1
|
* Add timestamp for incoming messages if none is setMichael Vetter2020-04-061-0/+6
| | | | | | | | Timestamps are only set if a message is delayed. If none is set let's set it upon recaival so we don't have to set it when it gets displayed. This means we will also have it for logs etc in the ProfMessage.
* Use correct MUC message timestampMichael Vetter2020-03-091-0/+7
| | | | | | | | win_println_incoming_muc_msg() always used the current time. Now let's use whatever is sent int he message struct (from the delay stanza or the current time that we set now once the message is received). No playing with the time upon display anymore.
* Set muc history correctly in _handle_groupchat()Michael Vetter2020-02-251-1/+1
| | | | Fix init. mistake introduced in e9c5c1979d836ed75c37d48651710b4fd125cfb2
* Fix memleak in _handle_groupchat()Michael Vetter2020-02-251-1/+6
| | | | We need to unref the timestamp before setting a new one.
* Parse mentions and triggers in muc history if display is 'regular'Michael Vetter2020-02-201-1/+1
| | | | Fix https://github.com/profanity-im/profanity/issues/1261
* xep-0308: enable for carbon copied messagesMichael Vetter2020-02-141-0/+15
| | | | | | | If we are connected with another client and send a message, then correct it. We now display it correctly in Profanity. Id wasn't saved for carbon copied messages too so far.
* xep-0308: Implement LMC for outgoing MUC messagesMichael Vetter2020-02-141-1/+5
| | | | | | Including OMEMO encrypted ones. Also rename `win_println_me_message()` to `win_print_outgoing_muc_msg() as I think it's a more descriptive name.
* Rename MUC PM handlerMichael Vetter2020-02-141-3/+3
| | | | | Rename from _private_chat_handler() to _handle_muc_private_message() to be more consistent with other handler names.
* xep-0308: Dont allow to correct MUC PMsMichael Vetter2020-02-141-8/+0
| | | | | People could change messages of other people if the nick isn't registered.
* xep-0308: correct incoming MUC PMsMichael Vetter2020-02-121-0/+14
|
* xep-0308: Display corrected incoming MUC messages correctlyMichael Vetter2020-02-121-0/+10
|
* xep-0308: enable corrections for outgoing encrypted messagesMichael Vetter2020-02-121-3/+15
|
* xep-0308: Implement `/correct` to correct the last send messageMichael Vetter2020-02-101-2/+5
| | | | | | | | So far the correction is sent. But the UI in Profanity itself is not updated. Also autocompletion for `/correct` with the last sent message is missing.
* xep-0308: Initial support for incoming LMCMichael Vetter2020-02-101-0/+19
|
* muc: save oldest timestampMichael Vetter2020-01-301-2/+7
| | | | | | | | | | | | | | | | | | So far we saved the timestamp which also had the `from`. But we need this only to find out whether it's MUC history. For displaying we should use the oldest delay timestamp. Also in https://github.com/profanity-im/profanity/commit/61f66966ddfe8ebd8bae26dd7ff92d777004edda#diff-4926fd4577a336bd3eb240f8104a5c5bL837 a error was introduced. Before we saved the timestamp in all cases. And only if timestamp AND from was given we went into MUC history case. Normal timestamp saving was not done anymore only if it also had a from attribute. Regards https://github.com/profanity-im/profanity/issues/1254
* Revert "Save first delay tag as timestamp"Michael Vetter2020-01-281-9/+0
| | | | | | | | This reverts commit ef00b10c90aef8b75415fae558789d21bb975d75. According to reply by user in https://github.com/profanity-im/profanity/issues/1254#issuecomment-578389784 it didn't help.
* Save first delay tag as timestampMichael Vetter2020-01-241-0/+9
| | | | | | | | | | | | So far we got the first delay with a from that comes from the server. This way we know it's MUC history. Now we take the first time stamp we actually find. Which is likely the one being added first. And should contain the correct time to display. It would be nicer to actually compare the dates though. Regards https://github.com/profanity-im/profanity/issues/1254
* Add vim modelineMichael Vetter2019-11-131-0/+1
|
* Check for correct delay tag for muc timestampsMichael Vetter2019-11-131-6/+7
| | | | | | | | | | | | | https://github.com/profanity-im/profanity/issues/1190 had another issue: Sometimes servers send multiple </delay> and we just checked the first one we got and only used it if the 'from' attribute was fitting. However it could be that we actually wanted the second </delay> element and there the 'from' would have been right. So we need to loop through them until we get the one with the fitting 'from'. Fix https://github.com/profanity-im/profanity/issues/1190
* _handle_groupchat(): get correct origin-id stanzaMichael Vetter2019-11-081-2/+2
| | | | | | | | | | | | | | | | | | The problem is that in _handle_groupchat() we look for STANZA_NS_STABLE_ID which will result in origin-id or stanza-id. It seems like prosody servers send origin-id first, so this worked in all my tests. But actually we cannot be sure of the order. So far we stopped after the first element was found. I only found xmpp_stanza_get_child_by_ns() and xmpp_stanza_get_child_by_name() in libstrophe. But we need a combination of both. So I created stanza_get_child_by_name_and_ns() for Profanity. I need to remember to upstream this to libstrophe later (if they really don't have such a function). Fix https://github.com/profanity-im/profanity/issues/1223
* Don't override ProfMessage Id with origin-idMichael Vetter2019-10-311-18/+40
| | | | | | | | | | Profanity sends the same value for both. Other clients might not. Safe both since we could need them later. Once we implement Last Message Correction we will need the regular id. If we override it with origin-id and another client chooses to not use the same value for id and origin-id then we can't interpret the id sent with the LMC request correctly.
* Set mucuser in carbon caseMichael Vetter2019-10-291-0/+8
| | | | | | | | | | | Also we initialize mucuser properly. Now in case of a carbon of a MUC PM we sv_ev_incoming_carbon() which calls _sv_ev_incoming_plain() and then we log it via chat_log_msg_in() in there. But we also get the sv_ev_incoming_private_message() and call chat_log_msg_in() in there too. So the incoming message get's logged twice.
* Make prof_identifier constMichael Vetter2019-10-221-1/+1
|