Re: [Standards] MAM Sync Strategies

[Thilo Molitor]

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 intention of 
the code clearer.

-tmolitor


Am Samstag, 28. August 2021, 03:01:00 CEST schrieb Sam Whited:
> 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 a new account, we query the archive with
> > end= and RSM {max=1, before=""}
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Sam Whited]

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 a new account, we query the archive with
> end= and RSM {max=1, before=""}
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Thilo Molitor]

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 several devices, which all start
> ringing when the call is incoming and stop ringing immediately after the
> call is picked or reclined on one device, or when it is cancelled by the
> caller.
> (further complicated if caller sends something)

I'll show you how it CAN be done as soon as I come along implementing the 
WebRTC based VoIP that Conversations et al use.
Without the need to invent new XEPs even for iOS.



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[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 several devices, which all start
ringing when the call is incoming and stop ringing immediately after the
call is picked or reclined on one device, or when it is cancelled by the
caller.
(further complicated if caller sends something)

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Thilo Molitor]

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
> that by either switching to committing the entire query in one
> transaction, or changing from using the last message for the sync
> query to using a separate "last message pointer" that gets updated
> only after the entire transaction is over.

In Monal we have this "last message pointer", too, but update it every time a 
new raw stanza comes in (e.g. also for "live" messages AND mam-catchup 
messages).
If the app gets killed in between processing a mam page, we just start our mam 
catchup from this point going forward (or continue the old mam query as if 
nothing happened, if the XEP-0198 session was still resumable).

Each incoming stanza lives in its own db transaction (including the update to 
the XEP-0198 counters), making it possible to resume processing of a half 
processed stanza when resuming the XEP-0198 session.
--> you can kill and restart the app as often as you like without ever loosing 
messages (as long as I did not make any implementation errors, of course).

- tmolitor




___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Thilo Molitor]

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 type=="groupchat" and from (without resource) == , put them into a ordered list in my database and process that list when 
the MAM catchup is complete (before starting to process "live" message stanzas 
again).

- tmolitor


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[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 ?

Lovetox

>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Thilo Molitor]

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 a catchup via MAM (e.g. no XEP-0198 resume, which Monal is capable 
of even if the device was restarted or the app killed etc.).
This sync-point will be updated to the newest stanza-id for every incoming 
message.

For the catchup we just query everthing with RSM {after=, max=50} and page through all results.
We delay processing of all incoming 1:1 "live" message stanzas while doing the 
MAM catchup to make sure the message order is preserved for OMEMO etc.

Once the MAM catchup is done, all queried "live" message stanzas are 
processed.

We do the same for every MUC catchup (every MUC has its own sync-point of 
course; every MUC catchup delays only "live" message stanzas for that MUC, not 
other MUCs or 1:1).

If we get item-not-found for a catchup query, we will query the whole archive.

Most of the time the XEP-0198 session will be resumed by Monal, MAM catchups 
are really rare.

- tmolitor



