Re: [Standards] Proposed XMPP Extension: Message Reactions

[Philipp Hörist]

Am Mi., 31. Juli 2019 um 18:20 Uhr schrieb Ненахов Андрей <
andrew.nenak...@redsolution.ru>:

> The fallback to message reactions is no reactions. If a user is using
> a legacy client, message reactions will likely flood his messenger.
> Fallback *could* be done via quote of a previous message an appended
> reaction symbol. But it should not be done at all.
>

+1

People who prefer fallback messages here should be aware that this could
lead to legacy clients beeing unusable because of reaction message spam in
MUCs
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Reactions

[Florian Schmaus]

On 15.07.19 17:57, Jonas Schäfer (XSF Editor) wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Message Reactions
> Abstract:
> This specification defines a way for adding reactions to a message.
> 
> URL: https://xmpp.org/extensions/inbox/reactions.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
> 

There is a debate whether or not clients should include a fallback body
to the reactions they send with a lot of arguments in favour or against.
Unfortunately I find it sometimes hard to get an overview of all the
arguments exchanged in a mailing thread, and thus I decided to start a
little experiment to find out if we are able to come up with a
collaborative pro and con list:


https://wiki.xmpp.org/web/XEP-Remarks/XEP-:_Message_Reactions#Fallback_Body

Feel free to add your arguments here. I currently see nothing which
speaks against adding a fallback body ;)

- 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] Proposed XMPP Extension: Message Reactions

[Tedd Sterr]

> HELLO I AM REACTING WITH A THUMBS UP EMOJI PLEASE UPGRADE YOUR MUA SO YOU CAN
> SEE MY REACTION WHICH IS A THUMBS UP EMOJI BY THE WAY DID I MENTION THAT 
> THANKS

:frowning_face:

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

Re: [Standards] Proposed XMPP Extension: Message Reactions

[Ненахов Андрей]

The fallback to message reactions is no reactions. If a user is using
a legacy client, message reactions will likely flood his messenger.
Fallback *could* be done via quote of a previous message an appended
reaction symbol. But it should not be done at all.

ср, 31 июл. 2019 г. в 21:00, Dave Cridland :
>
>
>
> On Wed, 31 Jul 2019 at 16:43, Kevin Smith  wrote:
>>
>> On 31 Jul 2019, at 16:40, Jonas Schäfer  wrote:
>> >
>> > On Mittwoch, 24. Juli 2019 22:00:30 CEST Marvin W wrote:
>> >>> Backward compatibility
>> >>
>> >> There clearly have been opposing opinions on that matter. I believe they
>> >> are partly driven by different understanding on how Reactions might be
>> >> used in the wild, but I doubt there will be any way to reach consensus
>> >> on a rule that mandates a specific body or its absence. That said, I
>> >> support Florians suggestion to gather some implementation experience
>> >> first and decide on a more specific business rule afterwards.
>> >
>> > Right, I am very on board with using Experimental for this. I have a very
>> > strong opinion on the "how" though.
>> >
>> > Please, let us, right from the start, add a legacy body in all
>> > implementations. This will let us gauge how much it really affects legacy
>> > implementations *much* better than not doing so. Remember, without the 
>> > legacy
>> > body legacy implementations will not see anything; they might not notice
>> > they’re missing anything. On the other hand, if the legacy body is in fact
>> > harmful, we will actually get that feedback and can work on how to improve 
>> > it,
>> > possibly by removing it altogether.
>>
>> As an extension of the long debate in Council a moment ago, I’m very much 
>> opposed to adding a body fallback to these - I think it’s actively harmful 
>> for multiple reasons (mentioned there).
>
>
> HELLO I AM REACTING WITH A THUMBS UP EMOJI PLEASE UPGRADE YOUR MUA SO YOU CAN 
> SEE MY REACTION WHICH IS A THUMBS UP EMOJI BY THE WAY DID I MENTION THAT 
> THANKS
>
>>
>>
>> /K
>> ___
>> 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
> ___



-- 
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] Proposed XMPP Extension: Message Reactions

[Dave Cridland]

On Wed, 31 Jul 2019 at 16:43, Kevin Smith  wrote:

> On 31 Jul 2019, at 16:40, Jonas Schäfer  wrote:
> >
> > On Mittwoch, 24. Juli 2019 22:00:30 CEST Marvin W wrote:
> >>> Backward compatibility
> >>
> >> There clearly have been opposing opinions on that matter. I believe they
> >> are partly driven by different understanding on how Reactions might be
> >> used in the wild, but I doubt there will be any way to reach consensus
> >> on a rule that mandates a specific body or its absence. That said, I
> >> support Florians suggestion to gather some implementation experience
> >> first and decide on a more specific business rule afterwards.
> >
> > Right, I am very on board with using Experimental for this. I have a
> very
> > strong opinion on the "how" though.
> >
> > Please, let us, right from the start, add a legacy body in all
> > implementations. This will let us gauge how much it really affects
> legacy
> > implementations *much* better than not doing so. Remember, without the
> legacy
> > body legacy implementations will not see anything; they might not notice
> > they’re missing anything. On the other hand, if the legacy body is in
> fact
> > harmful, we will actually get that feedback and can work on how to
> improve it,
> > possibly by removing it altogether.
>
> As an extension of the long debate in Council a moment ago, I’m very much
> opposed to adding a body fallback to these - I think it’s actively harmful
> for multiple reasons (mentioned there).
>

