from:"JC Brand"

On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote:
> On 2019/09/23, JC Brand wrote:
> > Based on our off-list discussion, I'm going to go with sending an IQ to the 
> > MUC
> > JID in order to ask for a message to be retracted.
> > 
> > The MUC then sends out the retraction message to all participants. This 
> > solves
> > the problem of temporary moderators retracting messages and clients then 
> > later
> > being unable to verify that the operation was done by someone with the
> > necessary permissions.
> > 
> > The MUC can then decide to replace the message with a tombstone in its 
> > XEP-0045
> > message history or in the MAM store.
> > 
> > I guess for MAM tombstoning the MAM service needs to advertise it via disco 
> > and
> > the client needs to specifically ask for it in the IQ?
> > 
> > When it comes to one-on-one conversations, I'm not sure what the equivalent
> > interaction would be given that there isn't a dedicated service as in the 
> > case
> > of MUC and because two MAM archives are involved. Perhaps sending the
> > retraction message yourself (instead of asking for it to be sent via an IQ) 
> > is
> > the preferred way there.
> > 
> > I'd be happy to hear some suggestions. I'm leaning towards restricting
> > the scope of this XEP to only MUCs (and MIX?) and ignoring the one-on-one
> > usecase entirely.
> 
> What about looking at it the other way around? 1:1 being the general
> case and MUC something that modifies/enhances it.
> 
> In 1:1, one would be able to send a retraction, referring to a previous
> message that has been sent with the same barejid. I think this should
> also be possible in MUCs.
> 
> Additionally in MUCs, one could send an IQ to the room so that the MUC
> itself broadcasts it to all participants of that room.

I don't like the idea of there being two ways of doing the same thing in a MUC.
IMO there should be only one way of doing this, and given that sending the
retraction message yourself can cause problems with verifying validity, I think
it should only be via an IQ.

For 1:1, sending a message yourself appears to be fine.

It's a bit unfortunate that we then don't use the same semantics (i.e. stanzas)
for both use-cases, but I don't see currently how we can reconcile them.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Retractions

On Tue, Sep 24, 2019 at 03:40:22PM +0200, Georg Lukas wrote:
> * JC Brand  [2019-09-24 15:10]:
> > > Additionally in MUCs, one could send an IQ to the room so that the MUC
> > > itself broadcasts it to all participants of that room.
> > I don't like the idea of there being two ways of doing the same thing in a 
> > MUC.
> 
> Those are not actually the same thing. One is you retracting your own
> message, the other one is a MUC moderator removing your message from the
> MUC history.

Are you implying that a message retracted by the author should not
be removed from MUC history?

I think in both cases it should be removed. If your own retracted message
doesn't get tombstoned, then there's fundamentally no difference to message
corrections and we don't need to cover the 1:1 case at all.

You could just consider an empty message correction as a retraction and update
the client UI accordingly.

> Having two separate mechanisms for that, with both ending up in a
> retraction message sent by an "authorized" JID (bare JID in 1:1, maybe
> MUC-JID or original-occupant-full-JID in MUC?) seems sane to me.

I was thinking that groupchat message authors would also send an IQ to retract
their messages, given that the room could be semi-anonymous and clients could
therefore not be able to figure out whether the person retracting the message
is actually the author.

We have XEP-0421 to deal with that though, so I guess it's fine to send a
message if you're the author and an IQ if you're a moderator.

signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Retractions

On Wed, Sep 04, 2019 at 02:44:27PM +0500, Andrew Nenakhov wrote:
> We have a fairly big protoXEP for message retraction and deletion,
> it's implemented on our upcoming server, and in Xabber for Web. It's
> working admirably well under most conditions: if the client is online
> or offline, and if the entity uses own or remote message archive. The
> only downside is that it offers no legacy fallback at all, but it can
> be added rather easily once we decide on the fallback method.
> 
> However, this method is 'server-centric', cause it requires a server
> to calculate edit versions so that offline clients can check it there
> were edits while they were away.

Can this not just be handled with a MAM catchup when the client comes online?
(if the MAM archive stores the retraction)

> It also introduces upgrade over MAM
> so we finally CAN delete messages from it.
> 
> Sadly, documents for the moment are available only in Russian, here:
> https://docs.google.com/document/d/17oLud7l9DYZb2fUvSDdcJugs_5es0jw-9KBPZVptUHA/edit
> I guess google translate would translate most of it rather well, and
> If anyone's really interested I can muster myself up and speed up
> translation to English.

I asked Google to translate it, but only half of the document got translated.


> ср, 4 сент. 2019 г. в 14:22, JC Brand :
> >
> > Hi folks
> >
> > I'm going to implement message retractions for Converse.js and while
> > researching what's available XEP-wise I came across this proposed
> > XEP from Lance Stout:
> >
> > https://xmpp.org/extensions/inbox/message-retraction.html
> >
> > It's from 2016 and was never accepted (i.e. assigned a XEP number).
> >
> > I searched the standards list archives and found a thread where it was
> > discussed: 
> > https://mail.jabber.org/pipermail/standards/2016-October/031506.html
> >
> > I also found a later thread (2018) about message corrections where people 
> > were
> > discussing putting message retractions in XEP-308 (Last message correction).
> > https://mail.jabber.org/pipermail/standards/2018-June/035154.html
> >
> > I don't see any specific reason in the archives why the XEP wasn't advanced,
> > except that apparently enthusiasm for it fizzled out.
> >
> > I'm not the author of the proposed XEP, but I'd like to see whether this 
> > can be
> > moved forward and I hereby offer to make any changes necessary to get it
> > accepted (unless Lance would like to do so himself).
> >
> > Given that the proposed XEP is fairly old, there are a few things I'd like 
> > to
> > add to it to bring it up to date with latest practices.
> >
> > These are:
> >
> > * Mandate support for XEP-0359  Unique and stable stanza ids)
> > * Mention XEP-0421 (Anonymous unique occupant IDs) as an alternative to
> >   including the user's JID in the tombstone (section 4 example 5).
> > * Allow admins to see the original (now retracted) message when they receive
> >   the tombstone from MAM.
> > * Allow for supplying a reason why the message was deleted.
> >
> > Concerning the question of putting this XEP inside an updated XEP-0308, I
> > propose keeping message retractions in a separate XEP, for these reasons:
> >
> > * We want MUC/MIX admins to be able to retract other occupants' messages
> >   (but not "correct" them).
> > * A message can be corrected multiple times, but retracted only once.
> > * Message retraction has different implications for MAM than corrections.
> >
> > I look forward to hearing your thoughts on this.
> >
> > Regards
> > JC
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> 
> 
> 
> -- 
> Andrew Nenakhov
> CEO, redsolution, OÜ
> https://redsolution.com
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Retractions

On Tue, Sep 24, 2019 at 04:29:47PM +0200, Maxime Buquet wrote:
> On 2019/09/24, JC Brand wrote:
> > On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote:
> > > What about looking at it the other way around? 1:1 being the general
> > > case and MUC something that modifies/enhances it.
> > > 
> > > In 1:1, one would be able to send a retraction, referring to a previous
> > > message that has been sent with the same barejid. I think this should
> > > also be possible in MUCs.
> > > 
> > > Additionally in MUCs, one could send an IQ to the room so that the MUC
> > > itself broadcasts it to all participants of that room.
> > 
> > I don't like the idea of there being two ways of doing the same thing in a 
> > MUC.
> > IMO there should be only one way of doing this,
> 
> I think these can/should be taken as semantically different.
> 
> One being retracting your own messages. The other being retracting other
> people's messages ("moderating a room"). They're essentially not the
> same thing to me.

Ok, Ge0rg made the same point.

> It might have been mentioned before, but it would make sense to split
> them. Rename this XEP "moderation" and keep the "retraction" case for
> own messages.

Ted Sterr suggested this as well.

I'm ok with that, this lets me focus on the moderation case for now, which is
what I need to implement.

> A client implementing both will have to use a similar logic as described
> below anyway though.
> 
> > and given that sending the
> > retraction message yourself can cause problems with verifying validity
> 
> A client would have to verify the validity of any incoming retraction
> message anyway. Having the MUC broadcasting this for you doesn't mean
> you're exempt of spoofing attacks.
 
> 
> Here is an exemple of validation logic:
> 
> If retraction message (RM) @type is 'groupchat':
> - (Moderation) Check if @from is a barejid and equals room barejid, if not
> - (Participant retraction) @from is a fulljid.
> - Ensure the fastened message (FM) is of the same type.
> - If RM @from is a valid room barejid as defined above, stop here.
> - RM is a fulljid, ensure RM's fulljid equals FM's fulljid.

This covers the non-anonymous MUC usecase. For semi-anonymous we'll need to
check the XEP-0421 occupant id as well.

> If retraction message (RM) @type is 'chat' or 'normal':
> - This is not moderation.
> - Ensure the fastened message (FM) is of the same type.
> - If message is MUC-PM[0], (and client is joined to this MUC?), ensure @from 
> is a fulljid,
>   * Ensure that RM @from equals FM @from fulljid
> - If not MUC-PM, ensure RM @from equals FM @from barejid.
> 
> 
> This is probably not perfect but I think that's a good start(?)
> 
> 
> [0]: Indicated by the presence of  xmlns='http://jabber.org/protocol/muc#user'/>
>   or previous knowledge that the barejid is a MUC (a general problem of
>   MUC-PMs anyway).
> 
> 
> -- 
> Maxime “pep” Buquet



> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Retractions

2019-09-25 Thread JC Brand

Based on the feedback from this list, I've split the message retractions
protoXEP into two, one for retractions and one for (groupchat) moderation.

