[Standards] Resurrecting Reactions

Dave Cridland dave at cridland.net
Mon Dec 9 17:44:18 UTC 2019

On Tue, 3 Dec 2019 at 20:51, Marvin W <xmpp at larma.de> wrote:

> I'd like the council to re-evaluate granting Experimental status to the
> proposed XEP. As per XEP-0001, "the granting of Experimental status must
> not be construed as indicating any level of approval by the XSF, the
> XMPP Council, or the XMPP developer community". If any of the council
> members prefers to refuse granting experimental status at this point,
> please give clear guidance on how to further process bringing this
> feature to XMPP in form of a XEP that can be implemented in practice.

I really dislike the notion of asking Council to essentially revote on
something a couple of months after rejecting it.

I disagreed with the decision the Council made in rejecting Reactions - in
fact, all bar one Council member voted in favour of it. Nevertheless, we do
not operate the Council on a simple majority basis - instead each Council
member has a veto to use to block adoption of new specifications and no
restraint placed upon this. So whether I agree with the reasoning or not is
somewhat irrelevant, as is the question of whether the members of the new
Council would have voted differently. Whatever the individual members of
Council choose to do, the decision of Council deserves some collective

Allowing decisions to be revisited after a couple of months merely because
there are new Council members who might see it your way now is, therefore,
a dangerous path. Therefore I will resist strongly any attempts to "wait
out" a Council or otherwise circumvent its decisions.

I think it'd be better if we considered the question of how to meet the
Council's overall verdict - that we need to have a generic and unified way
of specifying that a message relates to, and is subordinate to, another. I
desperately want to address Reactions in our standards suite, and while I
would have been fine accepting it as-is, I do nevertheless accept and
indeed agree that the general problem exists and needs addressing.

Various client implementers have noted that the nature of an
ever-increasing number of these ancillary messages means that MAM is
eroding in utility, as a request for the previous N messages gets, instead,
N receipts, reactions, and so on. Similar functionality, such as inboxes
etc, also suffers. The current solution server-side is to have the server
"know" what each ancillary message looks like - but this is both
unsustainable and undesirable, since we don't want to require a server
upgrade each time a new one is added.

I appreciate that your (and other) comments were left unacknowledged on
Fastening. While I hope you appreciate that we are all volunteers here
(even those who work on XMPP systems for a living), I'm obviously keen that
we can unblock this conversation again and seek some constructive progress.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191209/01b6b403/attachment.html>

More information about the Standards mailing list