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 <i...@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-unsubscr...@xmpp.org > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