HELLO I AM REACTING WITH A THUMBS UP EMOJI PLEASE UPGRADE YOUR MUA SO YOU
CAN SEE MY REACTION WHICH IS A THUMBS UP EMOJI BY THE WAY DID I MENTION
THAT THANKS


>
> /K
> ___
> 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] Proposed XMPP Extension: Message Reactions

[Kevin Smith]

Blah, I flipped 367 and 372 a couple of times here. I’m fine with using 
Attaching for this and not References - apply that rule whenever I screwed up 
the numbers.

/K

> On 31 Jul 2019, at 16:58, Kevin Smith  wrote:
> 
> On 24 Jul 2019, at 21:00, Marvin W  wrote:
>> 
>> Hi,
>> 
>>> * Jonas Schäfer  [2019-07-15 17:59]:
>>> Title: Message Reactions
>>> This specification defines a way for adding reactions to a message.
>> 
>> Given the feedback this proposed XEP received, I'd like to drop a few
>> more comments on the issues raised. Sorry, wall of text ahead.
>> 
>>> Referencing messages
>> 
>> There seems to be consensus that a generalized feature to annotate that
>> a message semantically belongs to a previous message or is a "child"
>> message of a specified "parent" might be of use for this and other XEPs.
>> 
>> For some reason, people always suggest XEP-0372 in this context, however
>> that XEP seems unusable for that purpose to me, for various reasons:
> 
>> On the contrary, XEP-0367 does not suffer from any of these issues
> 
> 
> The intention of References was both that it could add a reference to 
> something outside XMPP to a message (e.g. adding an image to a message) and 
> that it could reference a message in XMPP (and, indeed, that it can do both, 
> in order to attach an image URI to a previous message).
> 
> I’m happy for these two functions to be split and work on 372 to be the basis 
> of the ‘refer to a message’ bit (and then potentially 367 would make use of 
> 372 when it’s attaching a reference to a previous message).
> 
> So if References is removed from the running here for this, I’m not going to 
> be opposing it at all.
> 
>> Another alternative that I'd like to propose is to not mix server
>> processing information (which this seems to be, as it's mostly intended
>> to be used by a yet-to-be-created version of MAM) with client and
>> message information. That would mean that this proposed XEP as well as
>> others like LMC, Message Attaching, etc. are not directly affected.
>> Instead, some other XEP (Could be XEP-0334, but it could also be an
>> entirely new one) specifies a  element that would
>> only be used to describe the child annotation to the MAM server and
>> nothing else.
> 
> This bit, though, doesn’t make sense to me. If there’s a way of saying that 
> one message is an update (metadata or data) to another message, it makes 
> sense to me for that to be standardised and understood by both clients and 
> servers. 372 can be the basis of this, I think.
> 
>>> Correcting reactions
>> 
>> There are two main reasons for me to not use XEP-0308.
> 
> 
> I think the complexity of using 308 for this might be substantial and 
> difficult to reason about, and a new syntax that’s just concerned with ‘I 
> remove this thing I previously attached to the message’ might be better - 
> probably in terms of 372.
> 
>>> Limitation to Emoji
> 
> 
> 
> I think easier to limit it now, and expand later, once things are better 
> understood, than to start with the extra stuff in and remove it later. That 
> doesn’t usually work.
> 
> /K
> ___
> 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] Proposed XMPP Extension: Message Reactions

[Kevin Smith]

On 24 Jul 2019, at 21:00, Marvin W  wrote:
> 
> Hi,
> 
>> * Jonas Schäfer  [2019-07-15 17:59]:
>> Title: Message Reactions
>> This specification defines a way for adding reactions to a message.
> 
> Given the feedback this proposed XEP received, I'd like to drop a few
> more comments on the issues raised. Sorry, wall of text ahead.
> 
>> Referencing messages
> 
> There seems to be consensus that a generalized feature to annotate that
> a message semantically belongs to a previous message or is a "child"
> message of a specified "parent" might be of use for this and other XEPs.
> 
> For some reason, people always suggest XEP-0372 in this context, however
> that XEP seems unusable for that purpose to me, for various reasons:

> On the contrary, XEP-0367 does not suffer from any of these issues


