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.
For OMEMO we had a list with our sent messages.
It was used so that we don't decrypt our own messages in MUCs that come
in via reflection.
Recently for https://github.com/profanity-im/profanity/pull/1209 we
started to use origin-id and use an algorithm so we can detect our own
sent messages via checking origin-id.
Profanity uses the same id for the message ID and origin-id.
With 06f300a42c we added the
message_is_sent_by_us() function.
We implemented XEP-0359 this way to fix
https://github.com/profanity-im/profanity/issues/1201 so that we don't
log our own messages in MUCs twice.
We can now check whether the message was sent by us using this function
and can get rid of the list.
Probably we could also put many parts of the sv_ev_room_message()
function inside (else) part of `if (!(g_strcmp0(mynick,
message->jid->resourcepart) == 0 && message_is_sent_by_us(message))) {`.
Have to look more closely whether any of this needs to be run in case
the message actually comes from us.
So far if one had enabled `/history` and did `/msg somenick` the history
was loaded from file and displayed like this:
```
04-04-17 15:23 - 3/4/2017:
01-01-00 10:30 - me: ....
01-01-00 10:31 - somebody: ....
01-01-00 10:32 - somebody: ....
```
So the first line contained the actual date. But the date used in each
line was always 01-01-2000. This date was for some reason hardcoded.
This commit now actually uses that date to build the proper GDateTime
instead of just printing it.
Fix https://github.com/profanity-im/profanity/issues/922
This theme color applies to the tab title text of the statusbar tab that
is currently shown.
The (somewhat confusingly named) `statusbar.active` theme color now
applies to all other tabs (before, it applied to all tabs).
Coloring of a tab that is highlighted/has new messages is done as before
using the `statusbar.new` theme color.
The default color is set to `cyan`, and thus causes no visible change
for users -- until modified.
Profanity uses the node part of a JID as display name for a tab. If such
a JID doesn't contain the node part, Profanity crashes on NULL pointer
dereference.
In the above case, use barejid which is just a domain. Fixes#1153.
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.
If re-establish a connection don't print the room history again.
In case there there happened nothing at all since we got the room
history on the last connection.
And in case there were no new messages during the time we have been
disconnected.
Instead of printing the room history again we now print 'Re-established
Connection'.
This adds a bit of overhead since we save the timestamp upon every MUC
message.
See: https://github.com/profanity-im/profanity/issues/704
We destory the roster in ev_disconnect_cleanup().
Adding a function to test if the roster has been destroyed and testing
for it in the statusbar.
So now when the connection is lost 'Lost connection' is printed in all
open windows.
We can then reconnect with `/connect accountname`.
Should fix https://github.com/profanity-im/profanity/issues/1083
status_bar_new() and status_bar_active() are almost identical.
Let's use one helper function to not duplicate code.
I thought about renaming both functions into one and adding another
parameter but didn't come up with a good name for the function that
clearly describes what it does. So staying with current names + helper
functions.
Save the name for displaying the windows in the statusbar inside the tab
object.
So far we calculated them repeatedly and this created issues when we
lost the connection.
Regards https://github.com/profanity-im/profanity/issues/1083
`/occupants char` now sets a character that is displayed before the nick
in MUCs. Similar like `/roster char` is displaying a char for the roster.
Regards #690
`/occupants header char` now sets a character that is displayed before
the role (moderator, visitor..) in a room. Similar to `/roster header
char` is displaying a char for the roster.
Regards https://github.com/boothj5/profanity/issues/690
Roster has a `/roster contact indent` option.
Now we have the same for occupants. So contacts in roster and in MUC can
have configurable indentation.
Regards https://github.com/boothj5/profanity/issues/690
When auto joining a MUC we don't have access to required information so
we just don't start OMEMO at this time.
Once we receive disco info we then try to start OMEMO.
There is 3 policy:
- manual: OMEMO session are only started manually
- automatic: OMEMO session are only started if they have been started
manually before
- always: OMEMO session are always started unless they have been ended
manually before
Closes#1040 and fixes#1052
Reflected messages can't be filtered by nick only otherwise you might
ignore messages comming from you on another devices.
Consequently we maintain a list of sent messages id in mucwin.
To be sure the id will be correctly reflected we use the origin-id
stanza.
In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the
allowable lexical representations for the xs:boolean datatype are the
strings "0" and "false" for the concept 'false' and the strings "1" and
"true" for the concept 'true'; implementations MUST support both styles
of lexical representation.
