Re: [Standards] Resurrecting Reactions

[Kevin Smith]

On 10 Dec 2019, at 18:46, Andrew Nenakhov  
wrote:
> 
> Our stance on reactions, in a collection of theses:
>  - the most practical way to address reactions is something we refer to as 
> 'fastening'. 
>  - fastening also looks like the best way to attach error messages to stanzas
>  - fastening is also a possible way to do working message threads, 
> slack-style )there are other ways to make threads, but still, it's a 
> possibility)
>  - XMPP would greatly benefit from a unified approach to all these things
>  - archive question is not addressed at all, and storing all this crap in a 
> continuous stream is limiting archive usefulness (read markers are bad enough 
> already)
>  - also we can run into situations when we get attachment to a message that 
> we don't yet have
>  - we need a separate way to get 'main' message sequence and 'attachments'
>  - an 'inbox' system should use versioning to allow catching up missed 
> attachments in a conversation, just as it has to allow catching up on edits 
> and msg retractions)

Agreed with all of this, I think.

> (I'll be using the word 'attachment' for 'fastented' stanzas)
>  
> We are likely to try building a modified archive where we will have 3 types 
> of requests to MAM:
>  - basic, no changes from current
>  - with aggregated counter, where message is returned with a number of 
> attachments it currently has. Possibly, aggregated on type (6  3  1  1 ), 
> without authorship of those attachments
>  - verbose, with all messages and all their attachments, maybe nested.

I think this is pretty much what was discussed at the Summit (I don’t remember 
if that was in the room or over dinner!).

/K

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

Re: [Standards] Resurrecting Reactions

[Kevin Smith]

(Various bits snipped)

On 10 Dec 2019, at 18:12, Jonas Schäfer  wrote:
> 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].).

The path forward here, at least, is clear - last Council we discussed whether 
we wanted to use Attachments (despite at the time the belief that the Author 
didn’t want it used/adapted for these uses), use Reactions or write a new 
Fastening XEP very similar to Attachments, and Council’s opinion was that 
Fastening was the right thing to do. As I said at the time, I didn’t mind 
whether it was Fastening on Attachment, but that we should decide, and we did. 
I think revisiting this is the least sensible of the possible uses of our time, 
although others may disagree.

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

I’m not sure this is true, or at least depends heavily on your interpretation 
of ’the problem’. 

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


I’m sure this as fun discussion, but I think it’s tangential here.

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

Including, it must be said, me. I want reactions, and I have every intention of 
trying to get it into Swift as soon as I reasonably can, once we’ve got a 
suitable XEP.
(Equally, I have no wish to implement it twice, once to implement an interim 
XEP, and once for a long-term XEP)

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

I suspect the same reason most things don’t get done. We have limited time and 
it’s easier for someone else to do the work (the same reason that from the 
start I offered to make the needed changes to Reactions.

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

Indeed, see above.

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

Assuming nothing interrupts me, when I’m done with replying to this epic, the 
next emails in my stack are the feedback.

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

I hope this to be irrelevant.

/K

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

Re: [Standards] Resurrecting Reactions

[Andrew Nenakhov]

Our stance on reactions, in a collection of theses:
 - the most practical way to address reactions is something we refer to as
'fastening'.
 - fastening also looks like the best way to attach error messages to
stanzas
 - fastening is also a possible way to do working message threads,
slack-style )there are other ways to make threads, but still, it's a
possibility)
 - XMPP would greatly benefit from a unified approach to all these things
 - archive question is not addressed at all, and storing all this crap in a
continuous stream is limiting archive usefulness (read markers are bad
enough already)
 - also we can run into situations when we get attachment to a message that
we don't yet have
 - we need a separate way to get 'main' message sequence and 'attachments'
 - an 'inbox' system should use versioning to allow catching up missed
attachments in a conversation, just as it has to allow catching up on edits
and msg retractions)

(I'll be using the word 'attachment' for 'fastented' stanzas)

We are likely to try building a modified archive where we will have 3 types
of requests to MAM:
 - basic, no changes from current
 - with aggregated counter, where message is returned with a number of
attachments it currently has. Possibly, aggregated on type (6  3  1 
1 ), *without *authorship of those attachments
 - verbose, with all messages and all their attachments, maybe nested.

At our current speed and workload we might have a working prototype (client
+ server) to play with maybe in march, unless someone comes up with a
better working solution.


-- 
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] Resurrecting Reactions

[Jonas Schäfer]

On Dienstag, 10. Dezember 2019 19:16:32 CET Kevin Smith wrote:
> On 10 Dec 2019, at 18:12, Jonas Schäfer  wrote:
> >  I think
> > 
> > Kevin and the Reactions authors should have a direct discussion about
> > Fastening to move forward.
> 
> It is my intention to find the Fastening feedback I missed and reply to the
> various threads over the next couple of days (including reading the rest of
> this thread). So this is just a holding ack to say I’m not dead and I’m
> going to update Fastening once I understand what needs updating.
> 
> /K

I can help you, my browser has it in the recent history: 
https://mail.jabber.org/pipermail/standards/2019-September/036422.html

(Should’ve linked that in my rant.)

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Resurrecting Reactions

[Kevin Smith]

On 10 Dec 2019, at 18:12, Jonas Schäfer  wrote:
>  I think 
> Kevin and the Reactions authors should have a direct discussion about 
> Fastening to move forward.

It is my intention to find the Fastening feedback I missed and reply to the 
various threads over the next couple of days (including reading the rest of 
this thread). So this is just a holding ack to say I’m not dead and I’m going 
to update Fastening once I understand what needs updating.

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

Re: [Standards] Resurrecting Reactions

[Jonas Schäfer]

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

Re: [Standards] Resurrecting Reactions

[Dave Cridland]

On Tue, 3 Dec 2019 at 20:51, Marvin W  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
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.

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.

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

Re: [Standards] Resurrecting Reactions

[Florian Schmaus]

On 03.12.19 21:50, Marvin W wrote:
> Hi everyone,
> 
> I'd like to resurrect the Reactions topic.
> 
> 3. The ProtoXEP doesn't use a generic way to reference the message that
> is reacted on. However it was agreed that no proper way to do so
> generically existed until then. As a follow-up, the Fastening XEP-0422
> was proposed, with the intention to do some generic referencing thing.
> On this list, this XEP received some critique [3] from me and others
> that were not addressed yet and make it unclear to me how to correctly
> implement Reactions on top of it in various use-cases (updating
> reactions, encryption).

AFAIKT it was at least you and me who gave feedback on fastening 3
months ago. Sadly from this point everything regarding the development
of the fastening XEP came to an halt. I wonder if we could improve our
processes here. I'd really like to continue the work on this and and
like to avoid reactions being accepted as XEP in its current form.

- Florian



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