The message moderation protoXEP makes use of the retraction protoXEP and I
consider retraction one particular use-case of moderation. Another might be
correcting a message (on another user's behalf) or flagging a message.

Here are the relevant Github PRs:

* Message retractions: https://github.com/xsf/xeps/pull/832
* Message moderation: https://github.com/xsf/xeps/pull/833



On Tue, Sep 24, 2019 at 06:35:35PM +0200, JC Brand wrote:
> On Tue, Sep 24, 2019 at 04:29:47PM +0200, Maxime Buquet wrote:
> > On 2019/09/24, JC Brand wrote:
> > > On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote:
> > > > What about looking at it the other way around? 1:1 being the general
> > > > case and MUC something that modifies/enhances it.
> > > > 
> > > > In 1:1, one would be able to send a retraction, referring to a previous
> > > > message that has been sent with the same barejid. I think this should
> > > > also be possible in MUCs.
> > > > 
> > > > Additionally in MUCs, one could send an IQ to the room so that the MUC
> > > > itself broadcasts it to all participants of that room.
> > > 
> > > I don't like the idea of there being two ways of doing the same thing in 
> > > a MUC.
> > > IMO there should be only one way of doing this,
> > 
> > I think these can/should be taken as semantically different.
> > 
> > One being retracting your own messages. The other being retracting other
> > people's messages ("moderating a room"). They're essentially not the
> > same thing to me.
> 
> Ok, Ge0rg made the same point.
> 
> > It might have been mentioned before, but it would make sense to split
> > them. Rename this XEP "moderation" and keep the "retraction" case for
> > own messages.
> 
> Ted Sterr suggested this as well.
> 
> I'm ok with that, this lets me focus on the moderation case for now, which is
> what I need to implement.
> 
> > A client implementing both will have to use a similar logic as described
> > below anyway though.
> > 
> > > and given that sending the
> > > retraction message yourself can cause problems with verifying validity
> > 
> > A client would have to verify the validity of any incoming retraction
> > message anyway. Having the MUC broadcasting this for you doesn't mean
> > you're exempt of spoofing attacks.
>  
> > 
> > Here is an exemple of validation logic:
> > 
> > If retraction message (RM) @type is 'groupchat':
> > - (Moderation) Check if @from is a barejid and equals room barejid, if not
> > - (Participant retraction) @from is a fulljid.
> > - Ensure the fastened message (FM) is of the same type.
> > - If RM @from is a valid room barejid as defined above, stop here.
> > - RM is a fulljid, ensure RM's fulljid equals FM's fulljid.
> 
> This covers the non-anonymous MUC usecase. For semi-anonymous we'll need to
> check the XEP-0421 occupant id as well.
> 
> > If retraction message (RM) @type is 'chat' or 'normal':
> > - This is not moderation.
> > - Ensure the fastened message (FM) is of the same type.
> > - If message is MUC-PM[0], (and client is joined to this MUC?), ensure 
> > @from is a fulljid,
> >   * Ensure that RM @from equals FM @from fulljid
> > - If not MUC-PM, ensure RM @from equals FM @from barejid.
> > 
> > 
> > This is probably not perfect but I think that's a good start(?)
> > 
> > 
> > [0]: Indicated by the presence of  > xmlns='http://jabber.org/protocol/muc#user'/>
> >   or previous knowledge that the barejid is a MUC (a general problem of
> >   MUC-PMs anyway).
> > 
> > 
> > -- 
> > Maxime “pep” Buquet
> 
> 
> 
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> 



> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Retractions

2019-09-25 Thread JC Brand

On Wed, Sep 25, 2019 at 06:11:25PM +0500, Andrew Nenakhov wrote:
> вт, 24 сент. 2019 г. в 21:30, JC Brand :
> > > However, this method is 'server-centric', cause it requires a server
> > > to calculate edit versions so that offline clients can check it there
> > > were edits while they were away.
> >
> > Can this not just be handled with a MAM catchup when the client comes 
> > online?
> > (if the MAM archive stores the retraction)
> 
> If by "MAM catchup" you mean fetching all messages in a conversation,
> well, this CAN be handled this way, but it was exactly what we were
> trying to avoid, because it is the worst possible method, which also
> can't be used on iOS.

MAM catchup means fetching the messages you missed while you were offline.


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Message Retractions

2019-09-25 Thread JC Brand



Am 25. September 2019 15:59:46 MESZ schrieb Andrew Nenakhov 
:
>ср, 25 сент. 2019 г. в 18:57, JC Brand :
>> > If by "MAM catchup" you mean fetching all messages in a
>conversation,
>> > well, this CAN be handled this way, but it was exactly what we were
>> > trying to avoid, because it is the worst possible method, which
>also
>> > can't be used on iOS.
>>
>> MAM catchup means fetching the messages you missed while you were
>offline.
>
>And if there were 1 messages? Quite plausible for a busy group
>chat.

Yes, then being able to query for edits makes sense. This is not a problem 
limited to retractions, so it's perhaps something for a different separate XEP?


>-- 
>Andrew Nenakhov
>CEO, redsolution, OÜ
>https://redsolution.com
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

2019-10-09 Thread JC Brand

On Wed, Oct 09, 2019 at 04:56:54PM +0200, Jonas Schäfer wrote:
> - Should we really require both BOSH and WebSockets for the Web Suite for 
> clients? Maybe it makes more sense to require it both for Servers, but only 
> one of them for clients, possibly even phasing out BOSH. (Disclaimer: I’m not 
> a Web person).

Looking at footnote 14, it appears as if only one of the two is required for
compatibility, not both.

That said, I agree that supporting only one web connection mechanism is enough.

If only BOSH is supported, then XEP-0198 isn't needed since it's not compatible
with BOSH which in any case has its own session management protocol. This needs
to be made explicit.

Regards
JC
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

2019-10-09 Thread JC Brand

On Wed, Oct 09, 2019 at 05:24:49PM +0200, Georg Lukas wrote:
> * Evgeny  [2019-10-09 17:08]:
> > I would like to see BOSH dropped and moving the XEP to historical or
> > deprecated state, because I see zero advantages over Websockets now
> > (supporting both XEP-0198 and BOSH makes no sense at all).
> 
> there is still an open issue with WebSockets for anonymous sessions: you
> can't 0198 resume anon sessions because you can't re-login with the same
> credentials, and thus BOSH will survive a page reload, whereas WS won't.
> Until this problem is solved, I'd rather not kill BOSH.

Yes, I was affected by this issue recently.

I don't see how this will get resolved without allowing the client to specify
the full JID it wants to re-use so that it can then use XEP-0198 to resume
its previous session.

At least one server developer was against the idea, IIRC saying that it goes
breaks the semantics of anonymous connections.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

2019-10-09 Thread JC Brand

On Wed, Oct 09, 2019 at 06:32:12PM +0300, Evgeny wrote:
> On Wed, Oct 9, 2019 at 6:27 PM, Evgeny  wrote:
> > According to such logic this "problem" should be resolved for plain TCP
> > c2s as well. Unless it's not solved we should not kill BOSH.
> 
> Ah, and another question is raising: why actually BOSH allows you to restore
> the session without re-authentication, when XEP-0198 doesn't? Is BOSH a more
> secure transport?

HTTP is short-lived and stateless, so the XMPP server needs to keep the session
alive between requests and also for a certain period of time (usually ~60s)
after it has received the last request.

Because HTTP is stateless, individual requests need to be "authenticated" as
well. This is done with a session token and a continuously incrementing request
token, both of which need to be included per request.

"Restoring" a session means simply making a new request within the timeout
period. Whether the browser tab has been reloaded in the meantime is
irrelevant.

signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

On Wed, Oct 09, 2019 at 10:24:54PM +0300, Evgeny wrote:
> On Wed, Oct 9, 2019 at 10:20 PM, Evgeny  wrote:
> > I still doubt this is anyhow more secure than session resumption in
> > XEP-0198 (which btw requires real re-authentication).
> 
> Let me explain: using BOSH to bypass restriction of XEP-0198 (namely, SASL
> re-authentication) doesn't justify usage of BOSH, in my opinion. Such
> explanation looks really weird, to say the least.

You're arguing against a point nobody made.

Nobody advocated using BOSH to bypass restrictions in XEP-0198.
The issue Georg mentioned isn't due to anything in XEP-0198.

The issue is with the SASL anonymous login mechanism not allowing you to
reconnect with the same JID, which happens **before** trying to resume a
XEP-0198 session.

At least this is the case with Prosody, I haven't tested on other servers.

With websocket the connection and session immediately drop when you reload
the page and if you used anonymous login, you will then need a way to
reconnect and then re-establish your previous session. You can't however
because SASL anon doesn't allow you to reuse your same JID.

With BOSH you don't have this problem because the XMPP server keeps the session
alive between requests, so you're not re-establishing an old session, you're
just sending a new request to the original session.

Therefore with BOSH you can reload the page and still maintain your anonymous
session while with websocket you can't.

Non-web clients don't have this problem because their connections are
long-lived. With websocket-using web-clients your connection can be terminated
at any time when the user reloads the tab.

signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

On Wed, Oct 09, 2019 at 09:13:59PM +0200, Jonas Schäfer wrote:
> On Mittwoch, 9. Oktober 2019 21:01:18 CEST JC Brand wrote:
> > On Wed, Oct 09, 2019 at 05:24:49PM +0200, Georg Lukas wrote:
> > > * Evgeny  [2019-10-09 17:08]:
> > > > I would like to see BOSH dropped and moving the XEP to historical or
> > > > deprecated state, because I see zero advantages over Websockets now
> > > > (supporting both XEP-0198 and BOSH makes no sense at all).
> > > 
> > > there is still an open issue with WebSockets for anonymous sessions: you
> > > can't 0198 resume anon sessions because you can't re-login with the same
> > > credentials, and thus BOSH will survive a page reload, whereas WS won't.
> > > Until this problem is solved, I'd rather not kill BOSH.
> > 
> > Yes, I was affected by this issue recently.
> > 
> > I don't see how this will get resolved without allowing the client to
> > specify the full JID it wants to re-use so that it can then use XEP-0198 to
> > resume its previous session.
> > 
> > At least one server developer was against the idea, IIRC saying that it goes
> > breaks the semantics of anonymous connections.
> 
> Which is true.
> 
> I think that for those cases, [XEP-0397] would come in handy. It can serve 
> here not only as a speedup of resumption, but also as a way to make 
> resumption 
> possible.

Ok, so it seems the reasoning here is that XEP-0397 is the solution because
when you're using it you're not trying to log in anonymously with a 
pre-specified
JID (which is not allowed) in order to resume a XEP-0198 session, instead you
resume the session by means of a token (which implies a particular JID).

The difference is very subtle, but makes sense to me.

Well, to come back to Georg's point of not deprecating BOSH until we have a
solution, it seems that XEP-0397 would need to be included in the compliance
suite, at least for this particular use-case (maintaining anonymous logins
over websocket).


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Feedback to Compliance Suites 2020

On Thu, Oct 10, 2019 at 11:01:56AM +0300, Evgeny wrote:
> On Thu, Oct 10, 2019 at 10:52 AM, JC Brand  wrote:
> > You're arguing against a point nobody made.
> > 
> > Nobody advocated using BOSH to bypass restrictions in XEP-0198.
> > The issue Georg mentioned isn't due to anything in XEP-0198.
> > 
> > The issue is with the SASL anonymous login mechanism not allowing you to
> > reconnect with the same JID, which happens **before** trying to resume a
> > XEP-0198 session.
> 
> The issue is *exactly* due to limitation in XEP-0198 that you're trying to
> bypass with BOSH: since XEP-0198 doesn't allow you to resume a session
> without re-authentication (and with SASL ANONYMOUS you cannot
> re-authenticate with the same JID), you resort to use BOSH to bypass this
> restriction, since it's *implicitly* using session identifiers as
> authentication tokens.

Now you're saying "limitation", previously you said "restriction".

I agree that XEP-0198 is limited in the sense that it doesn't concern itself
with authentication and that this problem occurs at the authentication level.

Seems like XEP-0397 solves it though.


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-10-08



Am 10. Oktober 2019 12:38:53 MESZ schrieb Kevin Smith

>> Proposed XMPP Extension: Message Moderation -
>https://xmpp.org/extensions/inbox/message-moderation.html
>
>> Dave: [pending]
>> Georg: [on-list]
>> Jonas: [on-list]
>> Kev: [on-list]
>> Link: [on-list]
>
>+1
>(Although I note that the bit about iq ordering is often a bit of a
>nuisance server-side when there are unnecessary constraints on
>ordering, and this one deosn’t seem to be needed).

In thought it would make it easier for clients, but 
I'm happy to remove the constraint.

JC

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Support for stickers (custom emojis)

2019-10-17 Thread JC Brand

Hello

I'm currently working on adding support for non-unicode emojis to Converse.js.

Currently, users can't upload their own images to be used for custom emojis,
mostly because Converse is a thin client with no backend support for it.

So to add custom emojis, the web host needs to edit a emojis.json file
to add new entries with URLs pointing to the actual images.

Concerning compatibility with other clients, I've discussed it with edhelas
and he told me he uses XEP-0231 BOB for sending stickers.

There are a few reasons why I'm not keen on using BOB:

- BOB depends on XHTML-IM which is deprecated. Converse.js doesn't support it
  and I'm reluctant to add support just for this.
- BOB mentions that binary data should be smaller than 1KB. Not sure how
  relevant that still is, but it discourages me from sending larger amounts.
- The sending client needs to maintain a cache of all sent stickers.
- AFAICT, when receiving an uncached BOB message via MAM and the sending client
  is offline, then you can't get the image data.

Instead, I propose that we use XEP-0372 references to indicate that a
particular shortname (e.g. :dancingpanda:) should be replaced with an image.

For example:

I feel like dancing! :dancingpanda:
https://images.com/dancingpanda"/>


I'm not sure whether "type" should be "data", seems a bit too generic for me,
perhaps it could be something else?

Some criticisms of this approach from edhelas:

- HTTP images can be sent to a webchat client served over HTTPS
- There's no size limit, so users can send links to very large stickers

Concerning the first criticism, a client can choose to not render HTTP
images inline and instead make the shortname a link which opens the image in a
new tab. Not ideal, but a compromise for the privacy and security conscious.

For the second I don't have a good answer.

That said, I currently still prefer my suggestion to using BOB. I'd be
interested to hear your feedback and suggestions.

Regards
JC


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Support for stickers (custom emojis)

2019-10-17 Thread JC Brand

On Thu, Oct 17, 2019 at 01:23:18PM +0200, Marvin W wrote:
> Hi,

> Regarding your proposal:
> - You should still add a hash in the reference somehow so that clients *can*
> cache entries (even if you won't do it in Converse)

Sure.

> - I already dislike the fact that we do HTTP requests to arbitrary servers
> for file transfers, as we might be leaking IP addresses in such cases.

The file servers are usually not arbitrary but are hosted by your XMPP host.

> In the case of Converse, you are likely to get into GDPR issues when doing so
> without explicit user consent (and you don't want explicit user consent for
> every emoji).

Why would you need user consent to show remote images?

The GDPR makes provision for data capturing that's needed to provide the
actual service. I think that applies in this case.

Otherwise any website that has user accounts and which links to 3rd party
images would need user consent for each particular image.

> There is a reason why many e-Mail-Clients don't render remote
> content in e-Mails...

And that's not GDPR, right?

AFAIK it's to avoid pixel tracking and IP address leakage.

> - When this is combined with body-only e2e-encryption, you are leaking
> information as I guess you don't envision the emoji to be encrypted for each
> e2e session individually.

This is a general problem with body-only E2EE and a good example of
why we need full-stanza encryption.

> You can probably solve the second issue mentioned above and the issue with
> http files by proxying the image request through the server hosting Converse
> (which is what other popular sites that allow arbitrary http links like
> GitHub do). But I guess you don't want to do that.

Depends on the deployment, but no, not really.

> Regarding your issues with using BOB:
> - BOB does not depend on XHTML-IM. 0231 §2.2 specifically says that "any
> appropriate format can be used" to share the CID. This means it is also
> possible to use it in 0372 references (as you suggest to do just without
> http).

Yeah, the thought of doing that did cross my mind, I forgot to mention it in my
post though.

Then there are still the caching issues.

> - BOB does not require the sender to provide the file referenced by the CID
> 0231 §2.1 says that you can send the IQ to request the bytes to "potentially
> some other entity". If you don't expect the sending client to provide the
> file, it doesn't need to cache all stickers and it doesn't need to be
> online.

"some other entity" isn't terribly well defined. How do I (or the
recipient of my stickers) know what other entity to ask?

How are stickers added to the entity's cache? How does the client know which
stickers it can send, i.e. which stickers are contained in the cache?

These are all things not spec'd in BOB.

Ideally I'd like to implement something that works in 2019/2020.


> Marvin
> 
> On 10/17/19 12:07 PM, JC Brand wrote:
> > Hello
> > 
> > I'm currently working on adding support for non-unicode emojis to 
> > Converse.js.
> > 
> > Currently, users can't upload their own images to be used for custom emojis,
> > mostly because Converse is a thin client with no backend support for it.
> > 
> > So to add custom emojis, the web host needs to edit a emojis.json file
> > to add new entries with URLs pointing to the actual images.
> > 
> > Concerning compatibility with other clients, I've discussed it with edhelas
> > and he told me he uses XEP-0231 BOB for sending stickers.
> > 
> > There are a few reasons why I'm not keen on using BOB:
> > 
> > - BOB depends on XHTML-IM which is deprecated. Converse.js doesn't support 
> > it
> >and I'm reluctant to add support just for this.
> > - BOB mentions that binary data should be smaller than 1KB. Not sure how
> >relevant that still is, but it discourages me from sending larger 
> > amounts.
> > - The sending client needs to maintain a cache of all sent stickers.
> > - AFAICT, when receiving an uncached BOB message via MAM and the sending 
> > client
> >is offline, then you can't get the image data.
> > 
> > Instead, I propose that we use XEP-0372 references to indicate that a
> > particular shortname (e.g. :dancingpanda:) should be replaced with an image.
> > 
> > For example:
> > 
> >   >  I feel like dancing! :dancingpanda:
> >   >  begin="21"
> >  end="35"
> >  type="data"
> >  uri="https://images.com/dancingpanda"/>
> >  
> >

Re: [Standards] Support for stickers (custom emojis)

2019-10-17 Thread JC Brand

On Thu, Oct 17, 2019 at 03:05:32PM +0300, Sergey Ilinykh wrote:
>Doesn't SIMS ([1]https://xmpp.org/extensions/xep-0385.html) resolve all
>the concerns yet?

Yes, SIMS is more comprehensive than my example. It's still uses a XEP-0372
reference, so it's conceptually similar.

>We can have a  with cid: uri too.

yep.

We could probably also specify under  some JID which can return the BOB
data as Marvin suggested.

>The only thing is missed as for me is an attribute where the referenced
>text has to be removed or not.
>Best Regards,

I'm not sure what you mean. The "begin" and "end" attributes on the
 element can encapsulate the shortname of the sticker.

JC

>Sergey
>чт, 17 окт. 2019 г. в 14:24, Marvin W <[2]x...@larma.de>:
> 
>  Hi,
> 
>  Regarding your proposal:
>  - You should still add a hash in the reference somehow so that clients
>  *can* cache entries (even if you won't do it in Converse)
>  - I already dislike the fact that we do HTTP requests to arbitrary
>  servers for file transfers, as we might be leaking IP addresses in such
>  cases. In the case of Converse, you are likely to get into GDPR issues
>  when doing so without explicit user consent (and you don't want explicit
>  user consent for every emoji). There is a reason why many e-Mail-Clients
>  don't render remote content in e-Mails...
>  - When this is combined with body-only e2e-encryption, you are leaking
>  information as I guess you don't envision the emoji to be encrypted for
>  each e2e session individually.
> 
>  You can probably solve the second issue mentioned above and the issue
>  with http files by proxying the image request through the server hosting
>  Converse (which is what other popular sites that allow arbitrary http
>  links like GitHub do). But I guess you don't want to do that.
> 
>  Regarding your issues with using BOB:
>  - BOB does not depend on XHTML-IM. 0231 §2.2 specifically says that "any
>  appropriate format can be used" to share the CID. This means it is also
>  possible to use it in 0372 references (as you suggest to do just without
>  http).
>  - BOB does not require the sender to provide the file referenced by the
>  CID 0231 §2.1 says that you can send the IQ to request the bytes to
>  "potentially some other entity". If you don't expect the sending client
>  to provide the file, it doesn't need to cache all stickers and it
>  doesn't need to be online.
> 
>  Marvin
> 
>  On 10/17/19 12:07 PM, JC Brand wrote:
>  > Hello
>  >
>  > I'm currently working on adding support for non-unicode emojis to
>  Converse.js.
>  >
>  > Currently, users can't upload their own images to be used for custom
>  emojis,
>  > mostly because Converse is a thin client with no backend support for
>  it.
>  >
>  > So to add custom emojis, the web host needs to edit a emojis.json file
>  > to add new entries with URLs pointing to the actual images.
>  >
>  > Concerning compatibility with other clients, I've discussed it with
>  edhelas
>  > and he told me he uses XEP-0231 BOB for sending stickers.
>  >
>  > There are a few reasons why I'm not keen on using BOB:
>  >
>  > - BOB depends on XHTML-IM which is deprecated. Converse.js doesn't
>  support it
>  >    and I'm reluctant to add support just for this.
>  > - BOB mentions that binary data should be smaller than 1KB. Not sure
>  how
>  >    relevant that still is, but it discourages me from sending larger
>  amounts.
>  > - The sending client needs to maintain a cache of all sent stickers.
>  > - AFAICT, when receiving an uncached BOB message via MAM and the
>  sending client
>  >    is offline, then you can't get the image data.
>  >
>  > Instead, I propose that we use XEP-0372 references to indicate that a
>  > particular shortname (e.g. :dancingpanda:) should be replaced with an
>  image.
>  >
>  > For example:
>  >
>  >        >          I feel like dancing! :dancingpanda:
>  >            >                  begin="21"
>  >                  end="35"
>  >                  type="data"
>  >                  uri="[5]https://images.com/dancingpanda"/>
>  >      
>  >
>  > I'm not sure whe

Re: [Standards] Support for stickers (custom emojis)

2019-10-18 Thread JC Brand

On Thu, Oct 17, 2019 at 01:46:26PM +, Sam Whited wrote:
> TL;DR — we should avoid using XEP-0372 until "TODO: define character
> appropriately" is removed and resolved.

XEP-0394 (Message Markup) works similarly to XEP-0372 and defines the
"start" and "end" values in "units of unicode code points in the
character data of the body element".

This seems better than bytes because then you'll never have an offset in the
middle of a UTF-8 encoding.

You might still have an offset in between two codepoints that should ideally be
shown together like "EU" making the EU flag, but this seems less of an issue to
me.

I therefore think we should just do the same for XEP-0372. It would in any case
be crazy to specify one way of doing things in XEP-0394 and another in XEP-0372.

JC

 
> On Thu, Oct 17, 2019, at 10:07, JC Brand wrote:
> > Instead, I propose that we use XEP-0372 references to indicate that
> > a particular shortname (e.g. :dancingpanda:) should be replaced with
> > an image.
> >
> > For example:
> >
> >  I
> >  feel like dancing! :dancingpanda:  >  xmlnx="urn:xmpp:reference:0" begin="21" end="35" type="data" uri="
> >  https://images.com/dancingpanda"/> 
> 
> We should avoid using references in the wild until a few things are
> cleared up. We don't want lots of pre-mature implementations popping up
> that aren't compatible with one another.
> 
> For example, in the following message:
> 
> "> ☃︎ :sadpanda:"
> 
> Should the start attribute for ":sadpanda:" be 4 or 5? Unicode snowman
> is 2 bytes, after all.
> 
> What about:
> 
> "🇪🇺 :sadpanda:"
> 
> Which may be rendering as an EU flag or as the separate letters 'E', 'U'
> depending on your rendering?
> 
> The easiest way is to probably just say that the offset is in bytes, but
> now what do we do if a buggy or malicious client sends something with
> the offset in the middle of the UTF-8 encoding for the snowman emoji?
> What about in the middle of the two codepoints that will be combined to
> create the EU flag glyph which would still be between valid UTF-8
> encodings?
> 
> This is not an easy problem, and while I don't want to tackle trying to
> solve it in this thread, I think references should be avoided until we
> do or we'll never get all the implementations doing one thing later (and
> emojis are exactly the kind of feature that will lead to lots of
> implementations).
> 
> —Sam
> 
> 
> -- 
> Sam Whited
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Support for stickers (custom emojis)

2019-10-20 Thread JC Brand

On Sat, Oct 19, 2019 at 04:41:19PM +, Sam Whited wrote:
> On Sat, Oct 19, 2019, at 04:57, JC Brand wrote:
> > You might still have an offset in between two codepoints that should
> > ideally be shown together like "EU" making the EU flag, but this seems
> > less of an issue to me.
> 
> I don't know if this is better or not, and I'm still not sure how best
> to handle it. If you end up with text in the middle of a UTF-8 encoding,
> at least that's clearly an error. If it's in between the two letters in
> a flag emoji, that's not necessarily an error and there are tons of
> different ways you could handle it, which seems much more complex

You don't need tons of ways, you can just follow the instructions. If the
sending client is buggy, then this will become clear over time.

> Does this break the flag emoji back into the letter glyphs that are
> shown if it doesn't form a flag?

Yes, you just render the two letters separately given that this is
what's implied by the information you've been given and it's also a 
legitimate use-case.

By referencing only one of two consecutive letter glyphs, you're indicating
that they're logically distinct, so it makes sense that they're not rendered
together. In any case, usually you'll want to somehow highlight, make clickable
or replace the referenced text, thereby affirming the need to render them
separately.

> What if it's between something and a
> zero-width joiner that would join it to another glyph, does that split
> that and now you have a dangling joiner?

This is as clearly an error as setting an offset in the middle of a UTF-8
encoding.

> From a code perspective does
> this mean that highlighting always has to integrate with the text
> rendering engine? This seems like a *major* downside to me, as it likely
> makes the code much more complicated, and we may or may not even have
> the ability to manipulate how the text rendering engine handles things.

It's not clear to me why you think highlighting will necessarily require
integration with the rendering engine. It should be possible to identify
unicode codepoints in a string independent of any rendering engine.

signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A Short Note about "Tedd Sterr"

2019-11-25 Thread JC Brand

Thank you Tedd , for the excellent work you're doing recording the minutes and 
the voting. It's been a big help for me as well, as I'm sure for many others.

And here I thought Tedd was your real name. 🤔



Am 26. November 2019 01:18:31 MEZ schrieb Tedd Sterr :
>I saw the title and started wondering "oh no, what have I been accused
>of?"
>
>I'm glad what I do is useful and appreciated; I like to help make
>things happen, as I'm sure others do too, so I hope we can all continue
>doing that.
>
>I'm less sure that I should be singled out - others do much more, and
>many more do great work as their time allows. Maybe we can all thank
>everyone else for what they contribute; we each provide something for
>the others to build on, and despite the arguments and endless
>bikeshedding, we produce something that's beneficial for everyone -
>great work everybody!
>
>Let's do more cool stuff.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0425 (Message Moderation)

2020-01-24 Thread JC Brand



Am 24. Januar 2020 15:03:01 MEZ schrieb "Jonas Schäfer" :
>
>
>23 Jan 2020 10:19:49 pm Paul Schaub :
>
>> Hi everyone!
>>
>> I have a question regarding the element. Is the text content
>> inside the reason element mandatory? If so, what should be a default
>> reason text. If not, is is okay to leave the element empty, like
>> or or should the element be omitted in such
>> case?
>
>It seems to me as if there is no way to omit the reason, by looking at
>the examples.
>
>If we wanted to omit the reason, the proper way would be by omitting
>the element altogether.

Author here ..

Yes, I considered the "reason" element to be optional

Should the XML schema reflect this somehow?

JC




>(Also, I need to report a bug against my MUA for stripping out the XML
>in the qoutation.)
>>
>> Paul
>>
>> On 01.11.19 11:41, li...@opkode.com wrote:
>>
>> > Version 0.1.0 of XEP-0425 (Message Moderation) has been released.
>> >
>> > Abstract:
>> > This specification defines a method for groupchat moderators to
>> > moderate messages.
>> >
>> > Changelog:
>> > Accepted by vote of Council on 2019-10-16. (XEP Editor (jcb))
>> >
>> > URL: https://xmpp.org/extensions/xep-0425.html
>> >
>> > Note: The information in the XEP list at
>https://xmpp.org/extensions/
>> > is updated by a separate automated process and may be stale at the
>> > time this email is sent. The XEP documents linked herein are up-to-
>> > date.
>> > ___
>> > Standards mailing list
>> > Info: https://mail.jabber.org/mailman/listinfo/standards
>> > Unsubscribe: standards-unsubscr...@xmpp.org
>> > ___
>> >
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
>
>
>--
>Jonas Schäfer
>This was sent from mobile, and I'm not good with those. Sorry for
>brevity and such.
>
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0430 (Inbox)

2020-02-08 Thread JC Brand



Am 3. Februar 2020 19:54:29 MEZ schrieb Florian Schmaus :
>On 29.01.20 15:21, Jonas Schäfer (XSF Editor) wrote:
>> Version 0.1.0 of XEP-0430 (Inbox) has been released.
>> 
>> Abstract:
>> This specification proposes a mechanism by which clients can find a
>> list of ongoing conversations and their state.
>> 
>> Changelog:
>> Accepted by vote of Council on 2020-01-22. (XEP Editor (jsc))
>> 
>> URL: https://xmpp.org/extensions/xep-0430.html
>
>After re-reading this inbox xep I was surprised to find that there
>appears to be no indication how to determine which conversation has the
>most recent unread message(s).

In section 2.2 it states:

"The Inbox consists semantically of a list of conversations in order of last 
activity."

 - JC

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

2020-02-08 Thread JC Brand



Am 30. Januar 2020 11:44:33 MEZ schrieb "Jonas Schäfer" :
>On Donnerstag, 30. Januar 2020 08:45:22 CET Daniel Gultsch wrote:
>> Am Mi., 29. Jan. 2020 um 16:34 Uhr schrieb Jonas Schäfer 
>:
>> > 5. Is the specification accurate and clearly written?
>> 
>> I share Sam’s concerns regarding the title.
>> 
>> Maybe the benefits of Bookmarks 2 over Bookmarks need to be spelled
>> out more. Otherwise neither developers (as demonstrated by Phililpp)
>> nor the approving body will know why they should use or accept this
>> XEP.
>> 
>> The arguments for 402 I'm raising above are good; but I don’t want to
>> personally tell them to every developer in order to convince them.
>> That's the XEPs job.
>
>Bikeshed: "Atomic Bookmarks in PEP"?

I like it, it's more descriptive.

- JC



-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management



On 13.02.20 21:13, Florian Schmaus wrote:

On 2/11/20 4:21 PM, Jonas Schäfer (XSF Editor) wrote:

The XEP Editor would like to Call for Experience with XEP-0198 before
presenting it to the Council for advancing it to Final status.

With the advent of WebSockets and QUIC around the corner, we shouldn't
miss the opportunity to allow stream resumption over different
transports (TCP, BOSH, WebSocket, QUIC, …).


Stream resumption over BOSH doesn't make sense since it already has it's 
own session management tokens (SID and RID).



XEP-0198 works well over Websocket. Converse.js has support for that.

JC



I am not sure if this is actually feedback for xep198, as "Stream
Management for QUIC" could be simply another XEP. But maybe xep198 could
at least mention that it is not strictly limited to RFC6120-like TCP
transport bindings, while stream management for other transports are
outside the scope of xep198 and instead specified in their own XEP?



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management



On 14.02.20 11:06, Andrew Nenakhov wrote:

пт, 14 февр. 2020 г. в 14:03, Dave Cridland :

With the advent of WebSockets and QUIC around the corner, we shouldn't
miss the opportunity to allow stream resumption over different
transports (TCP, BOSH, WebSocket, QUIC, …).

I think people do that already. I vaguely remember a conversation where I 
suggested that '198 wasn't useful on BOSH, and got told that it was used for 
BOSH->WebSocket transitioning (since apparently the startup is then faster and 
more reliable).

For what it's worth, our iOS and web versions work perfectly fine
without XEP-0198. Android version will have it removed, too. Restoring
a state > resumption of a stream.
How are you able to receive stanzas that were sent to you during the 
short period that you were disconnected?



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management



On 11.02.20 16:21, Jonas Schäfer (XSF Editor) wrote:

The XEP Editor would like to Call for Experience with XEP-0198 before
presenting it to the Council for advancing it to Final status.


During the Call for Experience, please answer the following questions:

1. What software has XEP-0198 implemented? Please note that the
protocol must be implemented in at least two separate codebases (at
least one of which must be free or open-source software) in order to
advance from Draft to Final.


Converse.js (MPLv2) supports XEP-0198 over websocket connections.


2. Have developers experienced any problems with the protocol as
defined in XEP-0198? If so, please describe the problems and, if
possible, suggested solutions.
Like others, I've encountered counter bugs. Unsure whether anything can 
be done in the XEP about this.

3. Is the text of XEP-0198 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

AFAICT yes.

If you have any comments about advancing XEP-0198 from Draft to Final,
please provide them by the close of business on 2020-02-25. After the
Call for Experience, this XEP might undergo revisions to address
feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.


No.


You can review the specification here:

https://xmpp.org/extensions/xep-0198.html

Please send all feedback to the standards@xmpp.org discussion list.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management


On 20.02.20 11:49, Florian Schmaus wrote:

On 20.02.20 11:24, JC Brand wrote:

On 13.02.20 21:13, Florian Schmaus wrote:

On 2/11/20 4:21 PM, Jonas SchÃ¤fer (XSF Editor) wrote:

The XEP Editor would like to Call for Experience with XEP-0198 before
presenting it to the Council for advancing it to Final status.

With the advent of WebSockets and QUIC around the corner, we shouldn't
miss the opportunity to allow stream resumption over different
transports (TCP, BOSH, WebSocket, QUIC, â€¦).

Stream resumption over BOSH doesn't make sense since it already has it's
own session management tokens (SID and RID).

Quite contrary, even tough BOSH has a SM like mechanism built-in, I
think SM-for-BOSH is useful if you want to resume a stream previously
established via different transport, e.g. WebSocket or RFC6120-like TCP.


BOSH has it's own timeout independent from SM, so I can imagine that
causing issues when trying to switch from BOSH to some other transport.

In a web-client, you'll run into problems even if you don't switch
transports. When you're using BOSH and then reload the page (and
reconnect with BOSH), your reconnecting to a still-running BOSH session,
there's nothing to resume SM-wise and trying to do so simply confuses
the XMPP server.

