Re: [Standards] Council Minutes 2019-12-04

2019-12-10 Thread Evgeny
On Wed, Dec 11, 2019 at 3:52 AM, Tedd Sterr  
wrote:
Dave notes this is unchanged since being rejected by the previous 
Council, and wants to avoid setting a precedent where an XEP is 
re-submitted unchanged until one Council eventually accepts it.


Just my few cents: I'm with Dave here. If it has been rejected by 
mistake, then something is unclear in the XEP and at least a 
clarification should be added before re-submission.


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


[Standards] Council Minutes 2019-12-04

2019-12-10 Thread Tedd Sterr
http://logs.xmpp.org/council/2019-12-04?p=h#2019-12-04-c6829034506b62e1

Jonas is sick and would prefer someone else chairs - Dave, glad to be free of 
chairing, volunteers.

1) Roll Call
Present: Jonas, Zash, Dave, Daniel
Apologies: Georg

2) Agenda Bashing
Dave has no idea of what's going on and asks if there's anything to vote on - 
Daniel would like to vote on accepting Reactions as Experimental.

3) Proposed XMPP Extension: Message Reactions - 
https://xmpp.org/extensions/inbox/reactions.html
Dave notes this is unchanged since being rejected by the previous Council, and 
wants to avoid setting a precedent where an XEP is re-submitted unchanged until 
one Council eventually accepts it.
Jonas mentions that the authors of Reactions are unhappy with the Message 
Fastening proposal and their concerns don't appear to have been addressed. 
Jonas's own position is that there are still problems with Fastening which 
haven't been addressed at all (e.g. overlap with attaching), and we still don't 
have Reactions in our ecosystem; accepting this would allow development of 
Reactions to continue.
Daniel understands the problems of over-riding a previous Council's decision, 
but believes the decision was plainly wrong in this case.
Jonas is concerned Reactions will become difficult to change once let out into 
the wild. And though it wasn't entirely wrong to veto the first time on the 
promise of a proper base for attaching things, that didn't quite materialise - 
Fastening had its chance, so let's move on with Reactions.
The whole situation irritates Dave enormously - who originally voted in favour 
of Reactions. Dave is willing to give a holding vote, and dig into this further 
- would really love to have Reactions, and a generic method of 'fastening' 
would be even better.

The author of Message Fastening, Kev, is unclear on what needs to be fixed, but 
is happy to do so - the original offer of doing the necessary work on Reactions 
still stands. Jonas thinks replying to the on-list feedback would be a good 
start, especially as Reactions' authors feel their feedback was unheard - Kev 
thinks that all got missed when it coincided with his holiday.

Daniel isn't sure voting is the most important thing here, rather figuring out 
the situation. Dave will commit to re-reviewing Fastening, Reactions, and the 
feedback - looks forward to Kev's on-list comments in response to the feedback.
Daniel feels that doing Fastening the Right Way (with proper MAM retrieval) 
will take years, so it's good to get started on Fastening, but doesn't think 
Reactions should be blocked by that.

Jonas: +0
Dave: -1 (previous Council's recommendations have been ignored)
Daniel: +1
Zash: [on-list]
Georg: [pending]

4) Next Meeting
2019-12-11 1600 UTC

5) AOB
Dave has resurrected the Spreadsheet of Doom [1] and is willing to give edit 
access to all who need it (Google account required); will endeavour (but not 
promise) to keep it up-to-date.

6) Close
Thanks all


[1] 
https://docs.google.com/spreadsheets/d/1ANu9KGmNf2r-qpLYqF7NdJTtqA1GIu55rf2deKbM0GA

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


Re: [Standards] Resurrecting Reactions

2019-12-10 Thread 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

2019-12-10 Thread 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

2019-12-10 Thread 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
___


[Standards] XMPP Council Agenda for 2019-12-11

2019-12-10 Thread Jonas Schäfer
Hi everyone,

The next XMPP Council Meeting will take place on 2019-12-11 at 16:00Z in 
xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and give comments.

This agenda is composed from:

- xsf/xeps GitHub PRs marked as Needs Council
- Suggestions directly sent to me (see below)

Agenda as follows:

1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash on-list or directly to me if you think something is 
missing.

3) Items for voting

3a) Resurrection of Reactions

This is expected to cause an interesting discussion. I’d like to specifically 
invite the authors of the Reactions XEP (thus added one of them explicitly to 
the CC) and Kevin.

4) Outstanding Votes

5) Date of Next

6) AOB

7) Close

End of Agenda.

Note that I am 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.

You can join anonymously using your Browser at https://xmpp.`org/chat?council 
.

If you have suggestions for an agenda item, you can message me via XMPP or E-
mail at this address or at jo...@zombofant.net.

I aim to publish the Agenda at the day before the Council meeting before 
20:00Z.


I will not be able to Chair or attend this meeting (again .. next time, I 
promise!), but Dave was so kind to offer to jump in. I sent my discussion 
points on Reactions (3a) on-list just now.


Thanks everyone,
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

2019-12-10 Thread 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] Council Voting Summary 2019-10-22

2019-12-10 Thread Kim Alvefur
On Tue Dec 10, 2019 at 12:05 PM, Kevin Smith wrote:
> On 30 Oct 2019, at 23:26, Kim Alvefur  wrote:
> > Does this wording look sane?
> > 
> > https://github.com/xsf/xeps/pull/848/commits/21128e508c76bfe5e0f50b490d9f4849472a2955
>
> 
> It does to me, at first glance. It’s not immediately clear what this
> needs in terms of bumping. The old spec was effectively broken, I think.

Bump the `urn:xmpp:contacts` node name to `urn:xmpp:contacts:1` or
something? I'm not aware of this being used anywhere and it doesn't
affect the vcard fetching use right?

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


Re: [Standards] Council Voting Summary 2019-10-22

2019-12-10 Thread Kevin Smith
On 30 Oct 2019, at 23:26, Kim Alvefur  wrote:
> 
> On Wed, Oct 30, 2019 at 10:52:35PM +, Kevin Smith wrote:
>> On 23 Oct 2019, at 15:25, Tedd Sterr  wrote:
>>> Advance to Draft: XEP-0292 (vCard4 Over XMPP) - 
>>> https://xmpp.org/extensions/xep-0292.html
>>> Dave: [pending]
>>> Georg: [on-list]
>>> Jonas: [on-list]
>>> Kev: [on-list] (feels like we've done this already)
>>> Link: [on-list] (will have to gather data about has been done and what 
>>> should be done)
>> 
>> Sorry to do this, but ISTM there's unresolved feedback on list about
>> https://xmpp.org/extensions/xep-0292.html#contacts-storage 's "SHOULD
>> NOT include an ItemID, so that the pubsub service can assign those
>> identifiers". So I'm -1 on the basis that I don't see a resolution to
>> that (can easily change my vote if I've missed it).
> 
> Does this wording look sane?
> 
> https://github.com/xsf/xeps/pull/848/commits/21128e508c76bfe5e0f50b490d9f4849472a2955

It does to me, at first glance. It’s not immediately clear what this needs in 
terms of bumping. The old spec was effectively broken, I think.

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