<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 8:44 PM, Florian Schmaus <span dir="ltr"><<a href="mailto:flo@geekplace.eu" target="_blank">flo@geekplace.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 06.07.2016 20:42, Ivan Vučica wrote:<br>> If I am interpreting XEP-0313 correctly, for person-to-person use case,<br>> archive is obtained by inquiring the 'current server'. This is usually fine.<br>><br>> However, in case of an external transport component communicating with<br>> an IM network that can provide its own history, there does not seem to<br>> be a viable standardized way to inquire the external component about the<br>> additional history.<br><br></span>Does that component need to act as MAM archive? I would expect messages<br>exchanged between a user and a transport component to be stored in the<br>users MAM archive. Just like messages between the user and a remote<br>server are stored in the MAM archive.<br></blockquote><div><br></div><div>The IM service for which the component is acting as a transport may provide additional history.</div><div><br></div><div>User may exchange additional messages natively via the service, without use of the XMPP service or the component. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>> [^1]: Most of this mail makes the assumption that component's timestamp<br>> is the same as server's component, and that the sort order is based<br>> solely on the timestamp.<br><br></span>BTW: If I where to implement MAM service I think I would ignore any<br>timestamps and just store the message stanzas in the order they are put<br>in the archive. Because that order is important. Relying on timestamp<br>causes all sort of trouble that you likely can't solve in a federated<br>system like XMPP (without a central authority).<br></blockquote><div><br></div><div>Sure. But if you ignored timestamps, how would you go about merging histories while chatting via multiple services? (Point becomes moot if we go with 'component is authoritative'. No merging necessary.)</div><div><br></div></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Jul 6, 2016 at 8:45 PM, Kim Alvefur <span dir="ltr"><<a href="mailto:zash@zash.se" target="_blank">zash@zash.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br></span>Treating JIDs from components, especially transports, similar to MUC<br>makes some sense here I think.  Both MUC services and transports to<br>legacy services are in a better position for having a consistent view of<br>the message history, so it makes sense for them to be the authoritative<br>source.<br></blockquote><div><br></div><div>That's definitely less complex, although it does seem less useful than merging histories.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>This does produce more work for clients tho, who will have to somehow<br>know which JIDs need to be treated differently, apart from MUCs.<br></blockquote><div><br></div><div>I had service discovery on the component (opt 3) or fulljid (opt 4) in mind.</div><div><br></div></div><div class="gmail_quote">On Wed, Jul 6, 2016 at 8:54 PM, Dave Cridland <span dir="ltr"><<a href="mailto:dave@cridland.net" target="_blank">dave@cridland.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Rapid knee-jerk response:<div><br></div><div>* 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.</div></div></blockquote><div><br></div><div>It feels like marginally less work for client devs while offering ability to fetch history from other clients, not just components.</div><div><br></div><div>However, I agree there feels to be a greater potential for misuse.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">* 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.<br></div></blockquote><div><br></div><div>Thus the mention of deduplication. :-)</div><div><br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Jul 6, 2016 at 8:58 PM, Florian Schmaus <span dir="ltr"><<a href="mailto:flo@geekplace.eu" target="_blank">flo@geekplace.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
</span>Sorry, missed that you where talking about something like IRC<br>
transports, i.e. transports which (could) provide their own history. Was<br>
thinking you where talking about ICQ/MSN and the like.<br></blockquote><div><br></div><div>Because MUC use case is solved, I actually had in mind "ICQ/MSN and the like" -- the person-to-person use case.</div><div><br></div><div>Either way, I do not see the difference between IRC, ICQ and MSN; IRC does not provide history natively either. If anything, if I remember correctly, MSN had history sync while it existed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yep, that's an unresolved issue. My first reflex would also be option 4.<br>
But let's see if someone comes up with a more elegant solution.<br></blockquote><div><br></div><div>*nod* </div></div></div></div>