I remember lots of errors occurring server-side when I (mistakenly)
enabled SM for a BOSH connection.

These issues could probably be addressed server-side, but to day I'm not
aware of any servers that support SM over BOSH.

So, lots of extra complexity for what's IMO an edge case.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management



On 20.02.20 11:37, Andrew Nenakhov wrote:

чт, 20 февр. 2020 г. в 15:33, JC Brand :

For what it's worth, our iOS and web versions work perfectly fine
without XEP-0198. Android version will have it removed, too. Restoring
a state > resumption of a stream.

How are you able to receive stanzas that were sent to you during the
short period that you were disconnected?

Through the message archive and with our device sync protocol.
What if you had only one device and presence stanzas were sent during 
the disconnection?


With your way of doing things, you'd have to query MAM every time you 
load a web-page that contains an XMPP chat. Seems excessive.


I know your web chat client isn't meant to be embedded in websites where 
people navigate around, but that is a common use-case.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

2020-02-21 Thread JC Brand

On 20.02.20 20:57, Andrew Nenakhov wrote:
чт, 20 февр. 2020 г. в 16:05, JC Brand <mailto:li...@opkode.com>>:

> > Through the message archive and with our device sync protocol.
> What if you had only one device and presence stanzas were sent during
> the disconnection?
>
> With your way of doing things, you'd have to query MAM every time you
> load a web-page that contains an XMPP chat. Seems excessive.
>
> I know your web chat client isn't meant to be embedded in websites where
> people navigate around, but that is a common use-case.

