On Wed, Jul 6, 2016 at 8:44 PM, Florian Schmaus wrote:
> On 06.07.2016 20:42, Ivan Vučica wrote:
> > If I am interpreting XEP-0313 correctly, for person-to-person use case,
> > archive is obtained by inquiring the 'current server'. This is usually
> fine.
> >
> > However, in case of an external t
On 06.07.2016 21:44, Florian Schmaus wrote:
> On 06.07.2016 20:42, Ivan Vučica wrote:
>> If I am interpreting XEP-0313 correctly, for person-to-person use case,
>> archive is obtained by inquiring the 'current server'. This is usually fine.
>>
>> However, in case of an external transport component
Rapid knee-jerk response:
* 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.
* 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 serve
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 addi
On 06.07.2016 20:42, Ivan Vučica wrote:
> If I am interpreting XEP-0313 correctly, for person-to-person use case,
> archive is obtained by inquiring the 'current server'. This is usually fine.
>
> However, in case of an external transport component communicating with
> an IM network that can provi
Cheers,
If I am interpreting XEP-0313 correctly, for person-to-person use case,
archive is obtained by inquiring the 'current server'. This is usually fine.
However, in case of an external transport component communicating with an
IM network that can provide its own history, there does not seem t
