[09:57:52]
<moul> Thanks for the PR!
[10:02:03]
<Maranda> moul, np
[10:08:13]
<moul> There is one bug I am still encountering. Let’s see if v3.11 and the new configuration file will fix it.
In 1:1 conversations, with contacts which are using the mobile network and Conversations app, they are displayed online, but they are apparently not.
So, the message is sent, but not resent (MAM).
I don’t get a confirmation mark from poezio.
Sorry, my explaination is a bit shitty. I could explain it to you one more time.
[10:13:39]
<Maranda> moul: that's normal it's cause of stream management.
[10:14:51]
<Maranda> If they disconnect because of unstable data network or OS socket limitations, the server will wait 6 minutes before terminating a session
[10:17:45]
<moul> Ok, then it’s that normal that we are loosing messages? Can something be done to prevent this loss?
As I remember, I wasn’t experimenting this issue with Prosody 0.10.
[10:18:29]
<Maranda> moul, MAM is not affected
[10:18:38]
<Maranda> It never is
[10:19:10]
<moul> Sorry, what do you mean?
[10:19:49]
<Maranda> Messages are still recorded by MAM
[10:20:36]
<moul> Ok, so this problem should not happen with a working MAM. The new configuration file should fix it.
[10:22:45]
<Maranda> I don't think the config file itself will fix anything
[10:22:58]
<Maranda> @version moul.re
[10:22:59]
<moul> Ok
[10:23:00]
<Echo1> Maranda: moul.re is running Metronome version 3.10.14 on Linux
[10:26:43]
<Maranda> moul: just saying that "Conversations app, they are displayed online, but they are apparently not.
So, the message is sent, but not resent (MAM)" is not related to MAM as long as you can't actually see those messages in the archive.
[10:29:59]
<moul> Ok.
[10:34:02]
<moul> “Metronome by default doesn't enable logging despite the module being enabled clients need to explicitly configure prefs to enable logging (that also better conforms to GDPR).”
What does it mean? Should a client enable something? Allows to be logged to enable MAM in relation to GDPR?
[10:36:00]
<moul> Ok, I would be interested to watch the server archive to identify the issue, but I don’t know where are is it stored with the LDAP integration.
[10:36:54]
<Maranda> moul do you have Gajim?
[10:37:40]
<Maranda> You can retrieve the archive using the XML console, and verify that it has all messages.
[10:38:01]
<moul> Yes
[10:39:26]
<Maranda> when the issue happens just go in Gajim, open the xml console and input:
<iq type='set' id='juliet1'>
<query xmlns='urn:xmpp:mam:2' queryid='f27' />
</iq>
[10:40:12]
<Maranda> although I may have identified a possible issue, I don't think that's what is affecting you
[10:40:22]
<Maranda> since that module isn't enabled
[11:30:58]
<Maranda> moul, I just tested your scenario and the archive remains consistent
[11:37:11]
<Maranda> (aka failing to resume and then reconnecting)
[11:39:04]
<Maranda> there found what is the actual bug
[11:43:39]
<moul> Ok, cool !
[12:14:10]
<moul> Ah, and btw, you can directly discuss with YunoHost team on xmpp://dev@conference.yunohost.org rather than on the support chatroom which is more for people which need support.
[12:19:25]
<Curator> ok, and fixed
[12:36:16]
<Echo1> maranda committed --
mam.lib: cleanup a bit.
-> https://github.com/maranda/metronome/commit/24db630d2dfd55b4ed516833884021f209b58d31
[12:36:17]
<Echo1> maranda committed --
mam.lib: correct handling of offline caches.
-> https://github.com/maranda/metronome/commit/e0216db6431c365d696869a3647ef87b541c3f34
[16:48:20]
<moul> metronome.im is running Metronome version 3.11.0 on something which is not your bussness < mistake "business".
[20:41:18]
<Maranda> moul, that's typo'ed on purpose btw
[21:06:37]
<Maranda> @xep 156
[21:06:37]
<Echo1> Maranda: XEP-0156: Discovering Alternative XMPP Connection Methods is Standards Track (Draft, Make JSON example less error-prone.) See: https://xmpp.org/extensions/xep-0156.html