Well. This requires an explanation of how we see things. What is, 
exactly, a use-case for stream management? It helps in situations, 
when a connection is lost frequently, yet, briefly. Where can this 
occur? On a desktop, with a stable connection, it is hardly a problem: 
connections are stable there, and if something happens, one full 
reconnect every 30 minutes (much more rare in practice) is something 
any client can tolerate. This leaves us with mobile devices and browsers.

Mobile clients are, currently, a valid use-case for stream management. 
Mobile devices often hop from wifi to cellular connection and back, 
are brought to places with bad signal coverage, so they can benefit 
from SM. However, only on one platform - Android. iOS devices would 
not benefit from stream management at all - they can't maintain 
connection in the background, and rely on APNS to receive 
notifications about a necessity to connect to server. Android seems to 
be on the same trajectory: persistent processes have more and more 
difficulties living in the background with each release. Some 
manufacturers even make it even worse, see https://dontkillmyapp.com/

I believe that writing is on the wall for mobile devices, and in the 
long term we are destined to be forced to use push notifications in 
the future. So, only browsers remain.

If a browser is emulating a full-on desktop app, like Xabber for Web, 
it does not really need SM, just as desktop apps don't need it. If it 
behaves like converse.js, reloading on every page... well... it's a 
reasonable place to use SM. I personally can't really imagine a 
scenario where a user might want to have a real XMPP experience that 
way, complete with roster and presences, but I trust you that you know 
your users better.

I have worked on deployments where Converse.js is integrated together 
with roster and presences and/or MUC presences and where pages are 
regularly reloaded (i.e. not a single-page app).

Other people have integrated it into Diaspora and other FOSS social 
networking sites, many which aren't single-page apps and therefore cause 
page reloads when people navigate around.

The site I'm working on currently will eventually want DMs and the 
ability to request a DM (aka presence) and it's also not a full SPA.

(I can very well imagine a scenario where an XMPP is used on a website 
to provide an olark/purechat/livechat chat widget to talk to site 
owners, and in fact we're making a rather nice chat widget ourselves 
<https://demo.webchat.dev.xabber.com>, powered by our awesome group 
chat protocol, we break it from time to time and do not always answer 
to incoming requests, so I don't promise stability just yet)

So. Back to SM. Long term, we're dealing with 2 types of clients: one 
that have a stable connection, and ones that connect to servers 
infrequently and do not maintain a connection at all. The latter type 
of clients relies on message archive and our device sync protocol, and 
I can't call fetching messages from an archive as some excess, and 
practice shows it works quite well. (btw, we're disabling offline 
messages)

As Daniel and Guus have pointed out, you're not dealing with only these 
two types of clients. You can also have laptops connected to spotty wifi.

What other problems we have with reconnection? Roster and presences. 
Roster is mostly not a problem thanks to roster versioning. Presences. 
It's a big problem I'm still on the fence for this one. Receiving all 
presence information on each reconnect is not the ideal solution. I'm 
thinking of using a presence versioning, akin to roster versioning, or 
maybe to eschewing presences at all. The idea of 'always on' messaging 
has some merit to it with always connected modern mobile devices, 
however, personally, I am not ready to give up on green light bulbs on 
contacts just yet.

Is there anything specific about SM that you don't like?

It's more lightweight than having to do MAM requests for all open chats 
as well as making a new roster request every time your connection drops 
and it also solves the problem of presences being dropped.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience: XEP-0198: Stream Management

2020-03-04 Thread JC Brand



On 26.02.20 12:25, Andrew Nenakhov wrote:

пт, 21 февр. 2020 г. в 14:33, JC Brand :

I have worked on deployments where Converse.js is integrated together with 
roster and presences and/or MUC presences and where pages are regularly 
reloaded (i.e. not a single-page app).

Btw, I assume you use a strophe.js library. Personally, I didn't dive
into details, but my web developers who work with  web version of
Xabber, which also uses this library currenlty, complained to me about
SM implementation there. It was something about it counting stanzas
differently than ejabberd does. It was over a year ago so I am not
very sharp on details, but I can ask them for a clarification, email
me directly pls if you want it.


Converse uses Strophe.js but doesn't use any Strophe plugins (which 
includes SM).


Converse has its own independent SM module.

BTW, I know that someone from Jitsi was working on the Strophe SM plugin 
recently.



-JC

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: MUC presence versioning

2020-04-01 Thread JC Brand


On 01.04.20 08:48, Philipp Hancke wrote:

Am 31.03.20 um 20:35 schrieb Jonas Schäfer (XSF Editor):

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: MUC presence versioning
Abstract:
This specification defines a versioning mechanism which reduces the
amount of presence traffic in a XEP-0045 MUC

URL: https://xmpp.org/extensions/inbox/muc-presence-versioning.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.


While I understand that we all love disco, wouldn't it be easier to 
only send the ver attribute if one was received from the muc in the past?


IMO you should already be doing disco for a MUC before joining it, so 
this doesn't add much extra work and it has the advantage of adhering to 
the prevailing convention.


Or is that to avoid MUC rooms not understanding this feature 
broadcasting it as part of the presence?
I didn't explicitly think of this, but in general I think it's helpful 
to have the ability to know beforehand what features a MUC supports.
(a MUC should also remove this attribute before broadcasting since 
this would otherwise leak a tiny bit of information about the last join)


I'll add this to the security considerations section.


-JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: MUC presence versioning

2020-04-01 Thread JC Brand




On 01.04.20 16:27, Georg Lukas wrote:

Hi together,

* Jonas Schäfer  [2020-03-31 20:39]:

Title: MUC presence versioning

This is an awesome extension to the MUC protocol, and I think it fits in
well. Next step is to re-organize the MUC membership query from four IQs
to something with differential semantics as well ;)


This protoXEP comes from discussions I had with Matthew Wild about this.

I was wondering about implementing versioning for the membership lists,
and then Matthew suggested presence versioning instead.

He deserves credit for the good ideas in here.



Re disco#info:


While I understand that we all love disco, wouldn't it be easier
to only send the ver attribute if one was received from the muc in
the past?

That would require that the client received a presence before from the
MUC, i.e., that the client joined the MUC room before.

The client doesn't know a @ver value anyway when joining for the first
time, and in absense of a @ver, the server will send the full presence
list. This would of course break Business Rule #2, for which I can't see
any rationale.

If the server will always add @ver, regardless of client-side support
indication for Presence Versioning, then a supporting client can flag
the MUC as capable and store the last received @ver element solely based
on its existence, without an extra disco#info roundtrip.


I'm not sure about other clients, but Converse.js does a disco#info in any
case before joining a MUC, so it's not an extra roundtrip.

However, a client can opt to not do a disco query at all and simply check
whether it gets a 'ver' attribute back, like you and others have described.

I'll update the protoXEP text to make it clear that supporting MUCs should
always return a 'ver' attribute for this very reason.


 From section 4:

| If a MUC receives a presence version number that's so old, so that it
| no longer has the corresponding state available, it needs to send all
| presence statuses back to the client.

The server needs to prepend some kind of reset token to that, otherwise
the client will interpret the new presence as a delta to its existing
stored presence, and keep ghosts of the users that left since the client
left.


Yes, this would be necessary unless the additional measures in the bottom of
of the protoXEP are implemented.

If the server only sends presence for affiliated users (see 5.1) and 
also sends

unavailable presences (see 5.2.1), then ghost users won't be created.

I was however reluctant to make these two criteria required for message 
versioning,

which is why I added them to "additional measures".

Not all MUCs will want to configure themselves this way, but it's IMO a 
pretty

good way to implement a Slack-style MUC.

But for the cases where MUCs aren't configured in this way,
we'd need something like the reset token you mentioned.

