Re: [Standards] MAM Sync Strategies

Yes, if you add an already used account to a fresh install of Monal, it will not show any old history. But you can the the "pull to load" feature in an open chat to load old messages not already present in the local history via MAM. While the "before" may not strictly be necessary, it makes the

Re: [Standards] MAM Sync Strategies

I may have misunderstood, but if we're only fetching the last message the first time, do you start out with no history? Also, why set "before" at all if it's only one message, the direction won't matter, no? —Sam On Fri, Aug 27, 2021, at 09:34, Thilo Molitor wrote: > When the user first sets up

Re: [Standards] MAM Sync Strategies

Am Freitag, 27. August 2021, 17:20:17 CEST schrieb Andrew Nenakhov: > пт, 27 авг. 2021 г. в 18:08, Thilo Molitor : > > That's not quite right, you can use XEP-0353 together with XEP-0198 and/or > > XEP-0313 to make VoIP work on iOS. > > No. You can not. > > In a sense that the call recipient has

Re: [Standards] MAM Sync Strategies

пт, 27 авг. 2021 г. в 18:08, Thilo Molitor : > > That's not quite right, you can use XEP-0353 together with XEP-0198 and/or > XEP-0313 to make VoIP work on iOS. > > No. You can not. In a sense that the call recipient has several devices, which all start ringing when the call is incoming and stop

Re: [Standards] MAM Sync Strategies

Am Freitag, 27. August 2021, 13:12:44 CEST schrieb Sam Whited: > Thanks JC! > > You're right, I should have mentioned gaps. It's still possible to > have them in a desktop client because it could always close before it > finishes paging through catching up on history. I had planned to solve >

Re: [Standards] MAM Sync Strategies

Am Freitag, 27. August 2021, 16:03:19 CEST schrieb Philipp Hörist: > Thilo Molitor schrieb am Fr., 27. Aug. 2021, 15:35: > > every MUC catchup delays only "live" message stanzas for that MUC, not > > other MUCs or 1:1). > > How can you delay live messages from a muc ? I filter them by

Re: [Standards] MAM Sync Strategies

Thilo Molitor schrieb am Fr., 27. Aug. 2021, 15:35: > > every MUC catchup delays only "live" message stanzas for that MUC, not > other MUCs or 1:1). > How can you delay live messages from a muc ? Lovetox > ___ Standards mailing list Info:

Re: [Standards] MAM Sync Strategies

Hi Sam et al, for Monal we do something a bit different (a mixture of what you wrote and what JC wrote): When the user first sets up a new account, we query the archive with end= and RSM {max=1, before=""} The stanza-id of this message is then used as sync point the next time Monal has to do

Re: [Standards] MAM Sync Strategies

