Re: [Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain

[Piotr Nosek]

On Tue, Jan 10, 2017 at 3:43 PM, Dave Cridland  wrote:

> On 10 January 2017 at 14:37, Kevin Smith  wrote:
> >
> >
> > On 10/01/2017 14:27, Dave Cridland wrote:
> >>
> >> On 10 January 2017 at 13:30, Kevin Smith  wrote:
> >>>
> >>> On 10/01/2017 12:05, Steve Kille wrote:
> 
>  I have just issued a PR for MIX version 0.6.4.
> 
>  There is clear desire to have the option for  MUC and MIX to use the
>  same
>  domain.The difficulty in achieving this was incompatible disco
>  results.
>  This version has made a change to
>  add node='mix' to channel disco that will enable the queries to be
>  disambiguated.
> >>>
> >>> I haven't been able to think of a case other than disco#items on the
> room
> >>> JID where MUC and MIX are likely to collide. This change doesn't make
> it
> >>> *easy* to implement both on the same domain, but I think it makes it
> >>> viable
> >>> - please shout if anyone can think of other cases.
> >>>
> >> I agree. Further, I only know of a single client that would ever hit
> >> disco#items on a room, and that's Psi in its generic disco "browser".
> >>
> > Are you suggesting that this approach isn't necessary, and it'd be
> > sufficient to 'break' disco#items handling for MUC-only clients?
> >
>
> I'd not thought of this approach, but I was considering advocating
> "just break". I think this means we don't have to.


What about using Entity Capabilities to establish whether the client should
receive MIX or MUC stanzas and syntax? I know that it's mandatory for every
client to announce its caps but in such case the server could failover to
default mode. I don't know unfortunately if all major clients include their
version in initial presence...
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

[Piotr Nosek]

Hi Dave,

a) It retains some level of compatibility, please see Implementation Notes.
It is possible to use 0045 protocol for most of the functionality in
transition period. "Substantial chunk of work" is not very precise. In our
case the initial implementation that did not support 0045 compatibility
took about 2-3 weeks. Please note it included refining the protocol in the
meantime, so it was not pure implementation of existing, ready standard.

b) It is a compilation of requirements of mobile chat providers. I can't
see why being useful only for mobile clients is a reason to treat is as
useless. It is a common belief amongst many developers that XMPP is not
very attractive for mobile environments, why can't we make several
extensions that are specifically mobile-friendly?
Yes, there is no possibility of sending IQs but the thing is - what
IQ-based functionality we would need in groupchats? File transfer? It's a
common practice nowadays to upload files to external storage like Amazon S3
and then just send a message with a link. (extra benefit: it can get
archived by MAM).

Regards,
Piotr

On Wed, Dec 9, 2015 at 10:48 AM, Dave Cridland  wrote:

> This is quite a substantial protocol, but has, I think, two issues which
> mean it is problematic to accept in my opinion:
>
> a) It is not just presence-less MUC. It's an entirely new protocol which
> is incompatible with existing XEP-0045. Even the room affiliation model is
> different, allowing for example only one owner. This is problematic because
> it's not reusing much (if anything) of the existing infrastructure. As such
> it's going to be a substantial chunk of work for server developers to
> implement, and difficult to offer a transitional approach into XEP-0045
> based services.
>
> b) It is only presence-less MUC. It's not offering anything beyond simple
> fan-out of chat messages, and as a result there is no incentive for
> non-mobile, or non-chat, clients to adopt it. As an example, there's no way
> to send any IQ traffic through the system, due to a combination of no
> visibility of either presence or full jids, meaning there's no possibility
> of, for example, file transfer.
>
> I appreciate there is a degree of not wanting to accept it because we're
> expecting a MUC2 protoXEP to arrive, however I'm trying not to let that
> influence my thinking here, since there's currently no XEP.
>
> On 8 December 2015 at 17:39, XMPP Extensions Editor 
> wrote:
>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Multi-User Chat Light
>>
>> Abstract: This specification provides a presence-less standard for
>> Multi-User Chats. Its feature set is a response to mobile XMPP applications
>> needs and specific environment.
>>
>> URL: http://xmpp.org/extensions/inbox/muc-light.html
>>
>> The XMPP Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
>>
>>
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 adding archive id to live incoming messages

[Piotr Nosek]

On Mon, Jan 26, 2015 at 1:08 PM, Kevin Smith kevin.sm...@isode.com wrote:

 Please bottom-post on this list.

 On 26 Jan 2015, at 11:20, Piotr Nosek piotr.no...@erlang-solutions.com
 wrote:
 
  On Thu, Jan 22, 2015 at 2:47 PM, Kevin Smith kevin.sm...@isode.com
 wrote:
  On 22 Jan 2015, at 13:24, Georg Lukas ge...@op-co.de wrote:
  
   * Kevin Smith kevin.sm...@isode.com [2015-01-22 14:14]:
   How would you deduplicate a mix of messages received normally and
 MAM
   messages? Are you supposed to delete all normal messages when
 syncing up
   with MAM?
   Yep.
  
   Hmm. My gut feeling is that I don't particularly like that approach.
   Maybe we can really deprecate it with the unique-id idea.
 
  As I said earlier - if someone can come up with an alternative that
 works (in the edge cases, not just the obvious single-client case), I think
 speccing it would be great. No-one’s come up with such a proposal yet.
  But what are these edge cases actually?  Can anyone write an example, a
 clear scenario that is problematic when using server-side IDs?

 A few examples (between server and client) of what happens if you try to
 use the local archive on a client to fill in gaps in received server
 archives (i.e. to not fetch server archives for periods the client was
 online). These are addressible, to different degrees, with sufficient
 amounts of client smarts, but not (I believe) all. The list of edge cases
 was longer than this, but these are the ones I can trivially remember:

 1 server sends messageA
 2 client sends messageB
 3 client receives messageA
 4 server receives messageB

 Client has the archive out of order