Am Freitag, 27. August 2021, 09:57:32 CEST schrieb JC Brand:
> 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 5MB for localStorage).
> IndexedDB doesn't have a storage limit, but you can't always assume that
> it's available (e.g. it's not in incognito mode in Safari) or desirable
> to use it.
> 
> Additionally, the user can at any time navigate away from the tab or
> reload the tab, thereby interrupting the process of populating the archive.
> 
> In theory this second problem can be solved by using a shared worker,
> which can still populate the history in the background (I've added
> support to Strophe.js), but Safari doesn't support shared workers and
> they bring other complications and considerations.
> 
> So, instead of fetching the history for every contact in the roster, I
> only do so for open chats (i.e. ongoing 1:1 and MUC conversations).
> 
> If there are no messages in the history, I do a reverse order query
> using "before" set to an empty string together with a configurable limit
> (similarly to how you do it).
> 
> If there are messages in the history, I set "after" to the stanza-id of
> the most recent message. Now of course there might be more messages than
> might fit on the returned MAM page. Whether Converse will fetch the
> other pages is configurable, and depends on whether it has limited
> storage or not. In the case where storage is limited, Converse should be
> configured to not fetch all subsequent pages. This creates a gap in the
> history. In the soon-to-be-released Converse 8, I create a special gap
> indicator, which is shown to the user in the chat history, to indicate
> that there are missing messages. The user can click on this indicator,
> to fill it with a new MAM query.
> 
> The potential presence of gaps and how to deal with them is something
> that I don't see mentioned in Sam's description. Probably because with a
> desktop client you can just fetch all messages and don't have to worry
> about gaps.
> 
> Then there's also an edge case, where there is a message history, but
> for some reason we don't have a stable stanza-id. In that case, I get
> the time of the most recent message (taking into account a possible
>  element), and then I do a "before" query set to that date.
> 
> For those who might be interested, here's the code that implements the
> logic described above:
> https://github.com/conversejs/converse.js/blob/8d62c2b103f70e0a1e82787b5c464
> e8b2d53cc01/src/headless/plugins/mam/utils.js#L201
> 
> Regards
> JC
> 
> On 09.08.21 13:46, Sam Whited wrote:
> > 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 clients and
> > maybe move towards an XEP that outlines one or two ideal ones?
> > 
> > I'll start with the one I described in the chat yesterday that's used
> > (experimentally) by Mellium/Communiqué:
> > 
> > On client start iterate through all items in the roster. If no messages
> > exist in the local archive: Query in reverse order (in case the server
> > breaks it up by page and we end up committing pages separately) with
> > before: now && limit: X (where X is some configurable number, what we
> > think will fit on the page with some margin, etc.). Otherwise query with
> > after-id:  (making sure that the last message was pulled
> > from the 

Re: [Standards] MAM Sync Strategies

[Thilo Molitor]

> 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 together with XEP-0198 and/or 
XEP-0313 to make VoIP work on iOS.

@all: XEP-0353 needs something like "this should be stored in mam, too" to 
make it work flawlessly, right?
Of course,as a sender, you can always add a XEP-0334 store processing hint, 
but this should be made somehow mandatory imho.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[JC Brand]

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 the entire query in one
transaction, or changing from using the last message for the sync
query to using a separate "last message pointer" that gets updated
only after the entire transaction is over. If for any reason there is
a gap, this would effectively be the "there's a gap here" pointer
because you'd see that there existed messages after the last message
pointer. You could then fill it, or add a marker as you've done. I
haven't decided what's best yet, so I don't have this implemented
right now, but it's on my list.


FWIW I've seen markers in Slack, on Twitter and on Mastodon. So they're 
a relatively established UX paradigm.





___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[JC Brand]

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 
them up and down that fast, so you can't ever dump the messages 
starting from, say, 20th? Those are mightily rabid users, I must say!


For reasons not worth going into, we disabled infinite scrolling to 
fetch older messages, so it's not so simple to just restrict the history 
and then let users scroll up to fetch older messages.


Obviously this doesn't apply to most other use-cases, but my point is 
that it's dangerous to make assumptions that it's "easy" to just do X 
and that you never need to cache messages in a webclient.


I'm sure you can get quite far by never caching messages locally, but 
you are then also restricting yourself to certain use-cases. If you 
decide to cache messages locally, then you have other tradeoffs to 
contend with. Converse has always cached messages locally and it's 
worked well over the years.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[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
that by either switching to committing the entire query in one
transaction, or changing from using the last message for the sync
query to using a separate "last message pointer" that gets updated
only after the entire transaction is over. If for any reason there is
a gap, this would effectively be the "there's a gap here" pointer
because you'd see that there existed messages after the last message
pointer. You could then fill it, or add a marker as you've done. I
haven't decided what's best yet, so I don't have this implemented
right now, but it's on my list.

—Sam

On Fri, Aug 27, 2021, at 03:57, JC Brand wrote:
> The potential presence of gaps and how to deal with them is something
> that I don't see mentioned in Sam's description. Probably because with
> a desktop client you can just fetch all messages and don't have to
> worry about gaps.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Andrew Nenakhov]

пт, 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,
say, 20th? Those are mightily rabid users, I must say!




-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[JC Brand]

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 message) you haven't 
touched in a while. Loading history from the archive again is fast 
enough anyway, with any decent xmpp server.


If the site allows users to show multiple chats side-by-side then you 
can't discard chat history.


Also if users quickly switch between multiple chats in a single widget, 
they complain if there is a noticeable delay before showing the history 
(which happens if messages need to be fetched again from the server).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Andrew Nenakhov]

пт, 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 fast enough anyway,
with any decent xmpp server.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Andrew Nenakhov]

пт, 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 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), provides archived/unarchived/pinned statuses,
muting conversations (and is responsible for sending out push notifications
only to NOT muted conversations, etc.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[JC Brand]

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 regularly refresh/reload. If you
don't cache/store the messages somewhere, you'll have to refetch
them every single time the page loads, which is wasteful and
causes notable delays.

So no, you can't always just load everything from the server.


Well, if you intend to work as a widget, you'll hardly exceed 5MB 
local storage limit.


I know from professional experience that you can reach the 5MB limit 
with an integrated webchat of the type I mentioned.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Andrew Nenakhov]

пт, 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 have to refetch them every single time the page
> loads, which is wasteful and causes notable delays.
>
> So no, you can't always just load everything from the server.
>

Well, if you intend to work as a widget, you'll hardly exceed 5MB local
storage limit.

Also, we have a similarly working demo of our group chat tech made out to
work as a support chat widget: http://connector.chat/

it reloads almost instantly after each page reload (and even remembers the
position if it was moved to another place), reloading everything from the
archive. You may try it now, if you want.