> Not quite. XEP-0430 is a (rather weak) imitation of the XEP-SYNC which was > already done (and implemented) when Inbox was proposed. It supports > delivered/read/unread messages, active calls in chat (without it, VoIP > calls won't work on iOS) That's not quite right, you can use XEP-0353

Re: [Standards] MAM Sync Strategies

On 27.08.21 13:12, Sam Whited wrote: Thanks JC! You're right, I should have mentioned gaps. It's still possible to have them in a desktop client because it could always close before it finishes paging through catching up on history. I had planned to solve that by either switching to committing

Re: [Standards] MAM Sync Strategies

On 27.08.21 13:12, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 16:03, JC Brand >: If the site allows users to show multiple chats side-by-side then you can't discard chat history. Ok, so you have users that use so many simultaneous chats and scroll

Re: [Standards] MAM Sync Strategies

Thanks JC! You're right, I should have mentioned gaps. It's still possible to have them in a desktop client because it could always close before it finishes paging through catching up on history. I had planned to solve that by either switching to committing the entire query in one transaction, or

Re: [Standards] MAM Sync Strategies

пт, 27 авг. 2021 г. в 16:03, JC Brand : > > If the site allows users to show multiple chats side-by-side then you > can't discard chat history. > Ok, so you have users that use so many simultaneous chats and scroll them up and down that fast, so you can't ever dump the messages starting from,

Re: [Standards] MAM Sync Strategies

On 27.08.21 12:56, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 15:53, JC Brand >: I know from professional experience that you can reach the 5MB limit with an integrated webchat of the type I mentioned. then just discard chat history (bar the last

Re: [Standards] MAM Sync Strategies

пт, 27 авг. 2021 г. в 15:53, JC Brand : > > I know from professional experience that you can reach the 5MB limit with > an integrated webchat of the type I mentioned. > then just discard chat history (bar the last message) you haven't touched in a while. Loading history from the archive again is

Re: [Standards] MAM Sync Strategies

пт, 27 авг. 2021 г. в 14:52, Holger Weiß : > * Andrew Nenakhov [2021-08-27 14:45]: > >our quick sync protocol that loads every first message from all chats, > > This sounds like a non-standard replacement for XEP-0430: Inbox? > Not quite. XEP-0430 is a (rather weak) imitation of the XEP-SYNC

Re: [Standards] MAM Sync Strategies

On 27.08.21 12:20, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 14:52, JC Brand >: Converse is made so that it can be integrated into a website where the user might be clicking many links and navigate throughout the site, thereby causing the page to

Re: [Standards] MAM Sync Strategies

пт, 27 авг. 2021 г. в 14:52, JC Brand : > Converse is made so that it can be integrated into a website where the > user might be clicking many links and navigate throughout the site, thereby > causing the page to regularly refresh/reload. If you don't cache/store the > messages somewhere, you'll

Re: [Standards] MAM Sync Strategies

On 27.08.21 11:45, Andrew Nenakhov wrote: пт, 27 авг. 2021 г. в 12:59, JC Brand >: Webclients have restrictions that others don't, so while what you wrote makes sense, I do something a bit different with Converse. Web clients do not need to store

Re: [Standards] MAM Sync Strategies

* Andrew Nenakhov [2021-08-27 14:45]: our quick sync protocol that loads every first message from all chats, This sounds like a non-standard replacement for XEP-0430: Inbox? Holger ___ Standards mailing list Info:

Re: [Standards] MAM Sync Strategies

пт, 27 авг. 2021 г. в 12:59, JC Brand : > > Webclients have restrictions that others don't, so while what you wrote > makes sense, I do something a bit different with Converse. > Web clients do not need to store messages locally at all, they can just load everything when a user goes to a dialog

Re: [Standards] MAM Sync Strategies

Hi Sam et al Webclients have restrictions that others don't, so while what you wrote makes sense, I do something a bit different with Converse. First, depending on the type of storage used (sessionStorage vs localStorage vs IndexedDB), a webclient can easily run into a storage limit (around

Re: [Standards] MAM Sync Strategies

* Andrew Nenakhov [2021-08-09 17:22]: JFYI, We have developed and implemented a sync protocol that does this almost instantly and load all chats in reverse chronological order. Here is a video of how it looks

Re: [Standards] MAM Sync Strategies

In case anyone else is interested in documenting their MAM strategy, please consider editing this page: https://docs.modernxmpp.org/client/sync/ Thanks! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:

Re: [Standards] MAM Sync Strategies

JFYI, We have developed and implemented a sync protocol that does this almost instantly and load all chats in reverse chronological order. Here is a video of how it looks immediately after login, recorded just now, in

[Standards] MAM Sync Strategies

Hi all, I started a PR against modernxmpp to document MAM sync strategies after a discussion on jdev yesterday: https://github.com/modernxmpp/modernxmpp/pull/41 I wondered if anyone would share what their sync strategy is (or even possibly add it to that PR) so that we can document a few

Re: [Standards] MAM Corner Cases: MUC-PMs and Self-Messages

On Feb 21, 2018 19:05, "Georg Lukas" wrote: Hi, Philipp H. pointed out an interesting issue today: MUC-PMs are sent by a MUC to all joined client full-JIDs, so if you are joined to a MUC with two devices, your account will see two copies of the messages. Your MAM archive is also

[Standards] MAM Corner Cases: MUC-PMs and Self-Messages

Hi, Philipp H. pointed out an interesting issue today: MUC-PMs are sent by a MUC to all joined client full-JIDs, so if you are joined to a MUC with two devices, your account will see two copies of the messages. Your MAM archive is also going to store two copies of them, with different MAM-IDs,

Re: [Standards] MAM: misleading archiving node in examples

On 21.02.2017 22:00, Kim Alvefur wrote: Hi, On Tue, Feb 21, 2017 at 09:35:51PM +0100, Ruslan N. Marchenko wrote: If I understand it right - in absence of 'to' attribute on c2s - the server itself is assumed as a recipient - i.e. == . No, the current account is assumed, so ... In MAM case

Re: [Standards] MAM: misleading archiving node in examples

Hi, On Tue, Feb 21, 2017 at 09:35:51PM +0100, Ruslan N. Marchenko wrote: > In the examples across XEP-0313 the IQs are all to-less. > > If I understand it right - in absence of 'to' attribute on c2s - the server > itself is assumed as a recipient - i.e. == id='1'/>. No, the current account is

[Standards] MAM: misleading archiving node in examples

Good evening, In the examples across XEP-0313 the IQs are all to-less. If I understand it right - in absence of 'to' attribute on c2s - the server itself is assumed as a recipient - i.e. == to='example.org' id='1'/>. In MAM case archiving node for the user is user's bare jid - hence

Re: [Standards] MAM: Conflicting storage prefs behaviour

On 20 February 2017 at 20:47, Ruslan N. Marchenko wrote: > On 19.02.2017 22:49, Matthew Wild wrote: >> >> An example implementation of storage de-duplication, let's say you >> have two users: userA and userB. >> >> userA sends a message to userB, which the server archives, because

Re: [Standards] MAM things in MIX RE: MIX (XEP-0369) post-summit update to 0.8

* Steve Kille [2017-02-20 03:05]: > > - From that it sounds like "both". > [Steve Kille] > > Jonas - this is spot on. > > In my view, the text is clear, so I am not going to make any changes. It would be great to have that replicated in the §3.4 "MIX and MAM" section,

[Standards] MAM things in MIX RE: MIX (XEP-0369) post-summit update to 0.8

Georg submitted some comments on this and Jonas provided a useful response. So, this message is responding to Jonas's reply to Georg's original message. > -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Jonas > Wielicki > Sent: 16 February 2017 19:33

Re: [Standards] MAM: Conflicting storage prefs behaviour

Hi Ruslan, On 19 February 2017 at 13:48, Ruslan N. Marchenko wrote: > Good afternoon, > > > I'm preparing implementation of the mam and since there're very few details > in the XEP-0313 about actual archiving, mostly about querying - i believe > the archiving process is then left

[Standards] MAM: Conflicting storage prefs behaviour

Good afternoon, I'm preparing implementation of the mam and since there're very few details in the XEP-0313 about actual archiving, mostly about querying - i believe the archiving process is then left at the discretion of the implementers. Now, to avoid storing multiple copies of the

Re: [Standards] MAM: Adding stanza-id to archived messages

Mon, 31 Oct 2016 17:10:24 +0100 Daniel Gultsch wrote: > The by attribute should contain the archiving entity. For regular > users the archiving entity is the user account itself. This was not clear for me. And is still unclear what "archiving entity" means. That's why I put

Re: [Standards] MAM: Adding stanza-id to archived messages

The by attribute should contain the archiving entity. For regular users the archiving entity is the user account itself. Meaning the bare jid of the user. Compare that to the mam disco feature which is also announced at the bare jid of the user (see discovery in the MAM xep). The mam query is also

Re: [Standards] MAM: Adding stanza-id to archived messages

On 31.10.2016 17:02, Florian Schmaus wrote: > On 30.10.2016 08:19, Daniel Gultsch wrote: >> I created a PR[1] to add stanza-ids to archived MAM messages. >> … >> Ejabberd already adds the id (but with a wrong by attribute IIRC) … > > I assume ejabberd does/did use the XMPP domain of the service,

Re: [Standards] MAM: Adding stanza-id to archived messages

On 30.10.2016 08:19, Daniel Gultsch wrote: > I created a PR[1] to add stanza-ids to archived MAM messages. > … > Ejabberd already adds the id (but with a wrong by attribute IIRC) … I assume ejabberd does/did use the XMPP domain of the service, and not the user's bare JID, as value of the 'by'

[Standards] MAM: Adding stanza-id to archived messages

I created a PR[1] to add stanza-ids to archived MAM messages. This PR brings the old back but as a defined in XEP-0359. This PR only influence the live incoming messages and doesn't change the syntax of regular interaction with MAM. It also doesn't include a namespace bump and is purely

Re: [Standards] MAM and MUC archives

Hi Mickaël, On 27 Jul 2015, at 12:14, Mickaël Rémond mrem...@process-one.net wrote: I need a few questions to clarify the behaviour of the MAM XEP in the context of the MUC archives. Are we supposed to send the MAM queries to the MUC service or to the room itself ? To the room. 2. If

Re: [Standards] MAM and MUC archives

On 27 Jul 2015, at 14:38, Evgeny Khramtsov xramt...@gmail.com wrote: Mon, 27 Jul 2015 14:05:34 +0100 Kevin Smith kevin.sm...@isode.com wrote: Yes, “”” 3.2 MUC archives A MUC service allowing MAM queries for a room MUST expose the MAM archive on the room's bare JID “”” This is

Re: [Standards] MAM and MUC archives

Mon, 27 Jul 2015 12:32:48 +0100 Kevin Smith kevin.sm...@isode.com wrote: To the room. Will it be defined in the spec? Because it's not very obvious.

Re: [Standards] MAM and MUC archives

Hiya, On 27 Jul 2015, at 12:38, Evgeny Khramtsov xramt...@gmail.com wrote: Mon, 27 Jul 2015 12:32:48 +0100 Kevin Smith kevin.sm...@isode.com wrote: To the room. Will it be defined in the spec? Because it's not very obvious. Yes, “”” 3.2 MUC archives A MUC service allowing MAM queries

[Standards] MAM and MUC archives

Hello, I need a few questions to clarify the behaviour of the MAM XEP in the context of the MUC archives. Are we supposed to send the MAM queries to the MUC service or to the room itself ? 1. If we send to the MUC service, I think we need to send a with filter to get message from a given

Re: [Standards] MAM and MUC archives

Mon, 27 Jul 2015 14:05:34 +0100 Kevin Smith kevin.sm...@isode.com wrote: Yes, “”” 3.2 MUC archives A MUC service allowing MAM queries for a room MUST expose the MAM archive on the room's bare JID “”” This is still unclear. It's only said that a service allows MAM queries for a room, but

[Standards] MAM ids on new messages to prevent deduping

In implementing MAM in clients there can be a case where MAM results contain duplicates of already seen messages. In order to prevent such duplication, the MAM ID for a stanza would need to appear on a newly generated non-MAM stanza. As background, imagine a client which, when

Re: [Standards] MAM ids on new messages to prevent deduping

Leaving backward compatibility concerns aside, I'd like to see globally unique message IDs made compulsory instead of optional and to use the original message ID as the MAM ID. This is what we are doing in our closed-client environment and it works well, but sacrifices compatibility with other

Re: [Standards] MAM ids on new messages to prevent deduping

I don’t think it makes sense to require clients to generate globally unique IDs. In a closed environment you can do what you want, but it seems onerous to require that for arbitrary clients (many of which don’t include any ID on messages, let alone globally unique ones). -bjc On

Re: [Standards] MAM ids on new messages to prevent deduping

[I’m worried that my original message is getting derailed here, but I’ll continue with this thread for a little longer] Even were it simple, you cannot trust clients to generate UUIDs for purposes such as MAM or any other “trusted” ID source. It becomes trivial for ill-behaved

Re: [Standards] MAM ids on new messages to prevent deduping

On 11 May 2015 at 16:25, Brian Cully bcu...@gmail.com wrote: In implementing MAM in clients there can be a case where MAM results contain duplicates of already seen messages. In order to prevent such duplication, the MAM ID for a stanza would need to appear on a newly generated

Re: [Standards] MAM ids on new messages to prevent deduping

On 11.05.2015 17:25, Brian Cully wrote: In implementing MAM in clients there can be a case where MAM results contain duplicates of already seen messages. In order to prevent such duplication, the MAM ID for a stanza would need to appear on a newly generated non-MAM stanza. As

Re: [Standards] MAM and Pubsub

On 3 Feb 2015 11:58, Goffi go...@goffi.org wrote: Having a node attribute is defined in 313 as specifying you want to search a pubsub archive instead of another type of archive. I don't see the confusion. It's explained in XEP-0313, but I think it's a bad idea to use common terminology to

Re: [Standards] MAM and Pubsub

On 03/02/2015 15:46, Dave Cridland wrote: We can work around this in namespace delegation by adding an attribute check in addition to namespace check, that would be better than sending back the traffic to the server, even if it complicate the XEP. I would still be more happy with an other

Re: [Standards] MAM and Pubsub

Having a node attribute is defined in 313 as specifying you want to search a pubsub archive instead of another type of archive. I don't see the confusion. It's explained in XEP-0313, but I think it's a bad idea to use common terminology to associate MAM with an other XEP, without namespace.

Re: [Standards] MAM and Pubsub

On 03/02/15 11:05, Goffi wrote: G'day, I have an issue that I mentioned in Brussel to Matthew with using MAM (XEP-0313) for PubSub (XEP-0060)/PEP (XEP-0163). Today to query a PubSub node with MAM, we need to do (according to section 4): iq to='pubsub.shakespeare.lit' type='set'

[Standards] MAM and Pubsub

G'day, I have an issue that I mentioned in Brussel to Matthew with using MAM (XEP-0313) for PubSub (XEP-0060)/PEP (XEP-0163). Today to query a PubSub node with MAM, we need to do (according to section 4): iq to='pubsub.shakespeare.lit' type='set' id='juliet1' query xmlns='urn:xmpp:mam:0'

[Standards] MAM Offline messages

Hello folks, I am wondering what should happen if server has no support of offline messages storage but does have support of MAM and someone sends offline message, should server send back service-unavailable or not? Thanks.

[Standards] MAM IDs

In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question - are these useful? Are clients going to ignore them and just request all history since they last requested it anyway? /K

Re: [Standards] MAM IDs

If you mean the archived element: archived by='jul...@capulet.lit’ id=‘28482-98726-73623' / I personally have not found any need for it. Regards Spencer On 17 Feb 2014, at 10:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that

Re: [Standards] MAM IDs

On Mon, Feb 17, 2014 at 10:42 AM, Spencer MacDonald spencer.macdonald.ot...@gmail.com wrote: If you mean the archived element: archived by='jul...@capulet.lit' id='28482-98726-73623' / I personally have not found any need for it. Thanks. /K

Re: [Standards] MAM IDs

On Mon, Feb 17, 2014 at 10:26 AM, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question - are these useful? Are clients going to ignore them and just request

Re: [Standards] MAM IDs

On 17 feb. 2014, at 11:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question - are these useful? Are clients going to ignore them and just request all

Re: [Standards] MAM IDs

I just used XEP-0202 to get around the wrong time issue. I have only been to dealing with storing messages that people type and send, so the chance of multiple messages in (very) quick succession wasn’t an issue for me. Regards Spencer On 17 Feb 2014, at 10:55, Thijs Alkemade

Re: [Standards] MAM IDs

On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade th...@xnyhps.nl wrote: On 17 feb. 2014, at 11:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM, stanzas stored get stamped with a MAM ID by the entity that stored them, and entities receiving them then receive this. So a general question -

Re: [Standards] MAM IDs

On Mon, Feb 17, 2014 at 11:42 AM, Thijs Alkemade th...@xnyhps.nl wrote: On 17 feb. 2014, at 12:02, Kevin Smith ke...@kismith.co.uk wrote: On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade th...@xnyhps.nl wrote: On 17 feb. 2014, at 11:26, Kevin Smith ke...@kismith.co.uk wrote: In MAM,

Re: [Standards] MAM

On Fri Feb 10 23:06:48 2012, Peter Saint-Andre wrote: On 2/10/12 2:59 PM, Matthew Wild wrote: That said, you can consider even what is there a contribution to the community, and if people really think it's worthy of submission in its current state then I won't hold it back. I suggest

[Standards] MAM

On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote: On 01/12/2012 01:41 AM, Kim Alvefur wrote: On Tue, 2012-01-10 at 17:33 +0700, Sergey Dobrov wrote: Matt Wild's upcoming archiving spec is a good candidate for this. /K Where I can take a look on it? Here:

Re: [Standards] MAM

On 2/10/12 12:01 PM, Kim Alvefur wrote: On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote: On 01/12/2012 01:41 AM, Kim Alvefur wrote: On Tue, 2012-01-10 at 17:33 +0700, Sergey Dobrov wrote: Matt Wild's upcoming archiving spec is a good candidate for this. /K Where I can take a look on

Re: [Standards] MAM

On 2/10/12 2:59 PM, Matthew Wild wrote: On 10 February 2012 21:09, Peter Saint-Andre stpe...@stpeter.im wrote: On 2/10/12 12:01 PM, Kim Alvefur wrote: On Thu, 2012-01-12 at 15:09 +0700, Sergey Dobrov wrote: On 01/12/2012 01:41 AM, Kim Alvefur wrote: On Tue, 2012-01-10 at 17:33 +0700, Sergey