archive_is is <stanza-id> or <result id=""> and should identify one
message stable and uniquely.
See XEP-0359: Unique and Stable Stanza IDs.
We need this for example for this situation:
* we go online with Profanity
* we fetch all messages since yesterday
* we add them to the db
* we go offline
* we go online with Profanity
* we fetch all messages since yesterday
* we only want to add the new ones
So far we don't ask MAM "give me all since last 'id'" but since a
certain date.
In case no archive_id will be set, it will be `(null)` and thus should
be inserted anyways because it won't find a value with (null) in that
row.
Because when adding we use `message->stanzaid ? message->stanzaid : "",`
so it will be empty in such a case.
Regards MAM: https://github.com/profanity-im/profanity/issues/660
Regards Stable IDs: https://github.com/profanity-im/profanity/issues/1207
We use malloc() to allcoate memory for the arguments.
But later on in cmd_funcs.c we use g_strfreev() to free it.
Let's use g_malloc() to allocate instead.
Second change is to use g_malloc() and g_free() for a gchar.
Autocomplete only completed on|off.
Now:
`/lastactivity get` -> get server uptime
`/lastactivity get <jid>` -> get user lastactivity
`/lastactivity set on` -> enable for self
`/lastactivity set off` -> disable for self
Fix https://github.com/profanity-im/profanity/issues/1411
`parse_args()` and `parse_args_with_freetext()` shared a lot of common
code.
Let's have a helper function `_parse_args_helper()` for that. The
`with_freetext` parameter will make it behave like
`parse_args_with_freetext()`.
In preparation for https://github.com/profanity-im/profanity/issues/1404
This commit partly reverts
8f37afcd37
Which was using a wrong approach to achieve this.
It changed parse_args() to have a -1 for infinite parameters.
But actually parse_args_with_freetext() should have been used exactly
for this behaviour.
Discovered when checking for
https://github.com/profanity-im/profanity/issues/1404
Discovering Public Keys via PEP
* 4.3 Discovering Public Keys of a User
* 4.4 Requesting Public Keys
* Import Public Keys into GnuPG's local keyring.
Issue: #1331
If we receive a message we get:
<< room message: eagle@conference.anoxinon.me (win 2)
Same for private chats and regular chats.
And several other kinds of notifications.
If we only receive notifications from a chat window it would be nice to
also clear the hilight on the console window since we already catched up
by reading the actual message in the chat window.
Probably not the best description :-) I hope you get it..
Regards https://github.com/profanity-im/profanity/issues/1399
src/pgp/gpg.c:p_ox_gpg_readkey
Used to read a public key from a file. The function will return the fingerprint
of the file and the base64 encoded key.
src/xmpp/ox.[hc]
ox_announce_public_key(const char* const filename) can be called from the /ox
announce <filename> command. The key within the file will be pushed on PEP and
the Metadata node will be set.
Issue: #1331
Plain chat messages not working for non-carbon + no OTR support.
On master we did some clean-up. The problem is at https://github.com/profanity-im/profanity/blob/0.9.patch/src/event/server_events.c#L625 (0.9.0). The implementation looks like:
- HAVE_LIBOTR is set - _sv_ev_incoming_otr
- HAVE_LIBOTR is not set - _sv_ev_incoming_plain
I think the `_sv_ev_incoming_otr` can handle otr and plain, because I didn't find a `_sv_ev_incoming_plain` if `HAVE_LIBOTR` is set.
On master for 0.10.0 the implementation is much better:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L623
But, we just call `_sv_ev_incoming_otr` independent of `HAVE_LIBOTR`.
Unfortunately, `_sv_ev_incoming_otr` is doing nothing if `HAVE_LIBOTR` is not set:
https://github.com/profanity-im/profanity/blob/master/src/event/server_events.c#L538
I did some more clean-up at sv_ev_incoming_message and changed the implementation of `_sv_ev_incoming_otr`.
```
static void
_sv_ev_incoming_otr(ProfChatWin *chatwin, gboolean new_win, ProfMessage *message)
{
// OTR or plain
plain
}
```
The caller do not take care of `HAVE_LIBOTR`, call `_sv_ev_incoming_plain` if you are sure it's a plain message or call `_sv_ev_incoming_otr`. `_sv_ev_incoming_otr` can be used for otr / plain or for plain only.
In 0.9.x we fixed an issue, because OMEMO devices should be defined in "item"
with id "current". This should work, but it won't work if there is no "current".
If there is no "current" we will just use the first item.
Issue #1384
Messages from Conversations contains:
<request xmlns='urn:xmpp:receipts'/>
And would not be displayed in Profanity as it never reached
_handle_chat(..).
So far:
```
/executable urlsave html "test %u" results in url.save.cmd[html]=test %u
/executable urlsave * "test %u" results in nothing.
```
Probably due to limitation in .ini file format.
Additionally to ec7e635e75.
In the earlier commit I just setted the test value ignoring the real
format.
Now we correctly transform:
```
[logging]
urlopen.cmd=xdg-open
```
into:
```
[executables]
url.open.cmd=false;xdg-open %u;
```
c56d530b67 by peetah moves:
urlopen.cmd from the 'logging' to a new 'executables' section in profrc
avatar.cmd from the 'logging' to a new 'executables' section in profrc
We need to adapt this so that users don't have to set the setting again
themselves.
The display of commands associated with specific file
types and protocols will need to be implemented later,
but this requires to use private data of the GKeyFile
structure, which can be a maintainability issue on the
long term.
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
/urlopen is replaced by /url with the following sub commands:
/url open <url>
/url save <url> [<path>]
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
Where GKeyFile usually use the pref[locale] format to define
locale specific translated data, it is here hijacked to be used
as pref[option] in order to specialize a preference according
to an option:
open.url.cmd[pdf] = pdf-viewer
open.url.cmd[jpg] = image-viewer
Signed-off-by: Pierre Mazière <pierre.maziere@gmx.com>
strncpy(3) is not so safe function and can lead to mistakes. For
example, strncpy(dest, "Profanity", 10); is redundant and leads to
problems when someone changes the source string.
Different example is when 3rd argument equals to length of the
destination buffer. strncpy(3) doesn't terminate string with '\0' when
it truncates. Therefore, the destination string becomes corrupted.
Zeroize storage for 'nid', so the last byte remains '\0' in case of
truncate.
Since d92c576aa5
we rely on g_spawn_sync().
Which doesn't do variable/glob expansion.
For our use of call_external() in opening and URL or avatar this is
fine.
For getting the password we want to be able to use ~ for our files.
Let's use a shell here.
Fix https://github.com/profanity-im/profanity/issues/1364
98c38dc6d6
sets C99 as standard.
strdup() is not part of C99.
For now set `-D_POSIX_C_SOURCE=200809L` macro to have strdup() in C99.
Using `gnu99` instead would be another option.
We should take more care to use glib functions whenever possible.
Regards https://github.com/profanity-im/profanity/issues/1357
Found this when looking to fix bug https://github.com/profanity-im/profanity/issues/1357
Not sure if it is related.
man 3 getenv sais:
```
As typically implemented, getenv() returns a pointer to a string within
the environment list. The caller must take care not to modify this
string, since that would change the environment of the process.
```
Some systems don't provide recent libstrophe releases. When older
version of libstrophe is detected, don't build legacy auth support.
To simplify this patch, report about unsupported legacy auth and
keep commands option as is.
Profanity requests the device list and keys for contacts, also when the user
hasn't generated the OMEMO key. If the user has no OMEMO key, there is no need
to request OMEMO information.
Issue: #1332
Memleak was reinroduced in d92c576aa5
It was already fixed in ac5ce105ac
But the rebase peetahs rebase ontop of master took the wrong changes.
I decided to pull anyways and fix since reviewing/giving feedback
without GH probably takes longer.
Fix https://github.com/profanity-im/profanity/issues/1280
p_contact_set_presence() is triggered in
(roster_process_pending_presence) to set the presence to online
after the roster is displayed.
This happened to me _every time_ with one certain account on my server.
But not even once with other accounts on my server.
I don't understand why that is the case, but AFAIK the code should be
like it is in this PR anyways.
roster_process_pending_presence() was added there in
973a05d15a to fix
https://github.com/profanity-im/profanity/issues/1050
NOTE: as per XEP-0060 §12.20, it is RECOMMENDED for the publisher to specify an
ItemID of "current" to ensure that the publication of a new item will overwrite
the existing item.
https://xmpp.org/extensions/xep-0384.html#devices
Issue: 1329
There is code to redraw the ui, because the user may enter a passphase for the
private key. There was also a ui_init, which shouldn't be called, because it
will set the status to the initial state, which is 'offline' and 'no tls'.
Issue: #1327
A autoping is to make sure that there is still a connection between server and
client. If the application receives incoming stanza, the connection is fine.
There is no need to wait for response, if there are other incomings.
Issue: #1333 and #1315
With d1d0ad8d1a 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
In console autocomplete from roster.
In muc autocomplete from occupants lits.
In 1:1 regular chat autocomplete from active resources of currently
selected user (new).
Also give a hint (/help resource) how to set the resource should a user choose that way.
Fix https://github.com/profanity-im/profanity/issues/1337
1f8b1eb740 made it possible to have utf8 chars as correction chars. So since then prefs_get_correction_char() doesn't return a regular char but a char*.
Seems like there was an oversight that we need to use %s then.
For some time users could choose to have the old way "unanimous" where
all the MUC history is just grey (or whatever was set). Now it is always
just displayed like regular new incoming MUC text.
Profanity request the OMEMO Device List for all members, also if the MUC is
anonymouse. If the user is Admin / Owner, the device list will be requtest.
Issue #1315
glib functions can allocate a GError object that must be freed with
g_error_free(). Otherwise a memory leak happens.
There are similar unfixed places in omemo, check:
grep "&error" src/omemo/omemo.c
Fixes#1304.
MUCPMs and regular chat messages get printed with the same code.
But we don't save MUC PMs in the sqldb, because another jid could use
the same nick the next time.
And if we would take the log out we would need a different routine,
checking for resourcepart too.
Fix https://github.com/profanity-im/profanity/issues/1312
Only when we start the conversation.
Not yet when we get messaged and a new window is opened.
Need to have sorting of messages in the window buffer then, I guess.
Also MAM IQ should only be send one time in such a case.
If MAM is enabled history from sql backend will not be shown.
`mam` in profrc enables experimental MAM.
Can change soon again. Don't rely on stuff in this stage ;)
Later we will have several options.
Getting everything since last timestamp (if none everything at all).
Getting everything since today + configure time (1 week).
Should also have a reload all command like conversations once you
cleared the history.
All MAM messages should be written into sql db.
And then probably displayed from there so that regular history works
too.
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.
The function creates a form to find such strings as software, os, etc.
It remembers the strings allocated by form_create() and use them below
in caps_create(). The issue is that the form is destroyed before and as
result the strings are freed too.
As solution, allocate own copy of strings.
Otherwise we print the freshly received message to the window twice.
Once when receiving (and immediately printing), then logging it, and
then again when we print the last 10 log entries.
Fix https://github.com/profanity-im/profanity/issues/1305
Use g_date_time_format() instead of g_date_time_format_iso8601() to only
rely on glib 2.56.0 which is the latest version in Debian Buster
(current stable).
We also only use basic sqlite functions so 3.27.0 should be fine there
(also the one in Debian buster).
Thanks to @DebXWoody.
We now dont get the log files from the text files via chat_log_get_previous() anymore.
We use the sql backend via log_database_get_previous_chat().
So far it just has the same behaviour like chat_log_get_previous(),
except that in _chatwin_history() we don't pass the sender to
win_print_history() which should be fixed in a commit soon.
And log_database_get_previous_chat() can later easily be expanded to fix
https://github.com/profanity-im/profanity/issues/205.
