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-unsubscr...@xmpp.org _______________________________________________