The intention of References was both that it could add a reference to something 
outside XMPP to a message (e.g. adding an image to a message) and that it could 
reference a message in XMPP (and, indeed, that it can do both, in order to 
attach an image URI to a previous message).

I’m happy for these two functions to be split and work on 372 to be the basis 
of the ‘refer to a message’ bit (and then potentially 367 would make use of 372 
when it’s attaching a reference to a previous message).

So if References is removed from the running here for this, I’m not going to be 
opposing it at all.

> Another alternative that I'd like to propose is to not mix server
> processing information (which this seems to be, as it's mostly intended
> to be used by a yet-to-be-created version of MAM) with client and
> message information. That would mean that this proposed XEP as well as
> others like LMC, Message Attaching, etc. are not directly affected.
> Instead, some other XEP (Could be XEP-0334, but it could also be an
> entirely new one) specifies a  element that would
> only be used to describe the child annotation to the MAM server and
> nothing else.

This bit, though, doesn’t make sense to me. If there’s a way of saying that one 
message is an update (metadata or data) to another message, it makes sense to 
me for that to be standardised and understood by both clients and servers. 372 
can be the basis of this, I think.

>> Correcting reactions
> 
> There are two main reasons for me to not use XEP-0308.


I think the complexity of using 308 for this might be substantial and difficult 
to reason about, and a new syntax that’s just concerned with ‘I remove this 
thing I previously attached to the message’ might be better - probably in terms 
of 372.

>> Limitation to Emoji



I think easier to limit it now, and expand later, once things are better 
understood, than to start with the extra stuff in and remove it later. That 
doesn’t usually work.

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

Re: [Standards] Proposed XMPP Extension: Message Reactions

[Kevin Smith]

On 31 Jul 2019, at 16:40, Jonas Schäfer  wrote:
> 
> On Mittwoch, 24. Juli 2019 22:00:30 CEST Marvin W wrote:
>>> Backward compatibility
>> 
>> There clearly have been opposing opinions on that matter. I believe they
>> are partly driven by different understanding on how Reactions might be
>> used in the wild, but I doubt there will be any way to reach consensus
>> on a rule that mandates a specific body or its absence. That said, I
>> support Florians suggestion to gather some implementation experience
>> first and decide on a more specific business rule afterwards.
> 
> Right, I am very on board with using Experimental for this. I have a very 
> strong opinion on the "how" though.
> 
> Please, let us, right from the start, add a legacy body in all 
> implementations. This will let us gauge how much it really affects legacy 
> implementations *much* better than not doing so. Remember, without the legacy 
> body legacy implementations will not see anything; they might not notice 
> they’re missing anything. On the other hand, if the legacy body is in fact 
> harmful, we will actually get that feedback and can work on how to improve 
> it, 
> possibly by removing it altogether.

As an extension of the long debate in Council a moment ago, I’m very much 
opposed to adding a body fallback to these - I think it’s actively harmful for 
multiple reasons (mentioned there).

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

Re: [Standards] Proposed XMPP Extension: Message Reactions

[Jonas Schäfer]

On Mittwoch, 24. Juli 2019 22:00:30 CEST Marvin W wrote:
> > Backward compatibility
> 
> There clearly have been opposing opinions on that matter. I believe they
> are partly driven by different understanding on how Reactions might be
> used in the wild, but I doubt there will be any way to reach consensus
> on a rule that mandates a specific body or its absence. That said, I
> support Florians suggestion to gather some implementation experience
> first and decide on a more specific business rule afterwards.

Right, I am very on board with using Experimental for this. I have a very 
strong opinion on the "how" though.

Please, let us, right from the start, add a legacy body in all 
implementations. This will let us gauge how much it really affects legacy 
implementations *much* better than not doing so. Remember, without the legacy 
body legacy implementations will not see anything; they might not notice 
they’re missing anything. On the other hand, if the legacy body is in fact 
harmful, we will actually get that feedback and can work on how to improve it, 
possibly by removing it altogether.

kind regards,
Jonas


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

Re: [Standards] Council Voting Summary 2019-07-28

[Kevin Smith]

> On 29 Jul 2019, at 02:15, Tedd Sterr  wrote:
> 
> 
> 2019-07-17 (expiring 2019-07-31)
> 
> Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs 
> -https://xmpp.org/extensions/inbox/occupant-id.html
> Dave: [pending]
> Georg: +1 (would rather see occupant IDs in the form of JIDs, maybe even 
> passed in a 'jid' attribute in the XEP-0045 item tag)
> Jonas: +1
> Kev: [pending]
> Link: +1

I’m -0 on this at the moment. I’m concerned that there’s an assumption here 
that it’s desirable to be able to (effectively) de-anonymise semi-anonymous 
MUCs (they might be set semi-anonymous deliberately), and there’s a lack of 
security considerations about the cross-muc implications of poor generation, or 
of rainbow attacks with poor hash choices.

