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

288 Commits

Author SHA1 Message Date
Michael Vetter
4a7a0f3e76 db: move includes 2020-04-06 10:50:20 +02:00
Michael Vetter
11663625cc db: Have one database per account 2020-04-06 10:50:20 +02:00
Michael Vetter
71e872c5b8 database: dont log muc pms 2020-04-06 10:50:20 +02:00
Michael Vetter
5cc3b469a8 database: log stanza_id and whether it is a muc message 2020-04-06 10:50:20 +02:00
Michael Vetter
8045a32c4a database: log incoming messages
First trial. Not covering all cases yet.
2020-04-06 10:50:20 +02:00
Michael Vetter
eb2fbdba2e Dont filter out own MUC messages if muc history is set to 'regular'
We use the same incoming function as for regular incoming text here. But
don't want to filter out our own messages since we didn't print them
during sending.

Follow up to 8ee2cdadc8
2020-02-21 18:46:09 +01:00
Michael Vetter
c13553bfcb Fix missing change from last commit 2020-02-20 23:43:35 +01:00
Michael Vetter
1f8b1eb740 Allow utf8 symbols as omemo/pgp/otr indicator char
Fix https://github.com/profanity-im/profanity/issues/1264
2020-02-20 23:36:10 +01:00
Michael Vetter
1ddac7b9c6 Put getting mentions in own function
So we can use it somewhere else too.

Regards https://github.com/profanity-im/profanity/issues/1261
2020-02-20 10:03:36 +01:00
Michael Vetter
6aa793fca6 Refactor mucwin_history()
Just pass ProfMessage.
2020-02-19 16:57:37 +01:00
Michael Vetter
3aad0523d7 Always send delivery receipts if enabled
So far receipts are only send if we have enabled it and the other client
supports it.
But it could be that the other person is connected with several clients.
One supporting it and the other which doesn't. If the not supporting one
is active and we send to a fulljid, then we won't get receipts.

Probably it's best to just always send them if they are enabled in
Profanity. And not try to find out the capabilities of the other client.

