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

Kim Alvefur 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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160706/163e07e4/attachment.sig>

More information about the Standards mailing list