[Standards] Resurrecting Reactions

Jonas Schäfer jonas at wielicki.name
Tue Dec 10 18:12:50 UTC 2019


(Okay, this is the second email in 48h I write with a table of contents. 
Should I worry?)

Table of Contents:

1. General Stance on the Issue
2. Diagnosis on the current state of the XMPP Community
3. Diagnosis and Rationale for Reactions at the moment
4. How to move forward

TL;DR: +0 on Reactions; please please read section 2 if nothing else; I think 
Kevin and the Reactions authors should have a direct discussion about 
Fastening to move forward.


# 1. General Stance on the Issue

On Montag, 9. Dezember 2019 18:44:18 CET Dave Cridland wrote:
> 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.

Agreed.

Before I go on, first a few references to the relevant sessions for the 
interested reader:

  [2019-07-17]: The council session where Reactions was first discussed
     https://logs.xmpp.org/council/2019-07-17#2019-07-17-7d3d2519782de741
  [2019-07-31]: The day on which Kev vetoed Reactions:
     https://logs.xmpp.org/council/2019-07-31#2019-07-31-c49f57a7d6b9c741

> I disagreed with the decision the Council made in rejecting Reactions - in
> fact, all bar one Council member voted in favour of it.

Though upon re-reading the discussion, it was not as clear as this sentence 
may make it sound. It was quite a bit of discussion involved.

> 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
> responsibility.
> 
> 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.

(I find "overall verdict" a bit weird as wording, but that may be my non-
native tongue. The first intuition points me towards this being some kind of 
average or median of the member’s verdicts, but that’s not the case for 
Council.)

So... Uh. My problem with this situation is, that we’re in an awful stalemate. 
We have the suggestion by Kev on how to do the message fastening stuff, we 
have the Attaching XEP (which Sam says could also be used for this type of 
stuff) and we have References (which I think we can all agree isn’t really 
suited as *baseline* for MAM-collation because of being to complex. Also has 
unaddressed on-list feedback [1].). Fastening seems to be stuck still (no 
apparent progress, not even an Ack on-list, since Kev noted last week that 
there was feedback he missed).

We have the ProtoXEP which would solve the problem *right now*, although not 
in an ideal and future-proof way.


# 2. Diagnosis on the current state of the XMPP Community

I think this is a symptom of a *much larger* problem we’re having in the 
community. My diagnosis is this:

We badly want to fix so many broken things. We want to move forward, but 
instead we slow down ever more in our processes. This is because we’re afraid 
[2]. Many of the people involved are operating on a volunteer basis and cannot 
contribute as much to the actual code as they wish. However, those volunteers 
have *many* and really *bright and amazing* ideas. Those get discussed at the 
summit or written down in XEPs (for example, IM-NG, SASL2, Bind2, Fastening, 
the inbox ideas etc. etc.).

Then we also have a few bright people who manage to make their living off XMPP 
*and* being able to contribute back to the community, which is like the most 
awesome thing ever. Those people are in a certain position of power, because 
they shape the actual code and the actual experience users have. They can form 
expectations and they can easily form de-facto standards (example: 
Conversations with the current OOB usage and aes+gcm URLs) with a snip of a 
finger.

So now we, those who cannot contribute as much code as they’d like, are afraid 
about sub-optimal solutions sticking with us in the long term and making it 
*even harder* to adapt the ecosystem when the next big IM rift comes (and we 
still haven’t fully adapted to the 2010s). But the only power we often have is 
by shaping the XEPs, because we lack the time to put it into code. And we also 
lack the time to write proper XEPs which are a ready-to-use solution for those 
who write the code.

Pair this with the second-system syndrome which I think we’re suffering on the 
whole MAM-collation thing (with MAM, ironically, itself being more like a 
third-system to the way too complex XEP-0136 Message Archiving) to get a 
deadly and weird combination of tarpit and quicksand, pulling in ever more 
resources into slowdown.

Am I wrong? Please, tell me. I hope that this is just my perception.

(As a note: I am saying all of the above without any judgement and I do not 
intend to attack anyone. To compensate for any potential hurt, I’d like to 
throw out that Conversations is an excellent piece of software which has 
brought XMPP many steps forward by applying some pressure in a comparably 
short time. I also applaud smart people like Kevin and Dave who’ve served the 
community for decades and are always full of surprise "you can’t do that 
because it’d break X" - "uh, X even exists?!" for me :). So, really no hurt 
intended here and I hope I got this across without causing hurt. Let me know 
if I didn’t, I’d like to learn to do this type of stuff better.)

I digressed.

Back to the original topic.


# 3. Diagnosis and Rationale for Reactions at the moment

We have client developers who want to move forward with reactions, and we have 
users who want reactions and we even have Council members who want reactions.

But for some reason, we can’t get there. Obviously, nobody wants to mess with 
Kevs ProtoXEP (though nobody has asked for taking it over either).

So after several months have passed in this state, I understand and support 
the notion of re-considering Reactions in its current state to move forward 
*at least a bit*, acknowledging that Council may *require* the specification 
to be changed in a breaking manner before moving on to Draft, to get in line 
with a future MAM-collation-capable format.


# 4. How to move forward

> 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 think at the same time we need to acknowledge that the authors of Reactions 
are also volunteers whose time and motivation is being burned away here.

> I'm obviously keen that
> we can unblock this conversation again and seek some constructive progress.

Yes, but how?

So my questions for discussion are:

- Kevin, can you give any timeline on if and when you will be able to 
incorporate or at least discuss feedback on Fastening?

- If you (Kevin, again) can not give that, or the timeline passes because life 
happens, would you be happy to hand the ProtoXEP over to the Reactions folks 
if they are interested? I do not like this solution for multiple reasons, one 
being that I was (and still am) firmly against pushing the work of inventing a 
MAM-collatable protocol for MAM usage which doesn’t even exist yet on the 
shoulders of the Reactions authors.

- Reactions folks, are you interested in doing this work despite that being 
not ideal for us to ask of you?

- If not, would someone else be happy to step up? I most certainly would not 
get anything delivered this year, and I am also not proficient enough in the 
area of MAM (neither client nor server). Kim, maybe?


In addition: I am still +0 on the re-proposed Reactions ProtoXEP. I understand 
Daves concerns, but I think that the situation has changed enough (the promise 
of a solution to the attachment issue has not been delivered) to reconsider. 
We *may* come to the same conclusion, or not. I’m still on "let’s get this 
moving, but be aware that this may need to break before Draft hits".

(As a tangent on the "fallback body" issue: not a hill for me to die on. I 
still think that it’s a mistake to not have one by default, but I see that 
much of the people who get to actually decide and implement that disagree.)


kind regards,
Jonas


   [1]: https://mail.jabber.org/pipermail/standards/2018-March/034559.html
   [2]: Sorry, I may be projecting in this paragraph. Tell me if I am.




More information about the Standards mailing list