(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 <x...@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.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
