Ge0rG+1 obviously. Also I'd like to AOB that a bit
KevOn-list.
jonas’+1, I think we can discuss all content details in Experimental stage for this one.
dwdI'm afraid I need some time to look at this, so on-list.
dwd(I can't imagine why I'd do anything but +1)
dwdAOB noted.
dwdb) https://github.com/xsf/xeps/pull/812 (Bump bytes datatype from unsignedShort to unsignedInteger)
Ge0rGon-list
dwdI'm +1 on this. It's just rectifying an error in the XML schema.
dwdNote that vanitasvitae posted about this on the list as well.
KevDefault to +1 unless I think of a reason it's daft later.
jonas’yeah, +1
Lancehas left
dwdOK.
pep.I poked lm
pep.(via sms)
dwd4) Outstanding Votes
pep.But apparently it's over already.
jonas’not quite yet
dwdIIRC, Ge0rG has some outstanding, as does Link. I think the rest of us have voted lodged.
Ge0rGI mailed in my votes yesternight
dwdGe0rG, Oh, sorry.
Ge0rGAt least I think now that I'm synced.
dwdIn that case, I think XEP-0353's vote is done, so we're just pending on XEP-0300.
jonas’I change my vote on XEP-0353 advancement to -1
jonas’I think the Last Call has provided valuable feedback and that needs to be considered before moving to Draft.
dwdjonas’, Noted, thanks.
dwd5) Next Meeting
dwd+1W?
jonas’wfm
dwd6) AOB
Ge0rG+1W WFM
dwdGe0rG, hit it.
Ge0rGI have two AOBs regarding CS-2020, one regarding Message Errors and one regarding Attach-To-Reactions.
dwdOK.
Ge0rGI'll start with CS-2020a: introductory text. The text in XEP-0412 is awful at informing developers that this is *THE* XEP to use as a guidance on what to implement first
Ge0rGI'd like to change the intro in CS-2020 and to make "compliance" a remote second in it.
jonas’+1
pep.(https://github.com/siacs/Conversations/issues/3530 as an exemple of how it's not being advertized correctly)
dwdIsn't this a third AOB item? But anyway, I'm fine with whatever you like.
jonas’dwd, I was confused for a second, too, but I think there are four AOBs in total, two for CS, one for Message Errors and one for Attach-to-Message
Ge0rGwhat jonas’ said
dwdAh. Ge0rG, master of the AOB.
Ge0rGWe still have 8mins left
Ge0rGNo wait, my clock is off.
dwdBut yes, I'm absolutely fine with some different introductory text.
Ge0rGGreat.
Ge0rGAOB CS-2020b: https://xmpp.org/extensions/inbox/cs-2020.html#future - I've added that section because we need something like it, but the content I've put there is very very rough.
Ge0rGPlease throw XEP numbers at me
dwdIdeally, that text would have broad agreement from the community, mind.
Ge0rGdwd: I'm sure we can gain that via a Last Call.
KevIn an ideal world the community would agree with us.
jonas’Ge0rG, XEP-0500
dwdGe0rG, But what if Royal Assent is withheld?
KevEqually, technical direction is one of the few things Council has purview over.
dwdSorry, wrong politics.
KevSo by our process the most important thing is that Council agrees to a statement of technical direction.
dwdKev, That's true enough. Also, "Ideally".
dwdGe0rG, WRT "Future Development", I suspect that could cause a lot of discussion, and potentially few conclusions.
jonas’dwd, Ge0rG, I tend to agree
jonas’I think "future development" is more like a wiki page
Ge0rGdwd: Maybe that. Or it will get ignored, like most other topics.
dwdGe0rG, I mean, your call. But I think it might be the cause of much stress for little benefit.
KevI think a little tweaking would make it fine.
Ge0rGI'm not going to die on that hill. If there are issues, I can axe that section
KevIf it simply said "These are the areas that Council believe ..."
KevThen if we agree between ourselves, it's non-contentious.
dwdOr if it suggested these were areas under development rather than a forecast of the future.
KevI very very much think we should have that section, because we need to stop using the compliance suites as a form of wishful thinking, which we often seem to.
dwdKev, Yes, I can accept that.
jonas’mmm
jonas’I tend to agree with the sentiment, Kev, but I don’t think the CS are the right place for that. Maybe they are, though, because it makes it very clear immediately what they are for (by having a dedicated Future section)
Ge0rGKev: so you say we need to move the wishful thoughts into that section?
jonas’so, no strong opinion either way from my side
KevGe0rG: Yeah.
dwdGe0rG, If you're up for the pain, keep the section and we'll see what we can do with it. But I won't blame you if you find it more painful than you can be bothered with.
KevThe world that we wish it to be, rather than what it currently is, can sit in that section.
Ge0rGI think there is value in having a section that contains XEPs that a (client) implementor should closely watch, or even implement under the premise that they will change.
jonas’Ge0rG, +1 to that sentiment, too
dwdGe0rG, There's both aspirational stuff and development stuff that could be there.
Kev+1 to the sentiment
dwdBut you're running out of time for Errors and Reactions.
Ge0rGdwd: so we need sub-sections
KevGe0rG: Or maybe a summary of why it's there.
Ge0rGYes.
KevAnything along those lines would work for me.
Ge0rGWell, well.
Ge0rGThe other AOBs won't fit into the remaining 3 minutes.
Ge0rGThey rather deserve a Council Meeting of their own. Each of them.
Ge0rGPlease comment on the "Persisting Message Errors (XEP-0280, XEP-0313, XEP-0160)" thread on standards@!
KevWe need to rethink archives so drastically it's painful.
Ge0rGWhat about starting to rethink message delivery, and then fixing archives on the way?
KevThat works.
Ge0rGOh wait, we started that two years ago.
dwdWell, errors I basically agree with. I should say so on the mailing list.
dwdIf I haven't.
Ge0rGdwd: you haven't
Lancehas joined
dwdReactions-and-attaching-and-stuff, I'm a little concerned that unless someone comes up with a proposal there, we risk rejecting every XEP in the space out of hand, which seems less than useful.
dwdAssuming that was the other AOB.
Ge0rGdwd: it was indeed.
jonas’yeah
KevRalph and I were working on stuff that I hope leads to a proposal.
Ge0rGdwd: we had a very productive discussion the other day on xsf@, and I've tried to summarize it in a gist.
jonas’I tried to get hold of the authors of Reactions and didn’t get a reply
Ge0rGI should just dump it onto standards, I suppose.
dwdjonas’, I believe that one of them joined the XSF, which is positive.
KevGe0rG was in the discussion too, actually. I wrote up some gists, Ralph is writing those up in a more consumable form.
dwdGe0rG, Please.
Ge0rGThree kinds of "References" in XMPP:
* Thread (in-reply-to); largely off-scope for our discussion
* References of things mentioned in the payload/body of a message (0372)
- nicknames, URLs, old messages by means of xmpp: URI, etc.
- multiple Reference elements are allowed
- Can be used inside Attach-To to add References to a previous message
- Can be sent by anyone
- is irrelevant to MAM 2.0
* Attach-To for content that only makes sense in the context of another message
- Usable for Reactions, Edits (former LMC), Retraction, Image / website previews, Receipts(?), Read Markers(?)
- A message can be attached at-most to one other message (nobody could think of a case where it would be needed, Ge0rG still objects)
- allows grouping / special handling by MAM 2.0, e.g. for thin clients
- generally, the attached payload SHOULD be inside of the <attach-to> element (e.g. reactions)
- for E2EE and legacy Last Message Correction, an <attach-to> without a payload implies that the sibling elements need to be reviewed
- Some kinds of Attach-To can only be sent by the original author or a privileged entity (bot/admin in MUCs)
- Attach-To messages SHOULD NOT be nested, i.e. attach-to another Attach-To message
Ge0rGKev: what form is ralphm writing them in?
KevHe's got a draft blog post about it.
jonas’Kev, can’t you make that proposal right away and get early feedback from the community?
jonas’ah; I’d prefer a ProtoXEP tbh
dwdI am somewhat concerned with rejecting a XEP for not using another XEP that doesn't exist.
KevI think a description of the concept is more useful than a protoXEP at this point.
jonas’dwd, yes
jonas’Kev, a ProtoXEP could be a description of the concept
jonas’it doesn’t have to be standards track, mind
jonas’(even though I’d prefer that)
dwdIt seems that it is not the fault of the authors, and nothing they can possibly do can remedy it.
KevOk. I got ahead of my schedule today.
KevSo I can write something tomorrow, interruptions allowing.
jonas’dwd, well, they *could* come up with a solution ;)
jonas’but meh
Kevdwd: Other than have said "Yes Kev, go ahead and make your suggestion"
jonas’Kev, I’m saying that because I know what happens to draft blog posts
KevI mean, I did offer to 'fix' it.
Ge0rGKev: it seems that you were the only one who interpreted your response as an actual offer to 'fix' it ;)
KevAm I updating Sam's spec, or writing a new mostly duplicate one for attaching, or rolling it into References?
jonas’Ge0rG, no, I also interpreted it that way actually
jonas’Kev, we need to do a breaking change to the protocol in any case
jonas’so I’d say go with a separate document for now, see what happens. It also prevents issues with getting Sam on board.
KevYes, but I would like Council to give me guidance here because I don't want a fight about having done the wrong thing.
Ge0rGI disagree with jonas’ here. Don't make a copy of Attach-To
jonas’I can still git mv inbox/kevs-thing.xml xep-0367.xml
jonas’I don’t have a strong opinion towards a separate document.
Ge0rGCan somebody summon Sam?
jonas’hardly
jonas’but MattJ is a co-author
KevWould I be right in assuming there is no desire to have all this described in a single document (references)?
Ge0rGKev: right.
jonas’Kev, references needs fixing first
dwdKev, I honestly don't care.
jonas’I made proposals on-list about that a year ago or so
Ge0rGKev: from our last discussion, we figured out three use cases. They should have three documents
Kevjonas’: There's two halves - one is references, the other is attaching.
dwdThe other half is MAM, of course.
Kev(Or three halves, if you include threads, which I think we decided to punt for now)
dwdWe're 10 minutes over, so unless anyone's got anything else pressing, I'm going to call it a day.
KevI would like a concrete agreement on my approach.
KevUpdate References for the one half, new protoXEP for the other (which can later overwrite attachment if people agree)?
jonas’Kev, ok, I don’t have a strong opinion on whether you do a new document or not, but I strongly don’t think that References is the right place for this.
Ge0rGTBH, with the ideas around redoing attach-to and to put the payload inside of the attach-to element, maybe forking it into a new document is the better way forward
jonas’Kev, ok, I don’t have a strong opinion on whether you do a new document for attaching or not, but I strongly don’t think that References is the right place for this.
KevJust give me a +1 on my approach, please people, and we can go home :)
jonas’Kev, pragmatically, I’d say prepare an update to Message Attaching
jonas’if we find it should be a separate XEP, that’s a trivial thing to do
KevI would rather not deal with the admin of removing an author if Sam doesn't believe it should be used for this, but if that's the will of Council I'll go that way.
KevJust between the three of you agree something, please.
jonas’Kev, in that case we can still fork into a new XEP.
KevMy preference is fork for now, as I said.
KevBut I will do either.
jonas’do whatever you like (except merging into References) from my side
jonas’the rest is just editor dutywork which I’m happy to do
dwdKev, Least contentious is write a new XEP.
jonas’my main point is, get a proposal out there
dwdKev, Since it's much easier to merge into an existing one later if we choose that.
KevAnd Ge0rG already said fork, so I think that's agreement. Thanks.
Ge0rGMessage Attaching 2
KevI will see what I can get done tomorrow.
Ge0rGI don't like forking.
jonas’"... (This time it’s going to stick around)"
jonas’Ge0rG, please.
linkmauvehas joined
dwdjonas’, He's suggesting a new XEP, not a fork. That's fine.
Ge0rGXEP numbers are cheap, right?
linkmauveAaah, sorry! I was moving to the Berlin XMPP Meetup just during council meeting! >_<
jonas’they are
dwdlinkmauve, Well, I think I'm finally going to close this meeting, so perfect timing...
KevThanks all.
dwdX_1) Ite, Meeting Est
jonas’thanks dwd for chairing, thanks Kev for taking a stab on the attaching thing, thanks everyone for everything
Ge0rGthanks jonas’ for the encouraging words
Tobiashas left
Tobiashas joined
Lancehas left
Kev_has left
Lancehas joined
Wojtekhas joined
Wojtekhas left
Lancehas left
Kevhttps://github.com/Kev/xeps/blob/fasten/inbox/fasten.xml
That's ludicrously simple, but I think it works as a first indication of how the marking that a payload applies to an earlier message would look.
KevThere are several details of the (primarily) ralphm / Ge0rG / Kev discussion that still need reflecting there, and References also needs work, I realise.
ralphmGe0rG: what Kev said. I'm drafting a blog post, with various way of pointing to things (attaching, referencing, etc.), in protocol and visual renderings, along with explanatory prose.
jonas’let’s move this to xsf@?
ralphmGe0rG: [moved over to xsf@]
linkmauvehas left
Reventlovhas left
Reventlovhas joined
Remkohas left
moparisthebesthas left
lnjhas left
moparisthebesthas joined
moparisthebesthas left
moparisthebesthas joined
Kevjonas’: Thanks. I'll try to incorporate that when I get to references.
XMPP Council - 2019-09-04