However, if the reset token is received too late, then the client might 
already have
acted on false assumptions on the presence stanzas it received before 
the reset token.


So the reset token needs to be the first thing the client sees, so that 
it can
act accordingly (for example by wiping the slate clean) before the 
presences start

coming in.

The 'ver' attribute comes with your self-presence stanza and initially I 
thought of
putting the reset token there, if that was always received first, then 
it wouldn't be

a problem, but this isn't currently a requirement anywhere AFAIK.

Alternatively, the MUC should return an error presence if the version
is no longer cached and the client should then send a new join presence
without a 'ver' attribute.

Any thoughts on this?



This would be a repetition of failure mode #2 of GroupChat 1.0 -
see https://mail.jabber.org/pipermail/standards/2017-October/033501.html

 From §5.2.1:

| it's possible to provide any necessary presence metadata of all
| relevant users in a groupchat and not just the currently "present"
| users.

This sounds like the opposite of the goal of §5, which is to reduce the
number of stanzas sent.

Yes when read in isolation, but when taking into consideration what I 
wrote above

I believe the intent will be more clear.

I'll try to make this more clear in the document.


The right rationale would probably be to let the client know of all
members of the MUC and their respective roles. If we make that feature
discoverable and integrated into Presence Versioning, the client doesn't
need to run four IQ queries for owner, admin, member and outcast.


Yes, this pretty much sums up the need for what's in the "additional 
measures" section.


If the MUC could always send all presences (including offline ones)
for affiliated users, and then also include a reset token when sending 
the full

presence state, then we can avoid the 4 IQ queries and ghost users.

So I think I need to move 5.1 from "additional measures" to "requirements"
and change "Only" to "Always". And then move 5.2.1 also to "requirements"
and make clear that it's only for affiliate

Re: [Standards] XEP-0424: Service discovery on the server side

2020-05-17 Thread JC Brand

Hi Pawel,

sorry for taking so long to respond, this email didn't come up on my radar.

On Mon, May 04, 2020 at 01:48:52PM +0200, Pawel Chrzaszcz wrote:

 8-< 

>According to the XEP: "If a client or service implements message
>retraction, it MUST specify the 'urn:xmpp:message-retract:0' feature in
>its service discovery information features".
>When should the server include this feature in its discovery information?
>If a client sends a discovery request to the address of the main XMPP
>service, should the server response contain this feature if the server
>archives retraction messages in MAM (XEP-0313)? This should be enough to
>satisfy the only mandatory server-side requirement of the XEP.

Yes, I agree and will update the text to make this more explicit.

>Another option would be to advertise this feature only if messages are
>really removed or replaced with tombstones whenever a retract message is
>received. However, support for actual removal of messages is not mandatory
>in the XEP.

Yes, so for tombstones we can be more specific and let the XMPP server advertise
"urn:xmpp:message-retract:0#tombstones" if it supports turning retracted
messages into tombstones.

I'll update the XEP accordingly.

>MongooseIM would replace the messages with tombstones if such
>a feature is enabled by the user.
>I think that whatever rule is chosen, the same should apply for a MUC
>service if message archive/retraction is enabled for it.

Yes, agreed.

Regards
JC


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0424: Service discovery on the server side

2020-05-28 Thread JC Brand

Hi Pawel,

please see my replies inline.

On 18.05.20 10:15, Pawel Chrzaszcz wrote:

Thanks for your response JC.

There are a few more details that I think would be good to clarify.

Currently when a retraction message is processed by the server, the 
following criteria are used to find the original message - let's focus 
on 1-to-1 chat messages:

  * The |id| attribute specified in the |apply-to| element of the
retraction message has to be the same as the |id| attribute of the
|origin-id| element of the original message (required by XEP-0424).
  * Both messages need to originate from the same user (also required
by the XEP).
  * Both messages need to be addressed to the same user - not required
by the XEP, but it does not make sense to send a retraction
message to a different user.

This is done by the sender's server (outgoing message) and the 
recipient's server (incoming message). The operation is also done 
twice if there is one common server for both users.

If more than one message matches the criteria, only the most recent 
one is retracted (replaced with a tombstone).

The origin ID is supposed to be globally unique, so there shouldn't ever 
be more than one message that matches and if there is, then there is an 
implementation error somewhere.

If no messages match the criteria, no messages are retracted.

The problem is that if the sender made a mistake and sent a message 
with an incorrect origin-id or to a wrong user, there would be no 
direct feedback to the sender. Do you think it is an issue?

I'm not sure whether there's anything that the server can do here. How 
would it know that the retraction was sent to the wrong user? It might 
be that someone is trying to retract a message that's no longer in any 
server-side archive or cache, but which might still be stored 
client-side, and the correct thing to do then is to simply relay the 
retraction to the recipient.

Regards
JC

On Sun, May 17, 2020 at 10:14 PM JC Brand <mailto:li...@opkode.com>> wrote:

Hi Pawel,

sorry for taking so long to respond, this email didn't come up on
my radar.

On Mon, May 04, 2020 at 01:48:52PM +0200, Pawel Chrzaszcz wrote:

 8-< 

>    According to the XEP: "If a client or service implements message
>    retraction, it MUST specify the 'urn:xmpp:message-retract:0'
feature in
>    its service discovery information features".
>    When should the server include this feature in its discovery
information?
>    If a client sends a discovery request to the address of the
main XMPP
>    service, should the server response contain this feature if
the server
>    archives retraction messages in MAM (XEP-0313)? This should
be enough to
>    satisfy the only mandatory server-side requirement of the XEP.

Yes, I agree and will update the text to make this more explicit.

>    Another option would be to advertise this feature only if
messages are
>    really removed or replaced with tombstones whenever a retract
message is
>    received. However, support for actual removal of messages is
not mandatory
>    in the XEP.

Yes, so for tombstones we can be more specific and let the XMPP
server advertise
"urn:xmpp:message-retract:0#tombstones" if it supports turning
retracted
messages into tombstones.

I'll update the XEP accordingly.

>    MongooseIM would replace the messages with tombstones if such
>    a feature is enabled by the user.
>    I think that whatever rule is chosen, the same should apply
for a MUC
>    service if message archive/retraction is enabled for it.

Yes, agreed.

Regards
JC
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Very Simple Questions about Compliance Suites

2020-09-03 Thread JC Brand




On 02.09.20 17:23, Dave Cridland wrote:

Hey all,

Really simple questions, so please do reply and answer:

If you have an XMPP product or public project, do you claim compliance 
with XEP-0423?


Converse is about 80% compliant.
https://github.com/conversejs/converse.js/issues/1398

I think the lack of compliance badges is a bigger issue than some people 
might think. On Github/Gitlab badges is the main way in which projects 
quickly communicate their features, and I believe in this case they 
would provide a form of peer pressure which will motivate some projects 
(like ours) to get 100% compliance in order to show a shiny badge.


Also, without the badges, I suspect that most people are blissfully 
unaware of the compliance suites and/or whether they're supported by a 
particular project.


If you do not claim compliance, are you aiming for compliance with 
XEP-0423?
It would be nice to have 100% compliance, but I'm not motivated to spend 
the time on it. Especially if there isn't an easy way to brag about it 
(*cough* badges *cough*).


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Off-by-one error in XEP-372 "References"

2020-12-04 Thread JC Brand


Hey folks

In XEP-0372 in section 3.1, there is the following text:


An end attribute is similarly  used for the index of the last character of the 
reference


However, in the example in 3.2, the "end" attribute is set to 78, which 
is the index of the space after the nickname "Juliet".


The example appears to contradict the text. I'd like to fix this, but 
I'm not sure what the original author's intention was. I'm assuming the 
text is correct and the example is wrong.


AFAIK only Converse.js and maybe Movim support this incomplete XEP.

If anyone else is using it, I'd appreciate it if you could let me know 
which offset you're using. Converse is currently following the example 
in the XEP, i.e. i+1.


Thanks
JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Off-by-one error in XEP-372 "References"

2020-12-07 Thread JC Brand


Thanks everyone for the feedback.

I've made a PR here: https://github.com/xsf/xeps/pull/1018

The proposed change is the have the begin index inclusive and the end 
index exclusive, similarly to how Converse and Xabber do it currently.


This is known as the Dijkstra convention, and I presume it's based on 
his proposal here: 
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html


This matches how subsequence indexing is done in many programming 
languages and has the added advantages that 'end' minus 'begin' equals 
the length of the substring and if two referenced substrings are 
adjacent, then the 'end' of the first matches the 'begin' of the second.


This also appears to be the convention most people in the thread 
appeared to agree with.


- JC



On 04.12.20 13:31, JC Brand wrote:

Hey folks

In XEP-0372 in section 3.1, there is the following text:

An end attribute is similarly  used for the index of the last 
character of the reference


However, in the example in 3.2, the "end" attribute is set to 78, 
which is the index of the space after the nickname "Juliet".


The example appears to contradict the text. I'd like to fix this, but 
I'm not sure what the original author's intention was. I'm assuming 
the text is correct and the example is wrong.


AFAIK only Converse.js and maybe Movim support this incomplete XEP.

If anyone else is using it, I'd appreciate it if you could let me know 
which offset you're using. Converse is currently following the example 
in the XEP, i.e. i+1.


Thanks
JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] MUC Mention Notifications

2020-12-18 Thread JC Brand


Hi all

I've submitted a PR for a new protoXEP: MUC Mention Notifictions

https://github.com/xsf/xeps/pull/1022

The goal is to document how someone who's affiliated, but not currently 
present in a MUC might receive notifications when he/she is mentioned 
inside that MUC.


For the concept of "mentions", XEP-0372 references are used.

To enable this feature, I've opted for a configuration setting in the MUC.

Apparently Tigase already has a similar feature to this protoXEP and 
relies on letting the user opt-in when registering a nickname with the MUC.


Maybe someone from Tigase can comment on the particulars of that. My 
understanding is that this necessitates the ability to self-register in 
a MUC, which IMO adds a hurdle to adoption of this feature.


Regards
JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications




On 18.12.20 19:10, Dave Cridland wrote:
On Fri, 18 Dec 2020 at 17:01, JC Brand <mailto:li...@opkode.com>> wrote:


Hi all

I've submitted a PR for a new protoXEP: MUC Mention Notifictions

https://github.com/xsf/xeps/pull/1022
<https://github.com/xsf/xeps/pull/1022>


Thanks, this looks like a solid start and I will be voting to accept it.


Thanks, your cheque is in the mail.


Comments:

1) I think it would benefit from an example of the mention itself, 
though I assume it to be the message shown as forwarded in §3.2


Yeah, it would just be a copy paste of the inner . I've added 
some clarifying text to the bottom of the example.


2) Section 3.2 shows a message being forwarded to a full jid for the 
mentioned user - is this intentional?


Nope, fixed thanks.

3) The message forwarded doesn't contain, and is not accompanied by, a 
MAM stanza-id, which might be useful to locate it in the MUC archive. 
Can we include this if the room is archived?


Ok, I added it.

I was wondering whether I should include the stanza-id or not and 
originally decided not to in order to keep the stanza clear and to the 
point of this particular XEP.


Thanks
JC

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications





On 19.12.20 16:41, Andrzej Wojcik wrote:

To enable this feature, I've opted for a configuration setting in the 
MUC.


Apparently Tigase already has a similar feature to this protoXEP and 
relies on letting the user opt-in when registering a nickname with 
the MUC.


Maybe someone from Tigase can comment on the particulars of that. My 
understanding is that this necessitates the ability to self-register 
in a MUC, which IMO adds a hurdle to adoption of this feature.


Our approach was designed to solve MUC issue on the iOS based device 
where XMPP connection cannot be kept alive while in the background.


The idea was to enable MUC room to send groupchat messages (any 
message, not just mentions) to the user even if he is offline.
Additionally with nickname registration, we were able to present 
offline users but subscribed with offline notifications as away in the 
rooms.
That also allowed us to block nickname from being used in this room by 
anyone else and did not require any modification on the senders client 
side as the room was forwarding all messages and thanks to the logic 
on users local server push notifications to the users client were 
generated.


In the proposed protoXEP  element contains real bare JID 
of the user affiliated with the room, which is available, if I'm 
correct, only in non-anonymous rooms. In semi-anonymous it may not be 
available. Due to that it restricts usage of the protoXEP only to the 
cases in which bare jids of users in the room are known to the occupants.


You could still reference the person by MUC JID and nickname, as long as 
the nickname is registered (i.e. exclusive to one user) in the MUC.


Additionally I'm not sure if affiliation of a user with a room is 
enough for sending notifications as nickname used to mention someone 
could be already taken by someone else (if affiliation will not block 
nickname from being reuse and AFAIR it does not).


I was under the assumption that all affiliated users have their 
nicknames registered (i.e. the nicks can't be taken by anyone else). Is 
this wrong?


If this requirement is too lax, then I guess we'll have to update the 
XEP to require nickname registration instead of (just) affiliation.




___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications





On 23.12.20 16:16, Marvin W wrote:

Hi there,

I actually was working on something with partially overlapping goals,
that is
a) being notified for relevant groupchat messages via push
notifications. This is mostly relevant for iOS push notifications (at
least as far as I understood during last summit).
b) signal to recipient that a message is important to notify about (for
example, when out of office, still notify for the really important
things). This is a feature some of you may know from Slack.

I was first thinking to base this around mentions as well, but that
would mostly work for a, not b (at least not how b is realized in Slack).

