[Standards] Extending MAM results with results from a transport component
zash at zash.se
Wed Jul 6 19:45:00 UTC 2016
On 2016-07-06 20:42, Ivan Vučica wrote:
> - 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?
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
This does produce more work for clients tho, who will have to somehow
know which JIDs need to be treated differently, apart from MUCs.
Kim "Zash" Alvefur
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Standards