[Standards] NEW: XEP-0313 (Message Archive Management)

Kevin Smith kevin at kismith.co.uk
Fri Apr 20 08:32:56 UTC 2012


On Thu, Apr 19, 2012 at 6:01 PM, Matthew Wild <mwild1 at gmail.com> wrote:
> One solution I came up with was for an entity that relays and archives
> messages to stamp the message with: <archived by="capulet.lit"
> id="1234-5678"/> or <archived by="conference.jabber.org"
> id="8765-4321"/>. I'd be interested in feedback on this idea.

Yes, we need (archiving, rather than stanza) ids stamped on the
archived stanzas.

> However even <archived/> doesn't cover the case of the client knowing
> the id of its *outgoing* messages. The server could echo them back
> with <archived/>... but then things start to get a bit muddy.
> The alternative is to not solve this, and clients should treat the MAM
> archive as the canonical source of history - (therefore fetching
> messages from the archive that have already been sent/received by it).
> A waste of bandwidth if nothing else.

You will only need to request (assuming you have carbons) on average
less than a single message that's a duplicate, though - as IM is
typically send a message/receive a message [yes, there are exceptions
where this is potentially very untrue], and you will have the id of
the message you received.

> I'll also mention here that in my mind archiving and carbons are very
> related. They are both about replicating history across clients, only
> that Carbons just works while online. Originally MAM was to allow
> 'subscribing' to an archive, as a way to receive messages
> sent/received by other resources while online, and even allow
> following a MUC room in realtime without joining it. This would be a
> separate XEP if I submitted it, but now that we have Carbons there
> would be more than a little overlap there. Thoughts welcomed.

I had thoughts on the overlaps and how to deal with them that I
started writing up at
http://doomsong.co.uk/extensions/render/multiple-clients.html -
although my opinions have likely changed in the last two years on the
best way to do it.

/K



More information about the Standards mailing list