[Standards] Council Minutes 2020-04-15

[Tedd Sterr]

https://logs.xmpp.org/council/2020-04-15?p=h#2020-04-15-515165c7293c9539

1) Roll Call
Present: Daniel, Jonas, Zash, Georg
Apologies: Dave

2) Agenda Bashing
No additions.

3) Editor's Report
* Expired calls: None
* Calls in progress:
  - LC for XEP-0357 (Push notifications) ends at 2020-04-15
* New ProtoXEP: Room Activity Indicators

4a) Proposed XMPP Extension: Room Activity Indicators - 
https://xmpp.org/extensions/inbox/room-activity-indicators.html
Daniel: [on-list]
Jonas: [on-list]
Georg: [on-list]
Zash: [on-list]
Dave: [pending]

4b) PR #924 - XEP-0191: Change service discovery flow to use account instead of 
server - https://github.com/xsf/xeps/pull/924
Jonas expects some controversy on this, as do Zash and Georg.
Kev notes that it's usual to send disco queries to the server's JID to find out 
what's supported for your current session - Jonas would like to gradually 
change that. Kev doesn't think the status quo prohibits the right results from 
being returned to the right entities, and so the motivation given doesn't 
necessarily lead to this patch (though other motivations may.) Zash likes the 
general pattern of disco#info going to the same JID as for the rest of the 
protocol. As a puritan, Jonas believes that disco#info for an entity should 
look the same, no matter who is asking (subject to conditions.)
Daniel is not entirely on board with changing draft XEPs, but agrees this PR is 
'more correct.'
Given that many other XEPs advertise on the server JID, Kev doesn't think 
changing one XEP in isolation is the right thing to do here, without wider 
thought.
Jonas thinks this should be taken to the list for feedback from the wider 
community, and thus cancels this vote.

4c) Advance XEP-0357 (Push Notifications) - 
https://xmpp.org/extensions/xep-0357.html
Daniel: -1 (unaddressed feedback)
Jonas: -1 (arguments against this using PubSub syntax, making it unnecessarily 
hard to understand, are sound)
Georg: [pending]
Zash: [pending]
Dave: [pending]

Jonas asks whether anyone is taking ownership of this XEP, specifically Kev or 
Lance (as authors) - Lance wanted another author listed so he could retire from 
this, and Kev volunteered expecting to spend time working on it, but hasn't 
touched it since.
Daniel thinks it wouldn't be a bad idea to just start from scratch, not that 
he's volunteering, but it would make the ownership question unnecessary.
Jonas thinks it would be good to get someone already involved with 
implementations around this to do the work, primarily mobile client/server 
developers. Zash shirks any responsibility, having not touched this for years. 
Kev is very short of cycles at the moment. Jonas thinks input from Xabber would 
also be good.
Daniel mentions that Tigase introduced something at the Summit, so they might 
be encouraged to write that down in XEP form - Jonas asks Daniel to contact 
them to see if they will, or call for volunteers on the list if they won't - 
Daniel accepts.

5) Pending Votes
All votes are up to date.

Dave made valid points about PR #913, and Jonas is going to fix that up and 
re-propose it.

6) Date of Next
2020-04-22 1500 UTC

7) AOB
Daniel remembers what he wanted to do last week: ask Editor to Last Call 
XEP-0320 (Use of DTLS-SRTP in Jingle Sessions) and XEP-0339 (Source-Specific 
Media Attributes in Jingle) - thinks they will be uncontroversial, as it's just 
metadata annotations.
Jonas adds them to the agenda for next week.

8) Close
Thanks everyone.
Thanks all.
Thanks.

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

Re: [Standards] Proposed XMPP Extension: Quick Response

[Andrew Nenakhov]

ср, 22 апр. 2020 г. в 12:58, Kevin Smith :
> I have very mixed feelings on the protoXEP. It seems like a non-extensible 
> solution to
> a fraction of a larger problem, which is not great. Equally, sometimes just 
> solving the
> problem at hand is better than not solving a bigger/more general problem.

Such approach has led XMPP to where it is today, an obscure protocol
with no overall clarity and with insanely steep learning curve for any
new developer, who has to somehow make sense of this patchwork of all
fractional solutions to various small problems. Compare the list of
XEPs to matrix documentation, which would you chose as a 20 years old
developers who wants to make a chat application?


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

Re: [Standards] XEP-0313: pending 0.7 update review

[Florian Schmaus]