I believe that the order of messages A  B is not so relevant, since it is
unlikely they are question and answer (we are observing race condition
here). The order will be mixed until next sync, because the only archive ID
the client has, are the ones from the messages received. So if the
communication is interrupted at this point, the client will reconnect,
query MAM for messages after messageA and will learn that from server
perspective messageB should be after messageA, so the client can patch the
local archive. If the conversation continues, the incorrect order will most
likely persist in device memory but then again - how harmful for user
experience it could probably be?


 1 server sends messageA
 2 client sends messageB
 3 client receives messageA
 4 client disconnects

 Client has a message in its archive that was never delivered.


I believe XEP-0198 can deal with it and with SM enabled, the client
shouldn't store the message in archive until the ack is received.


 1) client sends messageA
 2…26) client sends messageB…messageZ
 3) session ends

 The client has to do a full sync anyway, because it doesn’t have IDs for
 any of its sent stanzas.

 /K


I can't think of a way to definitely solve this right now but is it such a
frequent case that you will send tons of messages to someone without a
single answer and then reconnect repeatedly?

Anyway I think it is essential to have some ID assigned by server (at
least) in MAM. Even if clients would add proper IDs to the stanzas, the
server might prefer an optimized ID types to enhance archive lookups, like
a guarantee for them to be non-decreasing.

Re: [Standards] XEP-0313 adding archive id to live incoming messages

[Piotr Nosek]

But what are these edge cases actually?  Can anyone write an example, a
clear scenario that is problematic when using server-side IDs?

On Thu, Jan 22, 2015 at 2:47 PM, Kevin Smith kevin.sm...@isode.com wrote:

 On 22 Jan 2015, at 13:24, Georg Lukas ge...@op-co.de wrote:
 
  * Kevin Smith kevin.sm...@isode.com [2015-01-22 14:14]:
  How would you deduplicate a mix of messages received normally and MAM
  messages? Are you supposed to delete all normal messages when syncing
 up
  with MAM?
  Yep.
 
  Hmm. My gut feeling is that I don't particularly like that approach.
  Maybe we can really deprecate it with the unique-id idea.

 As I said earlier - if someone can come up with an alternative that works
 (in the edge cases, not just the obvious single-client case), I think
 speccing it would be great. No-one’s come up with such a proposal yet.

 /K

Re: [Standards] XMPP summit / FOSDEM

[Piotr Nosek]

Hi everyone, 

I would like to attend too! I will arrive to Brussels on Wednesday in the 
evening and leave on Saturday early morning (can't stay for dinner :(). Can 
someone please add me to the wiki page? I don't have an account. :) 
I don't have any hotel booked yet so I can wait for some info on the discount. 

Regards, 
Piotr 


Od: Steffen Larsen zoo...@gmail.com 
Do: XMPP Standards standards@xmpp.org 
DW: XMPP Summit sum...@xmpp.org 
Wysłane: poniedziałek, 5 styczeń 2015 14:56:55 
Temat: [Standards] XMPP summit / FOSDEM 

Hi Guys, 

I haven’t heard anything about this subject since Joachim wrote a while ago. 
I am definitely coming and the summit is not many days from now. 

Have anyone looked at hotels and discounts etc? 
When is the summit? The two days before FOSDEM like it normally is? 

I think we should start organising it. The page is there: 
http://wiki.xmpp.org/web/Summit_17 , but we need some organisers. 

PS: I would gladly help I just need to be told what needs to be done. :-) 

-Cheers and hope you all had a nice x-mas and new year! 

/Steffen 

[Standards] Final XEP-0004 references to deprecated XEP-0086

[Piotr Nosek]

Hi everyone,

I have noticed that 0004 Data Forms references 0086 (Error Condition Mappings) 
here: http://xmpp.org/extensions/xep-0004.html#validation but 0086 has status 
Deprecated. Maybe 0004 should be modified to make reference to XMPP Core 
(despite being Final)?

Regards,
Piotr

[Standards] New feature proposal for XEP-0313: result limiting per JID

[Piotr Nosek]

Hi everyone,

I have encountered a requirement quite frequently, that client should be able 
not only to fetch all messages from MAM or messages for specific conversation, 
but also get a list of conversations (both 1-1 and MUC) that have any messages 
after certain timestamp + last message for each conversation to display in UI.

Me and colleagues had a discussion on this issue and we think XEP-0313 could 
use a new parameter for queries, that will tell the server to return only N 
last messages for every conversation (i.e. remote JID). Example:

iq type='set' id='juliet1'
  query xmlns='urn:xmpp:mam:0' queryid='1'
x xmlns='jabber:x:data'
  field var='FORM_TYPE'
valueurn:xmpp:mam:0/value
  /field
  field var='start'
value2010-08-07T00:00:00Z/value
  /field
  field var='last-per-jid'
value1/value
  /field
/x
  /query
/iq

This would allow to easily and quickly update client-side archive and UI. More 
messages can be fetched from conversation on-demand, e.g. when user opens the 
conversation in the app.

What do you think?

Regards,
Piotr