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

Dave Cridland dave at cridland.net
Wed Jul 6 19:54:59 UTC 2016


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.
* 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.

On 6 July 2016 at 19:42, Ivan Vučica <ivan at vucica.net> wrote:

> Cheers,
>
> 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.
>
> tl;dr skip to option 4.
>
> Thought process:
> - Option 1: Hack the server's mod_mam to take into account any
> capabilities that the external components may advertise. If a component
> advertises MAM, request additional history (e.g. 50 results). Merge and
> sort based on timestamps[^1].
>   - For MAM's Result Set Management-based paging purposes, tracking of
> merged results becomes trickier; if I were implementing it, I'd permanently
> merge the component-provided archive into main server's archive, along with
> timespans that were requested from component (so they can be skipped and
> duplicates further avoided).
>
> - Option 2: Try using XEP-0355 (delegation).
>   - If I am interpreting the XEP correctly, once the namespace is
> delegated, nothing is preventing the main server's internal components from
> also responding.
>   - Just flipping it on for MAM while leaving server's mod_mam active
> initially seems like it might do the trick... except I suspect that the
> duplication of the <iq/> dance as well as paging would pretty strongly
> confuse the client.
>
> - Option 3: Hack clients to discover and use mod_mam on components.
>   - Client separately inquires and tracks paging for the archive from
> internal and external component.
>   - UI layer handles merging (incl. deduplication and sorting based on
> disparate timestamps) and display of the unified history.
>
> - Option 4: Hack clients to discover and use mod_mam on individual
> full-JIDs. Hack the component to advertise MAM on individual full -JIDs.
>   - Additional cap can be advertised by full-JIDs. (No matter if it's from
> a component or not.)
>   - Same additional notes as Option 3 (separate archives + UI does
> merging).
>   - XEP 0313 gets updated for the use case of querying full-JIDs.
>   - full-JID is intentional (because full-JIDs for person-to-person
> communications are already queried about capabilities by clients; and
> hypothetically it /could/ be end-user's client supplying the archive,
> instead of component doing so), but perhaps bare-JID makes more sense?
>
>
> Of these that occurred to me, Option 4 seems most logical.
>
>
> Am I misreading something? Am I missing a XEP? Could I already somehow
> write an external component that can supply MAM on the exposed full JIDs
> for the clients I use -- Conversations, Gajim -- and without modifying the
> server?
>
> Is this a use case that would call for extending 0313 or writing a
> completely new XEP?
>
>  Am I missing some potential security issue?
>
>
> [^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.
>
>
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160706/3f783e4e/attachment.html>


More information about the Standards mailing list