> Proposed XMPP Extension: Message Reactions - 
> https://xmpp.org/extensions/inbox/reactions.html
> Dave: [pending]
> Georg: +0 (for now; still undecided)
> Jonas: +1 (details can be ironed out)
> Kev: [pending]
> Link: +1 (issues can be ironed out before Draft)

This is definitely not the Right Way to do this, as we need a general way of 
referencing a previous message for assorted things, of which reactions are only 
one, and to use that everywhere, while the reactions syntax is not reusable. 
This mechanism could be references, or could be attaching, or could be 
something else, but a reactions-only syntax is definitely unhelpful when we 
need to be collating all the different types of meta-data responses and 
exposing them in archives. As-is at the moment, without that half of the puzzle 
solved (such as the collation stuff from the Summit), reactions are limited. 
I’m very concerned that not doing it Right at first when it goes Experimental 
is going to lead to a situation where it gets deployed and is almost impossible 
to fix the holes later due to inertia-once-implemented.

Council had a long and heated discussion about this today, and I think the best 
thing I can do is -1. My suggested remediation is to a) Get general agreement 
that either references or attaching can be our Future Mechanism For All The 
Things (I think we’re pretty much there) b) use Attaching (367) in reactions.

As a recompense for the -1, I’m willing to make the change to the protoXEP 
myself, if desired.

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

[Standards] XMPP Council Agenda 2019-07-31

[Dave Cridland]

The XMPP Council will be holding it's regular meeting today, in fact almost
now (Wednesday) at 1500 UTC. The agenda is collated from (in order of
reliability):
* Github pull requests and issues marked "Needs Council":
https://github.com/xsf/xeps/labels/Needs%20Council
* Random mails from Standards List
* Random suggestions directly to me
* A discussion in council@ the day before where Jonas and I frantically try
to collate everything.
* Me inventing things because after all nobody will notice.
* Things sent in reply to this message because, let's face it, things get
forgotten.

I (try to) send out the final agenda about 24 hours in advance.

Agenda as follows:

1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash if you think something's missing - just reply to
this message on list.

3) Activity Summary

* New XEP-0420 (Stanza Content Encryption) published.
* Last Calls open for XEP-0353 and XEP-0300, both due to close on 13th
August.

4) Items for voting:

a) AttributeError: section instance has no attribute 'a'

5) Outstanding Votes

Votes from Kev on anonymous unique occupant identifiers for MUC ProtoXEP
and Message Reactions ProtoXEP, expiring today.

6) Next Meeting

7) AOB

8) Close

Note that I'm aiming for 30 minutes.

Meetings are normally held every Wednesday at 1500 UTC in the
xmpp:coun...@muc.xmpp.org?join
 chatroom.
Meetings are open, and anyone
(XSF Member or not) may attend, though only XMPP Council members may
vote. Relevant comments from the floor are welcomed.

Thanks,

Dave.
(Ex Cathedra Concillium).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-07-28

[Dave Cridland]

On Mon, 29 Jul 2019 at 02:15, Tedd Sterr  wrote:

> *2019-07-10 (expired 2019-07-24)*
>
> PASSED (-0:1:+4)
> *PR #797 - XEP-0128: Remove 'unlikely' statement* -
> https://github.com/xsf/xeps/pull/797
> Dave: +1
> Georg: +1 (looks straight-forward; pretty sure it's not a breaking change)
> Jonas: +1
> Kev: [abstained]
> Link: +1
>
> PASSED (-0:1:+4)
> *PR #796 - XEP-0368: clarify what happens when a `.` target is published*
> -
> https://github.com/xsf/xeps/pull/796
> Dave: +1
> Georg: +1 (this is just a clarification of RFC 2782)
> Jonas: +1
> Kev: [abstained]
> Link: +1 (definitely!)
>
>
> *2019-07-17 (expiring 2019-07-31)*
>
> *Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs*
> -
> https://xmpp.org/extensions/inbox/occupant-id.html
> Dave: [pending]
> Georg: +1 (would rather see occupant IDs in the form of JIDs, maybe even
> passed in a 'jid' attribute in the XEP-0045 item tag)
> Jonas: +1
> Kev: [pending]
> Link: +1
>
>
+0 - I won't block this, but I'm concerned that we're introducing a new
identifier form for endpoint entities, which feels pretty rough,


> *Proposed XMPP Extension: Message Reactions* -
> https://xmpp.org/extensions/inbox/reactions.html
> Dave: [pending]
> Georg: +0 (for now; still undecided)
> Jonas: +1 (details can be ironed out)
> Kev: [pending]
> Link: +1 (issues can be ironed out before Draft)
>
>
+1 - Enthusiastic about the problem space, but my crystal ball suggests
this will need a lot of changes on the way to Draft.


> ___
> 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
___