On 4/22/20 12:07 PM, Matthew Wild wrote:
> On Tue, 21 Apr 2020 at 15:50, Florian Schmaus  > wrote:
> On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at 16:20,
> > You're going to hate me, but one more thing...
> >
> > Current MAM says that servers SHOULD include a count. The problem with
> > this is that it's extremely slow on any system with more than trivial
> > retention periods, since this tends to degenerate into either a
> COUNT(*)
> > SQL query (table-scan-tastic) or a standalone counter (which then
> drifts
> > and is a contention point).
> >
> > The majority of client libraries appear to ignore the count values
> > anyway, as far as I can tell, so can we relax this to a MAY? (XEP-0059
> > is MAY-but-only-if, which is arguably really a SHOULD anyway).
> 
> I think such a relaxation would require a namespace bump.
> 
> I'm not convinced. In any case, servers that already comply with the
> SHOULD will probably continue to do so, new servers may be more likely
> not to, but given that clients don't really use the (unreliable) info
> today then I don't think we lose anything in practice.

I could follow that argumentation in this case. It's probably just me,
but I am very conservative when it comes to relaxations of keywords.

- Florian



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

Re: [Standards] XEP-0313: pending 0.7 update review

[Matthew Wild]

On Tue, 21 Apr 2020 at 15:50, Florian Schmaus  wrote:

> On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at 16:20,
> Matthew Wild  > > wrote:
> >
> > On Fri, 3 Apr 2020 at 21:51, Matthew Wild  > > wrote:
> >
> > Hi folks,
> >
> > XEP-0313 is a well-established protocol at this point, but
> > didn't yet make it to the next stage in the standards process.
> > Time to fix that!
> >
> > I have made a final round of updates to incorporate the various
> > feedback I have received from people who have implemented the
> > protocol over the past couple of years.
> >
> >
> > I have just updated the PR in response to feedback here and in the
> MUC.
> >
> > Changes:
> >
> >   - Removed the separate iq for fetching a single message by id,
> > this is now done via the 'ids' field in the data form and supports
> > multiple ids
> >
> >   - Reverted the additional  error (the RFC defines this to
> > mean something else, and the information signaled to the client was
> > of questionable value)
> >
> >   - Added an iq to query information about the id and timestamps at
> > the start/end of the archive, which can provide clients with useful
> > information.
> >
> >   - Clarified the intention of the rule surrounding use of the
> > user's bare JID in the 'with' query field.
> >
> > Thanks to everyone for the feedback and suggestions!
> >
> >
> > You're going to hate me, but one more thing...
> >
> > Current MAM says that servers SHOULD include a count. The problem with
> > this is that it's extremely slow on any system with more than trivial
> > retention periods, since this tends to degenerate into either a COUNT(*)
> > SQL query (table-scan-tastic) or a standalone counter (which then drifts
> > and is a contention point).
> >
> > The majority of client libraries appear to ignore the count values
> > anyway, as far as I can tell, so can we relax this to a MAY? (XEP-0059
> > is MAY-but-only-if, which is arguably really a SHOULD anyway).
>
> I think such a relaxation would require a namespace bump.
>

I'm not convinced. In any case, servers that already comply with the SHOULD
will probably continue to do so, new servers may be more likely not to, but
given that clients don't really use the (unreliable) info today then I
don't think we lose anything in practice.

Alternatively, we could add a flag in the query request to omit the
> .
>

I think that's not going to help - clients will not actively add it even if
they aren't interested. They ought to opt-in, if anything.


> Also given that  is specified to potentially be approximate,
> implementations could just return 0 or 1 as count.
>

Indeed. It is already vague enough that I'm not even sure if we need to
relax it. But also relaxing it isn't a problem if that's what we think best
reflects reality.

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

Re: [Standards] Proposed XMPP Extension: Quick Response

[Kevin Smith]

On 22 Apr 2020, at 08:10, Daniel Gultsch  wrote:
> 
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> 
>> Title: Quick Response
>> Abstract:
>> Quickly respond to automated messages.
>> 
>> URL: https://xmpp.org/extensions/inbox/quick-response.html
>> 
>> The Council will decide in the next two weeks whether to accept this
>> proposal as an official XEP.
> 
> To make it quick I’ll vote yes in our Council meeting this afternoon.
> I think it's good enough and interesting enough for an experimental
> XEP.

I have very mixed feelings on the protoXEP. It seems like a non-extensible 
solution to a fraction of a larger problem, which is not great. Equally, 
sometimes just solving the problem at hand is better than not solving a 
bigger/more general problem.

The appeal of the feature is obvious.

