On Thu, Apr 19, 2012 at 6:01 PM, Matthew Wild <[email protected]> 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
