[Standards] Extending MAM results with results from a transport component

Ivan Vučica ivan at vucica.net
Sun Jul 10 02:12:11 UTC 2016

On Wed, Jul 6, 2016 at 8:44 PM, Florian Schmaus <flo at geekplace.eu> wrote:

> On 06.07.2016 20:42, Ivan Vučica wrote:
> > If I am interpreting XEP-0313 correctly, for person-to-person use case,
> > archive is obtained by inquiring the 'current server'. This is usually
> fine.
> >
> > However, in case of an external transport component communicating with
> > an IM network that can provide its own history, there does not seem to
> > be a viable standardized way to inquire the external component about the
> > additional history.
> Does that component need to act as MAM archive? I would expect messages
> exchanged between a user and a transport component to be stored in the
> users MAM archive. Just like messages between the user and a remote
> server are stored in the MAM archive.

The IM service for which the component is acting as a transport may provide
additional history.

User may exchange additional messages natively via the service, without use
of the XMPP service or the component.

> > [^1]: Most of this mail makes the assumption that component's timestamp
> > is the same as server's component, and that the sort order is based
> > solely on the timestamp.
> BTW: If I where to implement MAM service I think I would ignore any
> timestamps and just store the message stanzas in the order they are put
> in the archive. Because that order is important. Relying on timestamp
> causes all sort of trouble that you likely can't solve in a federated
> system like XMPP (without a central authority).

Sure. But if you ignored timestamps, how would you go about merging
histories while chatting via multiple services? (Point becomes moot if we
go with 'component is authoritative'. No merging necessary.)

On Wed, Jul 6, 2016 at 8:45 PM, Kim Alvefur <zash at zash.se> wrote:

> Treating JIDs from components, especially transports, similar to MUC
> makes some sense here I think.  Both MUC services and transports to
> legacy services are in a better position for having a consistent view of
> the message history, so it makes sense for them to be the authoritative
> source.

That's definitely less complex, although it does seem less useful than
merging histories.

> This does produce more work for clients tho, who will have to somehow
> know which JIDs need to be treated differently, apart from MUCs.

I had service discovery on the component (opt 3) or fulljid (opt 4) in mind.

On Wed, Jul 6, 2016 at 8:54 PM, Dave Cridland <dave at cridland.net> wrote:

> Rapid knee-jerk response:
> * Option 3 is entirely viable, I'm not sure immediately why you'd want
> Option 4, and it would open up a can of Security Considerations.

It feels like marginally less work for client devs while offering ability
to fetch history from other clients, not just components.

However, I agree there feels to be a greater potential for misuse.

> * Bear in mind that messages from the remote network that have been sent
> over XMPP will *also* end up in the user's archive on the server.

Thus the mention of deduplication. :-)

On Wed, Jul 6, 2016 at 8:58 PM, Florian Schmaus <flo at geekplace.eu> wrote:

> Sorry, missed that you where talking about something like IRC
> transports, i.e. transports which (could) provide their own history. Was
> thinking you where talking about ICQ/MSN and the like.

Because MUC use case is solved, I actually had in mind "ICQ/MSN and the
like" -- the person-to-person use case.

Either way, I do not see the difference between IRC, ICQ and MSN; IRC does
not provide history natively either. If anything, if I remember correctly,
MSN had history sync while it existed.

> Yep, that's an unresolved issue. My first reflex would also be option 4.
> But let's see if someone comes up with a more elegant solution.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160710/707cde93/attachment.html>

More information about the Standards mailing list