> Personally I’m finding myself broadly agreeing with what Matthew wrote.
> * UX of data forms is horrible for 'simple' things like this
> * We should consider joining response and action; (That will probably
> mean getting rid of response)
> * We should consider sending the action-accepts as IQs. Having just
> implemented Jingle Message Initiation the uncertainty that comes with
> messages (I’m finding myself trying to track them via receipts) is not
> ideal for 'triggering actions' - Certainly I would like to know
> whether my merge action has actually been merged.
> 
> Getting rid of response and making action responses (just the
> responses) IQ, will probably also give a hint at the direction people
> want to take the UI in. (Meaning no; you won't see your response as a
> message; but instead button turns into spinning wheel while IQ is in
> flight; and gets a checkmark or becomes gray one success)

I think it needs to be messages because you expect this to be part of the 
normal chat flow, and therefore to end up in your archive.

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

Re: [Standards] Proposed XMPP Extension: Quick Response

[Daniel Gultsch]

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Quick Response
> Abstract:
> Quickly respond to automated messages.
>
> URL: https://xmpp.org/extensions/inbox/quick-response.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.

To make it quick I’ll vote yes in our Council meeting this afternoon.
I think it's good enough and interesting enough for an experimental
XEP.


Personally I’m finding myself broadly agreeing with what Matthew wrote.
* UX of data forms is horrible for 'simple' things like this
* We should consider joining response and action; (That will probably
mean getting rid of response)
* We should consider sending the action-accepts as IQs. Having just
implemented Jingle Message Initiation the uncertainty that comes with
messages (I’m finding myself trying to track them via receipts) is not
ideal for 'triggering actions' - Certainly I would like to know
whether my merge action has actually been merged.

Getting rid of response and making action responses (just the
responses) IQ, will probably also give a hint at the direction people
want to take the UI in. (Meaning no; you won't see your response as a
message; but instead button turns into spinning wheel while IQ is in
flight; and gets a checkmark or becomes gray one success)

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

Re: [Standards] On Quick Responses

[Matthew Wild]

On Tue, 21 Apr 2020 at 23:06, Dave Cridland  wrote:

>
>
> On Tue, 21 Apr 2020 at 21:24, Matthew Wild  wrote:
>
>> ### Why not use data forms?
>>
>
> What happens when people want to show, for example, a polling bot, or a
> ... well, anything beyond some text followed by some buttons?
>

Not sure why a polling bot wouldn't be possible with this?


> If the answer is "XEP-0004 Forms have ended up being used primarily
> non-interactively, especially in user-facing cases, and are unsuited to
> modern UX" that's absolutely fine as an opinion, but it's not an answer.
> I'd like to know where you see the future going.
>

For the future I don't see this protocol "going" anywhere. It's a very
simple protocol with a very simple ambition. And it might actually see
implementations.

Forms certainly open more possibilities, at the cost of additional
complexity in construction, parsing and the UI work required to display
them sensibly. Unless we modernize/replace XEP-0004 with the capabilities
of modern UIs, it's going to be doomed to be a UX monstrosity. I honestly
think we'd do as well to define some way of embedding (X?!)HTML widgets in
messages (XEP-0088 anyone?).

FWIW XEP-0004 itself already details the possibility to send someone a form
in a message and they will simply render it (it even includes a disco
feature for this ability). Yet it's almost our oldest protocol XEP, and no
bot or client implements it. (This is where someone tells me Psi or Gajim
support it, and pop up a form dialog - which only proves my point).

Note that I don't see a reason to block this from Experimental, but I do
> wonder if we could consider options that have a little more extensibility
> available.
>

Ok, well I linked to what other platforms are doing. The truth is, they are
doing stuff far in advance of this current proposal. Facebook support
buttons that don't just generate a response, but also that directly open a
URL, or carry out other Facebook-specific actions.

And the Slack documentation I linked to? It's actually deprecated. While
they started with buttons, they reworked their entire "interactive
messaging" API so that you can essentially compose any kind of message,
including interactive ones, out of various "blocks". You can get a feel for
it with their design tool here: (probably requires a Slack account)
https://api.slack.com/tools/block-kit-builder

Moving an ecosystem is hard. We aren't going to get anywhere near Slack or
Facebook overnight, but it's not even clear that we need to. We have
extensibility already baked into our core. There is merit to working with
simple additions such as this one that are relatively easy for client
developers to implement, with obvious UI choices.

Other platforms have the advantage that they control the protocol, and also
control the rendering code which they write once, maybe twice, to reach all
platforms.


> ### Responses on earlier messages
>>
>> For interactive bots (especially 1:1) such as memberbot, only showing
>> quick responses for just the latest message makes sense (and is how
>> Telegram "custom keyboards" work). For notification bots, you may still
>> want to display buttons under each notification. E.g. in the winning
>> example of a Mercurial notification bot, it would be surprising if two
>> notifications arrived together and only the latter had a button to merge.
>>
>>
> It'd also be surprising if you clicked Merge, and as you did so another
> pull request message arrived...
>

Why?

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