-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[JC Brand]

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 messages locally at all, they can 
just load everything when a user goes to a dialog that he didn't load 
before. The only exception to this we've found is OMEMO messages. For 
them and their keys we use lndexedDB.


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 have to refetch them every 
single time the page loads, which is wasteful and causes notable delays.


So no, you can't always just load everything from the server.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[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?

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Andrew Nenakhov]

пт, 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 that he didn't load before.
The only exception to this we've found is OMEMO messages. For them and
their keys we use lndexedDB.

Of course, we have sopport of our quick sync protocol that loads every
first message from all chats, clients that do not have it would have to do
requests to fetch at least 1 message for each contact in a roster. We had
this functionality, worked, as expected, far from ideal, so we eventually
scrapped it.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[JC Brand]

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 5MB for localStorage).
IndexedDB doesn't have a storage limit, but you can't always assume that 
it's available (e.g. it's not in incognito mode in Safari) or desirable 
to use it.


Additionally, the user can at any time navigate away from the tab or 
reload the tab, thereby interrupting the process of populating the archive.


In theory this second problem can be solved by using a shared worker, 
which can still populate the history in the background (I've added 
support to Strophe.js), but Safari doesn't support shared workers and 
they bring other complications and considerations.


So, instead of fetching the history for every contact in the roster, I 
only do so for open chats (i.e. ongoing 1:1 and MUC conversations).


If there are no messages in the history, I do a reverse order query 
using "before" set to an empty string together with a configurable limit 
(similarly to how you do it).


If there are messages in the history, I set "after" to the stanza-id of 
the most recent message. Now of course there might be more messages than 
might fit on the returned MAM page. Whether Converse will fetch the 
other pages is configurable, and depends on whether it has limited 
storage or not. In the case where storage is limited, Converse should be 
configured to not fetch all subsequent pages. This creates a gap in the 
history. In the soon-to-be-released Converse 8, I create a special gap 
indicator, which is shown to the user in the chat history, to indicate 
that there are missing messages. The user can click on this indicator, 
to fill it with a new MAM query.


The potential presence of gaps and how to deal with them is something 
that I don't see mentioned in Sam's description. Probably because with a 
desktop client you can just fetch all messages and don't have to worry 
about gaps.


Then there's also an edge case, where there is a message history, but 
for some reason we don't have a stable stanza-id. In that case, I get 
the time of the most recent message (taking into account a possible 
 element), and then I do a "before" query set to that date.


For those who might be interested, here's the code that implements the 
logic described above:

https://github.com/conversejs/converse.js/blob/8d62c2b103f70e0a1e82787b5c464e8b2d53cc01/src/headless/plugins/mam/utils.js#L201

Regards
JC



On 09.08.21 13:46, Sam Whited wrote:

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 clients and
maybe move towards an XEP that outlines one or two ideal ones?

I'll start with the one I described in the chat yesterday that's used
(experimentally) by Mellium/Communiqué:

On client start iterate through all items in the roster. If no messages
exist in the local archive: Query in reverse order (in case the server
breaks it up by page and we end up committing pages separately) with
before: now && limit: X (where X is some configurable number, what we
think will fit on the page with some margin, etc.). Otherwise query with
after-id:  (making sure that the last message was pulled
from the DB before we send initial presence).

If the user scrolls to the top of the history, query in reverse order
with before-id: . Fetch the next page for as long as they
continue to scroll up.

Thanks,
Sam



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Holger Weiß]

* 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 immediately after login, recorded just now, in real time
with no editing.

For every conversation, it syncs the most recent message, amount of unread
messages, delivered / displayed markers. In the future, it'll also sync
mute / archived / pinned / special notification states.


Glad to hear you're building superior solutions.  I suppose this is 
based on some custom spec of yours?  If so, do you have any plans to 
suggest it as a standard extension?  If you don't, how's this supposed 
to help anyone on this list?


Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Sam Whited]

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: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

[Andrew Nenakhov]

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 real time
with no editing.

For every conversation, it syncs the most recent message, amount of unread
messages, delivered / displayed markers. In the future, it'll also sync
mute / archived / pinned / special notification states.

пн, 9 авг. 2021 г. в 16:51, Sam Whited :

> 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 clients and
> maybe move towards an XEP that outlines one or two ideal ones?
>
> I'll start with the one I described in the chat yesterday that's used
> (experimentally) by Mellium/Communiqué:
>
> On client start iterate through all items in the roster. If no messages
> exist in the local archive: Query in reverse order (in case the server
> breaks it up by page and we end up committing pages separately) with
> before: now && limit: X (where X is some configurable number, what we
> think will fit on the page with some margin, etc.). Otherwise query with
> after-id:  (making sure that the last message was pulled
> from the DB before we send initial presence).
>
> If the user scrolls to the top of the history, query in reverse order
> with before-id: . Fetch the next page for as long as they
> continue to scroll up.
>
> Thanks,
> Sam
>
> --
> Sam Whited
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>


-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___