| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
and print settings if only `/correction` is run.
|
| |
|
|
|
|
| |
"retrieve1" should have been only for testing.
|
|
|
|
| |
Fix #1068
|
| |
|
|
|
|
| |
Introduced in bf2e09feee1697c570fcfb9e1e44a8ec991bd196.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Have two helper functions one for XEP-0203 and one for XEP-0091.
|
|
|
|
|
|
|
|
| |
This reverts commit ef00b10c90aef8b75415fae558789d21bb975d75.
According to reply by user in
https://github.com/profanity-im/profanity/issues/1254#issuecomment-578389784
it didn't help.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Default is on. `revail.os=false` in the `connection` section of the
config can disable it.
A command to configure this will follow.
|
|
|
|
|
| |
So far we only sent client name and version. Let's also send the OS
name.
|
|
|
|
|
|
|
|
|
|
| |
Cannot be configured for now.
Can be set via `adv.notify.discoversion` in the `notification` section.
Will notify about version requests via XEP-0092 and XEP-0232.
Client version can still be seen via caps (capabilities).
See `stanza_attach_caps()`.
|
|
|
|
| |
We will need this if we want to display the Name instead of the JID.
|
| |
|
| |
|
|
|
|
| |
Fixes #1239
|
| |
|
|\
| |
| | |
OMEMO message keys allow prekey="1" alongside prekey="true"
|
| |
| |
| |
| |
| |
| |
| |
| | |
prekey is defined as `<xs:attribute name="prekey" type="xs:boolean"/>`
which allows both `true` and `1` as truthy values.
Not checking for `1` breaks omemo encryption when interacting with
clients which set prekey="1", example: psi+ 1.4.983
Regards https://github.com/profanity-im/profanity/issues/1247
|
|/ |
|
|
|
|
| |
And use better function names.
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1241
|
|
|
|
|
|
| |
We use malloc() and free().
Fix https://github.com/profanity-im/profanity/issues/1241
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we removed the avatar feature only after a succesful retrive in
avatar_request_item_by_id() before we are going to retrieve the actual
image.
We should remove it at every `/avatar barejid` call too so in case one
retrieval was unsucessful that we can call it again.
So far it seems like there is no other way to trigger getting the nodes
except announcing that we support the avatar feature.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Proof of concept.
Needs error checking, a nice interface, general cleanup..
|
|
|
|
| |
Add a `/avatar` command.
|
|
|
|
| |
So far we just subscribe and get the IDs.
|
|
|
|
| |
Fix https://github.com/profanity-im/profanity/issues/1227
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Fix bug introduced in 68af0aad65d243e654866eac5a7cd728ee293aa0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some clients (eg. PSI) are sending the stanzas delimited by whitespace
text nodes, which will fail while looping through the <prekeys/>
children and also print weird errors when iterating through the <list/>
of devices.
When debugging this, I was looking at the XML of Gajim and PSI and first
was somehow confused why Profanity printed "OMEMO: received device
without ID" while the XML looked identical (minus the actual IDs and the
JIDs of course).
However, Gajim was sending the XML without whitespace nodes in between
and PSI did not, so for example the following (with the relevant
whitespace nodes marked with X):
<message type="headline" to="..." from="...">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items type="headline" node="eu.siacs.conversations.axolotl.devicelist">
<item id="...">
<list xmlns="eu.siacs.conversations.axolotl">
X <device id="..."/>
X <device id="..."/> X
</list>
</item>
</items>
</event>
<delay xmlns="urn:xmpp:delay" stamp="..." from="..."/>
</message>
... would result in three times the "OMEMO: received device without ID"
error, because we actually have three XML text nodes here that obviously
don't have an "id" attribute.
Now since the <list/> children above aren't really a problem and only
annoying, text nodes in the <prekeys/> stanza actually cause
omemo_start_device_session_handle_bundle to return failure.
I've fixed this by explicitly matching the stanza names we are
interested in, skipping everything else.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Let's use UUID to have a more random string then just 10 alphanumeric
values.
|