| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The most loggings has been set to debug. Just in case of error / problem the
logging should be done with log-level ERROR or WARNING.
We will see later, which loggings should be switched to log-level INFO.
This improvement has been done to find OMEMO bugs.
See also: #1070 #1530 #1538
|
|
|
|
|
| |
Found by DebXWoody.
Led to always be true (which still made it work in most cases).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was a great ride!
IDs look instead of
`TE5BTDc2ZTc3YTMwZGU3MDgzMzllOTliNGExNjVmMjZkMTY1ZmUyZGEyNTUxMjVmODBkMmQzOGMxYWI2ZjAxNzdiM2Q=`
more like `7HcnNSoO1MVvb0p9a9e293152922853e910b8b1a65bb26e225a0568` now.
Regards https://github.com/profanity-im/profanity/issues/1520
We still has our identifier into it to filter MUC reflected messages.
profident maybe should be changed to be longer or be generated upon each
start.
|
|
|
|
|
|
|
| |
_GNU_SOURCE was even in some files where it was not needed at all
(http*).
Let's replace asprintf() with g_strdup_printf().
|
|
|
|
| |
Related to https://github.com/profanity-im/profanity/issues/1512
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a todo for this in message.c which got forgotten.
This was most likely also the reason why there were NULL entries for
this in the DB which DebXWoody mentioned in the MUC.
Thus comparison was with NULL and no new entries were added to the
database.
Edit:
After checking pull requests I see Stefans draft PR:
https://github.com/profanity-im/profanity/pull/1505
So let's add him as co-author.
Co-authored-by: Stefan Kropp <stefan@debxwoody.de>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If this happens we have more serious problems :-)
But anyways..
|
| |
|
|
|
|
| |
since its NULL safe
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
And on the way fix a memleak
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This shouldnt be necessary since we check for the receipt outside
alreayd. Let's be on the safe side though in case code gets changed
later.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`/affiliation register` can now be used to register a nickname with a
MUC.
Tested with a server without forms. Couldn't find a server which
supports forms yet.
Implements https://github.com/profanity-im/profanity/issues/1210
|
| |
|
|
|
|
|
|
| |
A form will open. One can then use `/field4 on` `/form submit`.
Implements https://github.com/profanity-im/profanity/issues/1507
|
|
|
|
| |
closes https://github.com/profanity-im/profanity/issues/1211
|
|\
| |
| | |
Add command to change password of logged in user
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Main changes:
1. Attributes instead of tags
2. Read the optional <header> tags and send them in the HTTP PUT header:
* Authorization
* Cookie
* Expires
Co-authored-by: Martin Dosch <martin@mdosch.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the following options in `omemo_bundle_publish()`:
- "pubsub#persist_items" = "true"
- "pubsub#access_model" = "open"
The same options are also used in Gajim.
I've tested this on two different servers. The bundle was successfully
added as a new PEP node. Test cases:
1. Normal use on my main account
2. Log in into a fresh tesst account on a different server
3. `/omemo clear_device_list`. In this case, the client(s) may have to
be restarted.
Note: In `_omemo_bundle_publish_result`, there's a route that is taken
when the bundle publish stanza failed. In this case, the node is
configured manually, i.e. the access_model is set to 'open'. I have
manually tested this case, but this case didn't naturally occur for me.
Note: The option "pubsub#max_items=max" is REQUIRED for the bundle
publication, as per XEP-0384. However, this is not done in other clients
(I've checked the source code of Gajim and Conversations), and it is
also not supported by Prosody. Cf. <https://github.com/xsf/xeps/pull/988>.
|
|
|
|
|
| |
Also "handle" some errors in `_omemo_bundle_publish_configure` if the
stanzas can't be found
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We need the delay value from the <forward> element.
Regards https://github.com/profanity-im/profanity/issues/660
|
| |
|
|
|
|
| |
Probably should make this configurable later.
|