Fix https://github.com/profanity-im/profanity/issues/1268
2020-02-14 10:17:07 +01:00
Michael Vetter
c614cc288a Fix tests 2020-02-14 10:17:07 +01:00
Michael Vetter
50271493b7 xep-0308: remove replace_id from privwin signature
No `/correct` allowed in privwins
2020-02-14 10:17:07 +01:00
Michael Vetter
4ec005e4c3 xep-0308: Implement LMC for outgoing MUC messages
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.
2020-02-14 10:17:07 +01:00
Michael Vetter
66d3f572f9 xep-0308: Dont allow to correct MUC PMs
People could change messages of other people if the nick isn't
registered.
2020-02-14 10:17:00 +01:00
Michael Vetter
11b6e1bfa0 xep-0308: enable corrections for outgoing encrypted messages 2020-02-12 08:54:12 +01:00
Michael Vetter
b6b7dd5ad4 xep-0308: update the UI upon sending a corrected message
So far we don't do this for encrypted messages. Still needs to be done.
And MUC also needs to be done.
2020-02-11 15:26:58 +01:00
Michael Vetter
1118110071 xep-0308: Implement /correct to correct the last send message
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.
2020-02-10 16:17:01 +01:00
Paul Fariello
84506cbaeb Use OMEMO for offline MUC members (#1242) 2020-01-20 14:28:13 +01:00
Michael Vetter
be13e98fe7 Update my Copyright to 2020 2020-01-03 19:52:31 +01:00
Michael Vetter
771dfab123 Start implementing XEP-0084
So far we just subscribe and get the IDs.
2019-12-18 10:17:10 +01:00
Michael Vetter
3bb2e07c1e Use helper function to clean incoming messages
We might want to use utf8proc or something to normalize utf8 strings
later?
2019-12-13 13:42:43 +01:00
Michael Vetter
46fd7150e5 Add vim modeline 2019-11-13 12:11:05 +01:00
Michael Vetter
87f9bacffa Filter RTL unicode characters out
Gajim sends \u200E and \u200F for RTL.
It is planned that Gajim stops doing this and uses some GTK feature to
get the same result.

However users expressed the whish that we filter out such characters in
incoming messages before displaying them to make Profanity more robust.

I'm still not sure whether I like the solution because it means a lot of
allocating/deallocating upon every new message.

Fix https://github.com/profanity-im/profanity/issues/1220
2019-11-13 09:39:07 +01:00
Michael Vetter
f71de61b9d Don't override ProfMessage Id with origin-id
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.
2019-10-31 13:45:44 +01:00
Michael Vetter
aa0c638394 Update chat_log_pgp_msg_out() usage
Fix build
2019-10-29 15:20:24 +01:00
Michael Vetter
5a0a6c97e2 Two carbon logging changes
Add resourcepart to the outgoing carbon that is logged, so we use the
correct filenames for MUC PMs.

Dont log incoming carbons of MUC PMs as a workaround to faulty server
behaviour.

See https://wiki.xmpp.org/web/Multi-Session_Nicks#Private_Messages under
'Client-side workaround behavior'.

Regards https://github.com/profanity-im/profanity/issues/1214
2019-10-29 11:46:01 +01:00
Michael Vetter
9788410aaf Also log sv_ev_delayed_private_message 2019-10-29 10:52:11 +01:00
Michael Vetter
8c8c18c6fd Actually log MUC PM messages
If I'm not mistaken MUC PMs have not been logged at all if there was no
other client sending carbons.
This should add MUC PM logging functionality.

We still need to make sure carbons log to the same file.

Regards https://github.com/profanity-im/profanity/issues/1214
2019-10-28 23:36:42 +01:00
Michael Vetter
31014b5e51 Fix which message we want to log 2019-10-19 23:24:33 +02:00
Michael Vetter
06f300a42c Move message sent by us logic in own function 2019-10-18 14:50:25 +02:00
Michael Vetter
dfead6415f sv_ev_room_message: log in all cases if not our client
Forgot to check what happens if the length is <= 10.
2019-10-18 11:59:39 +02:00
Michael Vetter
f7474cd72c sv_ev_room_message: check if message->id is not NULL 2019-10-18 11:43:30 +02:00
Michael Vetter
5c6f5ba0f7 Add connection_get_profanity_identifier stub
And move defintion to xmpp.h
2019-10-18 11:23:30 +02:00
Michael Vetter
430b2eaa0d Log incoming MUC messages if origin-id sais they dont come from us
Regards https://github.com/profanity-im/profanity/issues/1201
2019-10-18 10:40:24 +02:00
Michael Vetter
147be3afdf Don't log own messages on incoming MUC
`sv_ev_room_message()` called `groupchat_log_msg_in()` to log all
incoming MUC messages.

`cl_ev_send_muc_msg()` calls `groupchat_log_msg_out()`.

So messages sent by the user himself was logged two times.

Filter the incoming messages and only log the ones not from our occupant
jid/nick.

Fix https://github.com/profanity-im/profanity/issues/1201
2019-10-06 22:32:58 +02:00
Michael Vetter
523681a642 Log outgoing carbons instead of incoming
Incoming carbons are logged as normal message already.
So we had this logged twice but didn't log outgoing carbons,
send from our account but by another client, at all.

Fix https://github.com/profanity-im/profanity/issues/1181
2019-10-04 13:22:14 +02:00
Michael Vetter
09b6fc9aaa Log 1:1 messages from other clients also to file
Carbons where not logged so far.

Fix https://github.com/profanity-im/profanity/issues/1181
2019-09-04 10:28:52 +02:00
Michael Vetter
25501a5d8a Improve sv_ev_roster_received() last activity check
We don't need to do all the timing stuff if last activity is disabled
anyways.
2019-08-02 15:52:49 +02:00
Michael Vetter
53c3115976 Don't print subscribed message if contact is already in roster
This occured with a user running Cisco Jabber. It seems this server
sends repeated presence subscribed stanzas. And although I find this
strange according to RFC this seems to be ok.

So let's filter them and only display in the console output and to the
log. But don't open seperate windows.

Fix https://github.com/profanity-im/profanity/issues/1165
2019-08-01 20:48:23 +02:00
Michael Vetter
ad9263520e Show MUC history on intentional reconnect
Small bug caused by 13675fb and ce5a4ed.
Fix https://github.com/profanity-im/profanity/issues/1142
2019-07-03 09:19:24 +02:00
Paul Fariello
db8f32c049 Fix handling of encrypted carbons 2019-06-21 15:52:24 +02:00
Paul Fariello
f831f65737 Rename prof_message_t into ProfMessage 2019-06-20 14:30:45 +02:00
Paul Fariello
44d16e9141 Add prof_message_t to wrap all message attributes
Probably missing copy of body to plain in carbon and privmessage.
Only covers the incoming message path because goal is OMEMO decryption
of untrusted message.
Cover some of the log functions but not all.
2019-06-20 14:30:42 +02:00
Paul Fariello
3bb3cc625d Use flags in xmmp/message.c for encryption and trust 2019-06-20 14:30:37 +02:00
Michael Vetter
40b72ffe55 Add myself to copyright
Like discussed with James.
2019-06-17 10:44:08 +02:00
Michael Vetter
5dd6ba73f4
Merge pull request #1110 from profanity-im/feature/704-ui-behaviour-reconnect
Feature/704 ui behaviour reconnect
2019-06-11 07:00:34 +02:00
Michael Vetter
47e55cc112 Safe last MUC message timestamp per MUC
After pasis review of my code he thinks it's better to safe the
timestamp per MUC so we can account for some problems that could occur
with timing.
2019-06-11 06:35:03 +02:00
Michael Vetter
ff6038fe32 Rejoin all MUCs on reconnect
Should fix https://github.com/profanity-im/profanity/issues/1120
2019-06-10 23:18:43 +02:00
Michael Vetter
ce5a4ed77c Only show MUC subject on first connect
For #704 we don't show the room history upon reconnect.
Now we also don't show the room subject in the channel
upon re-established connection.
2019-06-05 10:05:12 +02:00