I thus was to suggest a much more generic approach, that is to add a new
element  to the message
(completely independent of any use of mentions/references). Jid could be
left out in direct chats, in MUCs can point to the real jid, member jid
or room jid (equivalent to @channel mentioning), also there might be
value in an optional priority="high" attribute to signal higher message
priority.

Your usecase of delivering messages to non-present MUC users seems to
fit into this schema. Also, adding server-side meaning to something that
is mostly formatting (mentions) seems a little bit weird to me.


I don't find it that weird. It's more implicit than adding a  
element,
but the XEP requires it to be configured in the MUC and it's not too 
crazy to

expect that when you mention someone, they'll be notified somehow.


Another advantage of the  element approach is that it also works
for server-side processing in e2ee message (without leaking relevant
message details) as long as the  is not e2e encrypted (which it
shouldn't be as it's also meant to be processed by servers).


That is indeed a significant advantage, and I like the idea of being
presented the option (like in Slack) on whether I'd like to notify
the person I'm mentioning or not.

I do see some ambiguity here though. My use-case specifically is
notifying someone who's not present in a MUC, but what about
someone who *is* present in a MUC.

I believe most clients currently will notify a user present in a MUC when
mentioned, but now the presence or absence of the  element
might make the sender-intended behaviour less clear.

Doesn't the absence of a  element mean that
that mentioned user shouldn't be notified at all, even when they're
present in the MUC?

And if it doesn't, then it implies that the  element is meaningless
for users who are currently present in the MUC, which seems semantically
confusing to me, as if the  elements' purpose is not clear from
its name.

Maybe this can be resolve by calling the element "notify-absent" instead.

What do you think?

JC



On 18.12.20 18:00, JC Brand wrote:

Hi all

I've submitted a PR for a new protoXEP: MUC Mention Notifictions

https://github.com/xsf/xeps/pull/1022

The goal is to document how someone who's affiliated, but not currently
present in a MUC might receive notifications when he/she is mentioned
inside that MUC.

For the concept of "mentions", XEP-0372 references are used.

To enable this feature, I've opted for a configuration setting in the MUC.

Apparently Tigase already has a similar feature to this protoXEP and
relies on letting the user opt-in when registering a nickname with the MUC.

Maybe someone from Tigase can comment on the particulars of that. My
understanding is that this necessitates the ability to self-register in
a MUC, which IMO adds a hurdle to adoption of this feature.

Regards
JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications





On 25.12.20 12:46, Marvin W wrote:



On 24.12.20 16:25, Matthew Wild wrote:

 would be largely duplicating the semantics of XEP-0372
mentions.

XEP-0372 (in its current version 0.4.0) does not specify any semantics
for mentions at all and (according to its introduction) only "provides a
mechanism for marking up a section of a message body with information
about the target of the reference".


You can specify type="mention" for the  (as in the example
in XEP-0372), to me that is semantic information.


 would only be about semantics and not about marking up in
message body at all. At least with the current specification, there
would be little to no overlap and definitely no duplication. Sure enough
you could go without the  element and create a XEP that adds
semantic meaning to a XEP-0372 mention (which is what the suggested
protoxep does). But I think splitting semantics and markup here makes a
lot of sense.


I do see semantic overlap, hence the ambiguity I was mentioning in my
other reply to your first email in this thread.


I am aware that some implementations may use XEP-0372 as an indicator to
notify users in MUCs, but those implementations probably would also do
this without XEP-0372 by matching body against the users nickname. Both
is obviously unspecified behavior.  is about adding a properly
specified method to (in the long run) replace such unspecified behavior.


I'd say that very often the whole point of mentioning someone is so that
they get notified and not just for markup/display reasons.

It could be argued that adding type="mention" to a  is
asking for the user to get notified.

I'm not against the idea of using  but I'd like the ambiguities to
be cleared up first before updating the XEP to use it.

JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MUC Mention Notifications

On 25.12.20 13:38, Philipp Hörist wrote:

Hi,

Ok i think i get it, its a warmed up  XEP. Not a very 
successful XEP btw.

Anyway back to the original use case for sending messages to people 
not joined the MUC

i think Marvins approach is easier.
But it does not replace the reference mention, because we still need 
that to mark up the text correctly. And yes references might be 
encrypted, depending on the uri attr and what i can reference in the 
future, so i would say we should not expect servers to be able to read 
references. And its a recipe for disaster to encrypt some references 
and others not.

I really see no way how we can use references for these server features.

Seems like we duplicating here a bit of functionality between the XEPs 
then, but i still think its the cleaner approach.

If you can't use references because they're encrypted, then how is the 
server supposed to know who is to be notified?

Should the  element then also contain the JID of the person 
being notified?

That would mean some information leakage, although it's still better 
than references because the  element

won't refer to parts of the text in the message body.

Am Fr., 25. Dez. 2020 um 12:49 Uhr schrieb Marvin W >:

Hi,

On 23.12.20 17:47, Philipp Hörist wrote:
> and when would a client add this notify tag? Should the client let
> the user decide? (I dont like that) Is there any reason why i would
> not add  to every message? I see no downside for the sender

Client should only add the  tag on user request (that is
because
they did a mention or otherwise signal they'd like to notify a user).
The priority="high" tag should be even more restricted, e.g. should be
confirmed by user explicitly. Client should not have an option to send
 with every message.

The downside for the sender is that the recipient probably doesn't
like
it when used without good reason and will probably hate you for doing
it. Obviously, recipient clients would need to have certain limits for
when they accept  (e.g. ignore them when in direct
messages from
strangers to not amplify the impact of spam or allow to disable
support
for it per-contact in case any of your important contacts just
uses this
feature too much).

In large communities I've already seen users making excessive or
unjustified use of @all or @channel, leading to their messages being
removed, them being warned and/or banned. There can also be a server
policy that only room members of a certain level are allowed to send
these messages (or in our case  tags). Having a more dedicated
feature for notifications that is not directly related to the message
body helps servers to enforce such policy.

Misuse of high priority notification (be it by adding a 
tag or
by mentioning) is a social issue that you can't tackle
meaningfully on a
protocol level alone.

On 24.12.20 16:25, Matthew Wild wrote:
>  would be largely duplicating the semantics of XEP-0372
> mentions.

XEP-0372 (in its current version 0.4.0) does not specify any semantics
for mentions at all and (according to its introduction) only
"provides a
mechanism for marking up a section of a message body with information
about the target of the reference".

 would only be about semantics and not about marking up in
message body at all. At least with the current specification, there
would be little to no overlap and definitely no duplication. Sure
enough
you could go without the  element and create a XEP that adds
semantic meaning to a XEP-0372 mention (which is what the suggested
protoxep does). But I think splitting semantics and markup here
makes a
lot of sense.

I am aware that some implementations may use XEP-0372 as an
indicator to
notify users in MUCs, but those implementations probably would also do
this without XEP-0372 by matching body against the users nickname.
Both
is obviously unspecified behavior.  is about adding a properly
specified method to (in the long run) replace such unspecified
behavior.

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards

Unsubscribe: standards-unsubscr...@xmpp.org

___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
__

[Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

Hi everyone

I've been reading XEP-0385 SIMS with an eye towards potentially
implementing it, when I noticed that a XEP-0300 hash is required, in
order to allow integrity checking and caching.

In the introduction of SIMS, the following is written:
"This proposal aims to provide a protocol that will enable XMPP clients
to implement a great user experience (UX) around the process of sharing
media in conversations."

I think making inclusion of the file hash mandatory is at odds with that
goal, the reason being that a lot of the media being shared in chats is
shared as URLs to 3rd parties where the media is hosted.
In other words, the sharer of the media doesn't necessarily know the
hash of the media because it was never on their own machine to begin with.

Here's the use-case I have in mind:

Romeo sees a funny picture on funnypics.com. He right-clicks on the
picture, copies the URL and sends it to Juliet. Before the message is
sent, Romeo's client does an HTTP HEAD request, to get information on
the URL, and learns that its an image.

Here's the response:

HTTP/2 200
last-modified: Fri, 02 Jul 2021 02:46:55 GMT
etag: "a1d5ea7e796f5da6980bed86a8396664"
content-type: image/jpeg
cache-control: public, max-age=31536000
accept-ranges: bytes
date: Fri, 02 Jul 2021 06:44:39 GMT
access-control-allow-methods: GET, OPTIONS
access-control-allow-origin: *
content-length: 110220

The "content-type" header can be used for the SIMS tag and
the "content-length" header for the .

The server also responds with an "etag" header, which can be used for
caching, but unfortunately not for integrity checking, since the method
by which it's generated is not specified.
If the etag is passed along via SIMS (instead of the hash), the
receiving client could also check whether it matches what's returned by
the webserver, although I'm not sure what conclusions can be drawn if
they don't match.

Before someone says that this scenario is not relevant to what SIMS is
trying to do, please note that this problem also occurs when someone
shares a file via HTTP upload and then the receiving party copies and
pastes that URL in a message to someone else. Perhaps an intelligent
enough client might go and get the hash from the original SIMS data and
then add that to the newly sent message, but that seems a bit contrived
to me and might not always be feasible.

So... back to the scenario. After Romeo's client has received the HEAD
headers, it can then construct a SIMS element with it.

Look
at this funny cat
pictureimage/jpegicanhazcheeseburger.jpg110220http://jabber.org/protocol/shim'>some-long-opaque-stringFat
cat that looks like it wants a
cheeseburgerhttps://funnypics.com/icanhazcheeseburger.jpg'/>

Note the inclusion of the ETag header (as defined in "XEP-0150: Use of
Entity Tags in XMPP Extensions") and the omission of a XEP-0300 hash
element.

If, for some reason the content-type and content-length headers can't be
used for the and tags, then they can also be
included as XEP-0131 headers (like the Etag).

So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash
requirement gets relaxed to a SHOULD and that the inclusion of the Etag
header be documented as an alternative in case a hash is not feasible.
There might also be cases where neither a hash or an Etag header is
available.

I'd be happy to make the necessary changes and submit a pull request.

Regards
JC

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing




On 02.07.21 12:42, Sergey Ilinykh wrote:

What about a slightly different scenario?

Romeo sees a funny picture on funnypics.com <http://funnypics.com>, 
copies it to a messenger's input field. The messenger prefetches the 
whole picture, generates a thumbnail (at least it's impossible to have 
a thumbnail without fetching everything), computes hashes and then 
sends. Optionally the picture can be put to a local cache and also 
become available over Jingle and other transfer methods.
Now Juliet having a thumbnail knows exactly if she wants to download a 
whole size picture.


But this is just about pictures. Probably sharing a bluray video by 
the link from the web won't work this well in this case. So I tend to 
agree having alternative  integrity checks looks reasonable. Also 
sharing arbitrary files via SIMS, not just multimedia, may require 
splitting the presentation and sharing into two dedicated XEPs.


Yeah, I'd be quite annoyed if I shared a link to a video and my client 
first insists on downloading the entire file so that it can send out a 
hash to the recipient.


-JC




пт, 2 июл. 2021 г. в 13:17, JC Brand <mailto:li...@opkode.com>>:


Hi everyone


I've been reading XEP-0385 SIMS with an eye towards potentially
implementing it, when I noticed that a XEP-0300 hash is required, in
order to allow integrity checking and caching.

In the introduction of SIMS, the following is written:
"This proposal aims to provide a protocol that will enable XMPP
clients
to implement a great user experience (UX) around the process of
sharing
media in conversations."

I think making inclusion of the file hash mandatory is at odds
with that
goal, the reason being that a lot of the media being shared in
chats is
shared as URLs to 3rd parties where the media is hosted.
In other words, the sharer of the media doesn't necessarily know the
hash of the media because it was never on their own machine to
begin with.

Here's the use-case I have in mind:

Romeo sees a funny picture on funnypics.com
<http://funnypics.com>. He right-clicks on the
picture, copies the URL and sends it to Juliet. Before the message is
sent, Romeo's client does an HTTP HEAD request, to get information on
the URL, and learns that its an image.

Here's the response:

HTTP/2 200
last-modified: Fri, 02 Jul 2021 02:46:55 GMT
etag: "a1d5ea7e796f5da6980bed86a8396664"
content-type: image/jpeg
cache-control: public, max-age=31536000
accept-ranges: bytes
date: Fri, 02 Jul 2021 06:44:39 GMT
access-control-allow-methods: GET, OPTIONS
access-control-allow-origin: *
content-length: 110220

The "content-type" header can be used for the SIMS 
tag and
the "content-length" header for the .

The server also responds with an "etag" header, which can be used for
caching, but unfortunately not for integrity checking, since the
method
by which it's generated is not specified.
If the etag is passed along via SIMS (instead of the hash), the
receiving client could also check whether it matches what's
returned by
the webserver, although I'm not sure what conclusions can be drawn if
they don't match.

Before someone says that this scenario is not relevant to what
SIMS is
trying to do, please note that this problem also occurs when someone
shares a file via HTTP upload and then the receiving party copies and
pastes that URL in a message to someone else. Perhaps an intelligent
enough client might go and get the hash from the original SIMS
data and
then add that to the newly sent message, but that seems a bit
contrived
to me and might not always be feasible.

So... back to the scenario. After Romeo's client has received the
HEAD
headers, it can then construct a SIMS element with it.


Look

at this funny cat

pictureimage/jpegicanhazcheeseburger.jpg110220http://jabber.org/protocol/shim

<http://jabber.org/protocol/shim>'>some-long-opaque-stringFat

cat that looks like it wants a

cheeseburgerhttps://funnypics.com/icanhazcheeseburger.jpg'/

<https://funnypics.com/icanhazcheeseburger.jpg'/>>


Note the inclusion of the ETag header (as defined in "XEP-0150:
Use of
Entity Tags in XMPP Extensions") and the omission of a XEP-0300 hash
element.

If, for some reason the content-type and content-length headers
can't be
used for the  and  tags, then they can also be
included as XEP-0131 headers (like the Etag).

So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash
requirement gets relaxed to a SHOULD and that the inclusion of the
Etag
header be documented as an altern

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

Sorry, I see now that Thunderbird has completely mangled the stanza that 
it showed so nicely to me in the email editor.


I guess because I have it configured to send out only plaintext.

Here it is again:


    Look at this funny cat picture
    type='data'>

        
            
                image/jpeg
                icanhazcheeseburger.jpg
                110220
                
                    some-long-opaque-string
                
                Fat cat that looks like it wants a 
cheeseburger

            
            
                uri='https://funnypics.com/icanhazcheeseburger.jpg'/>

            
        
    


On 02.07.21 12:15, JC Brand wrote:

Hi everyone


I've been reading XEP-0385 SIMS with an eye towards potentially 
implementing it, when I noticed that a XEP-0300 hash is required, in 
order to allow integrity checking and caching.


In the introduction of SIMS, the following is written:
"This proposal aims to provide a protocol that will enable XMPP 
clients to implement a great user experience (UX) around the process 
of sharing media in conversations."


I think making inclusion of the file hash mandatory is at odds with 
that goal, the reason being that a lot of the media being shared in 
chats is shared as URLs to 3rd parties where the media is hosted.
In other words, the sharer of the media doesn't necessarily know the 
hash of the media because it was never on their own machine to begin 
with.


Here's the use-case I have in mind:

Romeo sees a funny picture on funnypics.com. He right-clicks on the 
picture, copies the URL and sends it to Juliet. Before the message is 
sent, Romeo's client does an HTTP HEAD request, to get information on 
the URL, and learns that its an image.


Here's the response:

HTTP/2 200
last-modified: Fri, 02 Jul 2021 02:46:55 GMT
etag: "a1d5ea7e796f5da6980bed86a8396664"
content-type: image/jpeg
cache-control: public, max-age=31536000
accept-ranges: bytes
date: Fri, 02 Jul 2021 06:44:39 GMT
access-control-allow-methods: GET, OPTIONS
access-control-allow-origin: *
content-length: 110220

The "content-type" header can be used for the SIMS  tag 
and the "content-length" header for the .


The server also responds with an "etag" header, which can be used for 
caching, but unfortunately not for integrity checking, since the 
method by which it's generated is not specified.
If the etag is passed along via SIMS (instead of the hash), the 
receiving client could also check whether it matches what's returned 
by the webserver, although I'm not sure what conclusions can be drawn 
if they don't match.


Before someone says that this scenario is not relevant to what SIMS is 
trying to do, please note that this problem also occurs when someone 
shares a file via HTTP upload and then the receiving party copies and 
pastes that URL in a message to someone else. Perhaps an intelligent 
enough client might go and get the hash from the original SIMS data 
and then add that to the newly sent message, but that seems a bit 
contrived to me and might not always be feasible.


So... back to the scenario. After Romeo's client has received the HEAD 
headers, it can then construct a SIMS element with it.



Look 
at this funny cat 
pictureimage/jpegicanhazcheeseburger.jpg110220http://jabber.org/protocol/shim'>some-long-opaque-stringFat 
cat that looks like it wants a 
cheeseburgerhttps://funnypics.com/icanhazcheeseburger.jpg'/>



Note the inclusion of the ETag header (as defined in "XEP-0150: Use of 
Entity Tags in XMPP Extensions") and the omission of a XEP-0300 hash 
element.


If, for some reason the content-type and content-length headers can't 
be used for the  and  tags, then they can also be 
included as XEP-0131 headers (like the Etag).


So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash 
requirement gets relaxed to a SHOULD and that the inclusion of the 
Etag header be documented as an alternative in case a hash is not 
feasible. There might also be cases where neither a hash or an Etag 
header is available.


I'd be happy to make the necessary changes and submit a pull request.

Regards
JC








___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing



Am 2. Juli 2021 13:41:26 MESZ schrieb Tobias Markmann 
:
>On Fri, Jul 2, 2021 at 1:22 PM Florian Schmaus 
>wrote:
>
>> On 02.07.21 12:15, JC Brand wrote:
>> > So, my proposal is that XEP-0385 be updated so that the XEP-0300
>hash
>> > requirement gets relaxed to a SHOULD
>>
>> +1. I would even make the hash OPTIONAL as SHOULD is already pretty
>strong.
>>
>>
>I'd be fine with making that OPTIONAL.
>
>If HTTP server would support the HTTP Digest header you wouldn't need
>to
>download the complete file as
>the HTTP server would provide you with the hash upfront. But obviously
>it's
>rarely provided by servers.
>
>https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest


Thanks, I'll prepare a pull request.



-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

2021-07-03 Thread JC Brand


Hi Marvin

On 03.07.21 17:01, Marvin W wrote:

Hi,

Remember that URLs are not guaranteed to be globally reachable
(examples: restricted to company network or requiring authentication).
For most users it's not easily understandable if a URL can be reached by
the recipient client or not. Thus sending an URL of funnypics.com
instead of downloading that file and uploading it can lead to unexpected
behavior.


If you're behind a corporate firewall, then you're probably already 
aware that certain sites are blocked, so the behavior isn't necessarily 
that unexpected.


I'm happy to leave the decision to the user whether they want to share a 
URL or a file. Not all servers support HTTP file upload and not all 
clients support Jingle, so sharing via 3rd party URL is the only option 
some people have.


Given that users already share URLs, I would like to have better 
metadata so that I can provide a better UX.



Fetching files from untrusted third-party servers is a privacy
nightmare. We already have this issue with oob file sharing and I
remember a proposal to restrict automatic fetching to known-good servers
or if the domain of the URL matches the domainpart of the JID (or is a
subdomain thereof). This wouldn't work when we want to accept sending
URLs from funnypics.com.

Sounds like configuration, and not something that would ever be universal.


When doing inline sharing, the sending client would want to display the
media inline as well. For this it also needs to fetch the media anyway
and thus calculating the hash would be easy.


I don't see this as simply "inline sharing" and I don't share the 
assumption that you'll always show the image to yourself when you're 
sharing the URL.


Also, at least in my web client, the images are shown asynchronously 
after the message has been sent, and they're shown via  tags, so 
the browser is responsible for fetching the image and caching it, not my 
client.




Also, especially when sharing image files, it would be great to have a
thumbnail so that you don't have to fetch the full (maybe high quality)
image when not explicitly needed, i.e. on mobile. To generate a
thumbnail, the sending client has to first download the image.

Nice to have, but not essential.


Providing the hash of the file is a good way to allow caching. Thus if
you receive the same meme several times, but from different URLs, the
hash will allow you to only download it once. This is not possible via
ETag, due to ETags not following a common generation scheme.
Indeed, I'm however dealing with the case where it's not deemed 
desirable to first download the entire file in order to generate a hash.

When receiving a file via SIMS, the URL to the file is typically not
going to be exposed to the end user (instead the inline media or
thumbnail and maybe filename are displayed). Thus when forwarding the
file to another contact, users will typically want to do this directly
instead of through copying the URL. In that case, all the details from
SIMS can be just forwarded as is. I'd also like to mention that it
probably is a rare case (although it may happen from time to time) where
you forward a file without downloading it first.
I read a lot of assumptions in this last paragraph that don't match up 
to the use-case that I have and seem to come from the perspective of a 
desktop or perhaps mobile client developer.


When sharing video URLs on the web, the browser is not going to download 
the entire video before starting to show it to you in a  tag.



I don't know any instant messaging client that would have the equivalent
of sharing a URL using SIMS. Some clients do allow sending a URL as a
message and then have the server attach some SIMS-like metadata to that
message.


Yes, and that's another use-case where it might be preferable to simply 
do a HEAD request and use the headers rather than downloading the whole 
file.



  There's also client side generated link previews, but these are
typically not the same as I'd expect SIMS to be used, because links
don't necessarily qualify as media (although I agree media is a very
broad term and thus probably most things that URLs point to are actually
somewhat media).

When they link directly to media they do qualify as media in my opinion.


Currently, when I share an image from my browser on Android, I can just
use the browsers "share image" feature (long press on the image) and
select Conversations. The browser will transfer the image to
Conversations without the need to download it again (might also actually
do another download, but that's another story) and Conversations uploads
it using HTTP file upload as usual.
This works great for me and I wonder what would be wrong with this approach?


Nothing, but I'm working on a web client, not a mobile client.

- JC


On 02.07.21 12:15, JC Brand wrote:

Hi everyone


I've be

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

2021-07-03 Thread JC Brand




On 03.07.21 17:44, Linus Jahn wrote:

Hello,

I just wanted to note that there's also XEP-0447: Stateless file sharing [1] 
which has some
improvements over SIMS (like multiple files in one message and a little simpler 
API (no need to
use character counting / the References XEP) and later attaching of additional 
sources).

Not sure if I've missed something, but I thought there're no reasons to use 
SIMS anymore, right?

Anyway, I guess making checksums OPTIONAL/RECOMMENDED is probably also a good 
idea for SFS.

Thanks, I wasn't aware of this XEP.

I had a look and it's not fit for what I have in mind.

Not using references is a drawback for me, since Converse already 
supports and uses references.


Not supporting mixed content is a deal breaker, since I'm interested in 
the case where users write messages containing URLs pointing to media, 
not just sharing files.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0372 references pointing to different elements in same stanza

2021-08-13 Thread JC Brand


Hi everyone

In XEP-0372, when references are used for "mentions", there is an 
implicit assumption that the referenced text is in the  tag.


There are however other elements where mentions could also occur, such 
as ,  and , and some stanzas could have multiple 
possible elements whose text might be referenced.


XEP-0372 provides an "anchor" attribute for the  tag, which 
can be used to refer to other addressable entities, to handle the case 
where the reference points to something in another stanza.


I think this "anchor" attribute can also be used to disambiguate the 
references in a stanza that has multiple text-containing elements. In 
this case, instead of letting the anchor point to an XMPP URI, it would 
only point to a fragment, meaning that the fragment is inside the same 
stanza.


In HTML the fragment of a URI points to an element with the same id 
attribute value as the fragment itself, but apparently this isn't a 
general requirement for URIs. In this case, for simplicity, I would 
however stick to that convention.


So, if you have a stanza with for example, both "subject" and "body" 
tags, we can have references for both, and use the "anchor" attribute as 
follows (I hope this comes out formatted properly once sent):



    Attention Bart Simpson
    Please hand in your homework before the end of the 
day

    


I think this is an elegant solution that uses the existing mechanics, 
and the only further requirement would be to clarify in the XEP that the 
anchor attribute can be used in this way.


I'd be happy to hear your thoughts and feedback.

Regards
JC
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

2021-08-25 Thread JC Brand


Hi all

I didn't get any response, so I've gone ahead and made an MR with the 
proposed changes in the previous email.


https://github.com/xsf/xeps/pull/1102


Regards
JC

On 13.08.21 14:00, JC Brand wrote:

Hi everyone

In XEP-0372, when references are used for "mentions", there is an 
implicit assumption that the referenced text is in the  tag.


There are however other elements where mentions could also occur, such 
as ,  and , and some stanzas could have 
multiple possible elements whose text might be referenced.


XEP-0372 provides an "anchor" attribute for the  tag, which 
can be used to refer to other addressable entities, to handle the case 
where the reference points to something in another stanza.


I think this "anchor" attribute can also be used to disambiguate the 
references in a stanza that has multiple text-containing elements. In 
this case, instead of letting the anchor point to an XMPP URI, it 
would only point to a fragment, meaning that the fragment is inside 
the same stanza.


In HTML the fragment of a URI points to an element with the same id 
attribute value as the fragment itself, but apparently this isn't a 
general requirement for URIs. In this case, for simplicity, I would 
however stick to that convention.


So, if you have a stanza with for example, both "subject" and "body" 
tags, we can have references for both, and use the "anchor" attribute 
as follows (I hope this comes out formatted properly once sent):



    Attention Bart Simpson
    Please hand in your homework before the end of the 
day

    


I think this is an elegant solution that uses the existing mechanics, 
and the only further requirement would be to clarify in the XEP that 
the anchor attribute can be used in this way.


I'd be happy to hear your thoughts and feedback.

Regards
JC


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies

Hi Sam et al

Webclients have restrictions that others don't, so while what you wrote
makes sense, I do something a bit different with Converse.

First, depending on the type of storage used (sessionStorage vs
localStorage vs IndexedDB), a webclient can easily run into a storage
limit (around 5MB for localStorage).
IndexedDB doesn't have a storage limit, but you can't always assume that
it's available (e.g. it's not in incognito mode in Safari) or desirable
to use it.

Additionally, the user can at any time navigate away from the tab or
reload the tab, thereby interrupting the process of populating the archive.

In theory this second problem can be solved by using a shared worker,
which can still populate the history in the background (I've added
support to Strophe.js), but Safari doesn't support shared workers and
they bring other complications and considerations.

So, instead of fetching the history for every contact in the roster, I
only do so for open chats (i.e. ongoing 1:1 and MUC conversations).

If there are no messages in the history, I do a reverse order query
using "before" set to an empty string together with a configurable limit
(similarly to how you do it).

If there are messages in the history, I set "after" to the stanza-id of
the most recent message. Now of course there might be more messages than
might fit on the returned MAM page. Whether Converse will fetch the
other pages is configurable, and depends on whether it has limited
storage or not. In the case where storage is limited, Converse should be
configured to not fetch all subsequent pages. This creates a gap in the
history. In the soon-to-be-released Converse 8, I create a special gap
indicator, which is shown to the user in the chat history, to indicate
that there are missing messages. The user can click on this indicator,
to fill it with a new MAM query.

The potential presence of gaps and how to deal with them is something
that I don't see mentioned in Sam's description. Probably because with a
desktop client you can just fetch all messages and don't have to worry
about gaps.

Then there's also an edge case, where there is a message history, but
for some reason we don't have a stable stanza-id. In that case, I get
the time of the most recent message (taking into account a possible
element), and then I do a "before" query set to that date.

For those who might be interested, here's the code that implements the
logic described above:

https://github.com/conversejs/converse.js/blob/8d62c2b103f70e0a1e82787b5c464e8b2d53cc01/src/headless/plugins/mam/utils.js#L201

Regards
JC

On 09.08.21 13:46, Sam Whited wrote:

Hi all,

I started a PR against modernxmpp to document MAM sync strategies after
a discussion on jdev yesterday:

https://github.com/modernxmpp/modernxmpp/pull/41

I wondered if anyone would share what their sync strategy is (or even
possibly add it to that PR) so that we can document a few clients and
maybe move towards an XEP that outlines one or two ideal ones?

I'll start with the one I described in the chat yesterday that's used
(experimentally) by Mellium/Communiqué:

On client start iterate through all items in the roster. If no messages
exist in the local archive: Query in reverse order (in case the server
breaks it up by page and we end up committing pages separately) with
before: now && limit: X (where X is some configurable number, what we
think will fit on the page with some margin, etc.). Otherwise query with
after-id: (making sure that the last message was pulled
from the DB before we send initial presence).

If the user scrolls to the top of the history, query in reverse order
with before-id: . Fetch the next page for as long as they
continue to scroll up.

Thanks,
Sam

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies




On 27.08.21 11:45, Andrew Nenakhov wrote:


пт, 27 авг. 2021 г. в 12:59, JC Brand <mailto:li...@opkode.com>>:



Webclients have restrictions that others don't, so while what you
wrote makes sense, I do something a bit different with Converse.



Web clients do not need to store messages locally at all, they can 
just load everything when a user goes to a dialog that he didn't load 
before. The only exception to this we've found is OMEMO messages. For 
them and their keys we use lndexedDB.


Converse is made so that it can be integrated into a website where the 
user might be clicking many links and navigate throughout the site, 
thereby causing the page to regularly refresh/reload. If you don't 
cache/store the messages somewhere, you'll have to refetch them every 
single time the page loads, which is wasteful and causes notable delays.


So no, you can't always just load everything from the server.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies




On 27.08.21 12:20, Andrew Nenakhov wrote:
пт, 27 авг. 2021 г. в 14:52, JC Brand <mailto:li...@opkode.com>>:


Converse is made so that it can be integrated into a website where
the user might be clicking many links and navigate throughout the
site, thereby causing the page to regularly refresh/reload. If you
don't cache/store the messages somewhere, you'll have to refetch
them every single time the page loads, which is wasteful and
causes notable delays.

So no, you can't always just load everything from the server.


Well, if you intend to work as a widget, you'll hardly exceed 5MB 
local storage limit.


I know from professional experience that you can reach the 5MB limit 
with an integrated webchat of the type I mentioned.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies




On 27.08.21 12:56, Andrew Nenakhov wrote:


пт, 27 авг. 2021 г. в 15:53, JC Brand <mailto:li...@opkode.com>>:



I know from professional experience that you can reach the 5MB
limit with an integrated webchat of the type I mentioned.


then just discard chat history (bar the last message) you haven't 
touched in a while. Loading history from the archive again is fast 
enough anyway, with any decent xmpp server.


If the site allows users to show multiple chats side-by-side then you 
can't discard chat history.


Also if users quickly switch between multiple chats in a single widget, 
they complain if there is a noticeable delay before showing the history 
(which happens if messages need to be fetched again from the server).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies




On 27.08.21 13:12, Andrew Nenakhov wrote:



пт, 27 авг. 2021 г. в 16:03, JC Brand <mailto:li...@opkode.com>>:



If the site allows users to show multiple chats side-by-side then
you can't discard chat history.


Ok, so you have users that use so many simultaneous chats and scroll 
them up and down that fast, so you can't ever dump the messages 
starting from, say, 20th? Those are mightily rabid users, I must say!


For reasons not worth going into, we disabled infinite scrolling to 
fetch older messages, so it's not so simple to just restrict the history 
and then let users scroll up to fetch older messages.


Obviously this doesn't apply to most other use-cases, but my point is 
that it's dangerous to make assumptions that it's "easy" to just do X 
and that you never need to cache messages in a webclient.


I'm sure you can get quite far by never caching messages locally, but 
you are then also restricting yourself to certain use-cases. If you 
decide to cache messages locally, then you have other tradeoffs to 
contend with. Converse has always cached messages locally and it's 
worked well over the years.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM Sync Strategies


On 27.08.21 13:12, Sam Whited wrote:

Thanks JC!

You're right, I should have mentioned gaps. It's still possible to
have them in a desktop client because it could always close before it
finishes paging through catching up on history. I had planned to solve
that by either switching to committing the entire query in one
transaction, or changing from using the last message for the sync
query to using a separate "last message pointer" that gets updated
only after the entire transaction is over. If for any reason there is
a gap, this would effectively be the "there's a gap here" pointer
because you'd see that there existed messages after the last message
pointer. You could then fill it, or add a marker as you've done. I
haven't decided what's best yet, so I don't have this implemented
right now, but it's on my list.


FWIW I've seen markers in Slack, on Twitter and on Mastodon. So they're 
a relatively established UX paradigm.





___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0372 references pointing to different elements in same stanza


Hi Jonas

On 31.08.21 17:23, Jonas Schäfer wrote:

Hi JC,

This has somehow slipped past me.


Thanks for taking the time to respond.


On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:

So, if you have a stanza with for example, both "subject" and "body"
tags, we can have references for both, and use the "anchor" attribute as
follows (I hope this comes out formatted properly once sent):


  Attention Bart Simpson
  Please hand in your homework before the end of the
day
  


What about messages with multiple  elements disambiguated by xml:lang?
Could some conceivably contain a mention while others don't? Does this require
replicating the mention element all over? Same question for .
This is another currently ambiguous and undefined use-case that I think 
can be solved with my proposal.
As the XEP currently stands, there's no documented way to distinguish 
between multiple  (or ) elements.


Going with my proposal, the solution would be to have a separate 
 element for each .
The mention parameters ("begin", "end") will be different for each 
 since the mentioned text usually won't be in the exact same 
place for the different translations.


The "id" attribute can have any value, it doesn't have to be "body" or 
"subject", those were just examples.



Besides that, I don't think that adding an attribute to an element in this way
is really acceptable.

I would prefer an approach which identifies the XML element without having to
modify the XML being referenced.
The only mechanism that doesn't require modifying the referenced 
elements that I can think of is XPath.


My example then becomes:


 Attention Bart Simpson
 Aandag Bart Simpson
 Please hand in your homework before the end of the 
day
 Handig asseblief jou huiswerk in voor die einde van die 
dag
 
 
 

Regards
JC



Libraries which currently represent body as a
(mappnig of language tags to) string(s) would now need extra magic in order to
be able to set ID attributes on those. This feels like a quite major change,
and not just to References, but to literally everything else.

kind regards,
Jonas

[1]: https://www.w3.org/TR/REC-xml/#id


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0372 references pointing to different elements in same stanza




On 01.09.21 10:06, Sergey Ilinykh wrote:

why not just

```

```
?


Because that doesn't distinguish between elements with different names.
Is that reference based on the  or  tag? Or perhaps a 
 tag?


- JC

ср, 1 сент. 2021 г. в 10:59, JC Brand <mailto:li...@opkode.com>>:


Hi Jonas

On 31.08.21 17:23, Jonas Schäfer wrote:

Hi JC,

This has somehow slipped past me.


Thanks for taking the time to respond.


On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:

So, if you have a stanza with for example, both "subject" and "body"
tags, we can have references for both, and use the "anchor" attribute as
follows (I hope this comes out formatted properly once sent):

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Please hand in your homework before the end of the
day
  


What about messages with multiple  elements disambiguated by 
xml:lang?
Could some conceivably contain a mention while others don't? Does this 
require
replicating the mention element all over? Same question for .

This is another currently ambiguous and undefined use-case that I
think can be solved with my proposal.
As the XEP currently stands, there's no documented way to
distinguish between multiple  (or ) elements.

Going with my proposal, the solution would be to have a separate
 element for each .
The mention parameters ("begin", "end") will be different for each
 since the mentioned text usually won't be in the exact
same place for the different translations.

The "id" attribute can have any value, it doesn't have to be
"body" or "subject", those were just examples.


Besides that, I don't think that adding an attribute to an element in this 
way
is really acceptable.

I would prefer an approach which identifies the XML element without having 
to
modify the XML being referenced.

The only mechanism that doesn't require modifying the referenced
elements that I can think of is XPath.

My example then becomes:

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Aandag Bart Simpson
  Please hand in your homework before the end of the 
day
  Handig asseblief jou huiswerk in voor die einde van die 
dag
  
  
  

Regards
JC



Libraries which currently represent body as a
(mappnig of language tags to) string(s) would now need extra magic in order 
to
be able to set ID attributes on those. This feels like a quite major change,
and not just to References, but to literally everything else.

kind regards,
Jonas

[1]:https://www.w3.org/TR/REC-xml/#id  
<https://www.w3.org/TR/REC-xml/#id>


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
<https://mail.jabber.org/mailman/listinfo/standards>
Unsubscribe: standards-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0372 references pointing to different elements in same stanza




On 01.09.21 10:23, Sergey Ilinykh wrote:
I mean to use both *anchor* and *xml:lang* attributes to not write a 
complicated element query parser if one is not provided by the used libs.


What would you then put in the "anchor" attribute?

If you say just the name of the referenced element (e.g. "body" or 
"subject"), well then there is still a problem with for example XEP-0316 
MUC PEP messages where you can have multiple  elements that you'd 
like to have mentions for. In such a case, the element name and 
"xml:lang" attribute aren't sufficient to know which  element is 
being referred to.


If you say an id selector (e.g. #abc123), then we're back to my original 
proposal, which works for all the use-cases brought up so far, but which 
requires an "id" attribute on the referenced element.


- JC

ср, 1 сент. 2021 г. в 11:10, JC Brand <mailto:li...@opkode.com>>:




On 01.09.21 10:06, Sergey Ilinykh wrote:

why not just

```

```
?


Because that doesn't distinguish between elements with different
names.
Is that reference based on the  or  tag? Or
perhaps a  tag?

- JC


ср, 1 сент. 2021 г. в 10:59, JC Brand mailto:li...@opkode.com>>:

Hi Jonas

On 31.08.21 17:23, Jonas Schäfer wrote:

Hi JC,

This has somehow slipped past me.


Thanks for taking the time to respond.


On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:

So, if you have a stanza with for example, both "subject" and "body"
tags, we can have references for both, and use the "anchor" attribute as
follows (I hope this comes out formatted properly once sent):

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Please hand in your homework before the end of the
day
  


What about messages with multiple  elements disambiguated by 
xml:lang?
Could some conceivably contain a mention while others don't? Does this 
require
replicating the mention element all over? Same question for .

This is another currently ambiguous and undefined use-case
that I think can be solved with my proposal.
As the XEP currently stands, there's no documented way to
distinguish between multiple  (or ) elements.

Going with my proposal, the solution would be to have a
separate  element for each .
The mention parameters ("begin", "end") will be different for
each  since the mentioned text usually won't be in the
exact same place for the different translations.

The "id" attribute can have any value, it doesn't have to be
"body" or "subject", those were just examples.


Besides that, I don't think that adding an attribute to an element in 
this way
is really acceptable.

I would prefer an approach which identifies the XML element without 
having to
modify the XML being referenced.

The only mechanism that doesn't require modifying the
referenced elements that I can think of is XPath.

My example then becomes:

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Aandag Bart Simpson
  Please hand in your homework before the end of the 
day
  Handig asseblief jou huiswerk in voor die einde van 
die dag
  
  
  

Regards
JC



Libraries which currently represent body as a
(mappnig of language tags to) string(s) would now need extra magic in 
order to
be able to set ID attributes on those. This feels like a quite major 
change,
and not just to References, but to literally everything else.

kind regards,
Jonas

[1]:https://www.w3.org/TR/REC-xml/#id  
<https://www.w3.org/TR/REC-xml/#id>


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
<https://mail.jabber.org/mailman/listinfo/standards>
Unsubscribe: standards-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
___


___
Standards mailing list
Info:https://mail.jabber.org/mailman/listinfo/standards  
<https://mail.jabber.org/mailman/listinfo/standards>
Unsubscribe:standards-unsubscr...@xmpp.org  
<mailto:standards-unsubscr...@xmpp.org>
___


__

Re: [Standards] XEP-0372 references pointing to different elements in same stanza