jonas’Nothing, but editor didn’t do anything. Bad editor!
jonas’4) Items for Voting
jonas’5) Pending Votes
jonas’6) Date of Next
jonas’Ge0rG, have a nice vacation!
Ge0rGjonas’: I'll try my best
dwdThe same time next week works for me.
jonas’Ge0rG had some I think
Ge0rGOh, I'm kinda unprepared.
Ge0rGI think you mentioned something about bringing uo the CVE thing on standards.✎
Ge0rGI think you mentioned something about bringing up the CVE thing on standards. Which I didn't do yet. ✏
Ge0rGAnd I have a hard time remembering last week's conclusion of what to do with <private/> and no-copy.
dwdMy AOB is that I'm getting a COVID vaccine shortly, which seems a bit pointless as I don't even have a 5G phone.
jonas’scrolls up to answer Ge0rGs implicit question
ZashSomething about not removing <private> IIRC
jonas’Ge0rG, the summary was, I think, that if you want to remove that strange <private/> behaviour, add a feature to indicate that the server in fact executes the new behaviour
jonas’otherwise it will do nothing good except chaos
Ge0rGWhy didn't we add a feature the last time we changed <private/> stripping rules?
jonas’past wrongs don’t give permission for new wrongs
Ge0rGI had a slight hope that the past wrong would be cancelled out by the upcoming wrong
KevI’m not even convinced that the last change wasn’t a mistake.
jonas’no, because there are a few years of practical deployment inbetween
KevBut I don’t think that means fixing it can skip the needful.
Ge0rGjonas’: given the amount of server developer feedback, I'm not sure this is true at all ;)
jonas’Ge0rG, yes, the lack of feedback does not allow us to come to any conclusion.
jonas’hence, we have to play it safe
Kev“Lack of feedback” doesn’t actually mean lack of feedback, does it?
jonas’even if the only diff on the server side would be adding a thing to disco#info
KevThere’s been lots of feedback, IIRC, in response to some of the previous 2039871032730987 last calls.
jonas’Kev, I think Ge0rG meant to reference lack of feedback on that specific issue
Ge0rGOkay, so I'll move forward by removing the stripping and adding a no-stripping feature.
dwdKev, Maybe we should keeping having more and more last calls until eventually we get no feedback at all and we can reject it on that basis instead.
Ge0rGNow what about no-copy hints?
Ge0rGdwd: That's an excellent idea
ZashLC of Zeno?
jonas’Ge0rG, I have no opinion on no-copy hints
Ge0rGWell, my (serious) question still stands.
jonas’nor do I have a clear picture about the implications
jonas’Ge0rG, could you summarize your thoughts on no-copy?
jonas’i.e. what is the current situation, what is bad about it and what would you like to change?
Ge0rGjonas’: no-copy was added as an AND requirement for clients after <private/> was there
Ge0rGthe requirements for servers are vague, at best
Ge0rGIMO, removing no-copy will not do any harm to specification-abiding implementations
Ge0rGThe only corner case I see is when a receiving client would rely on no-copy being there while <private/> being stripped by a stripping server.
Ge0rGSorry, somebody decided that *now* would be a good time to send thousands of vaccination notifications.
daniel(I just checked the only time I use no-copy in Conversations is when I send a direct-invite to my own connected resources to inform them that I've just joined a new muc. Which has arguably been made obsolete now that we have bookmarks in PEP)
jonas’daniel, lovely hack though :)
jonas’love the attention to detail in there
Ge0rGdaniel: why not sending one invite to your bare JID?
danielto avoid receiving it on my own client i guess
jonas’Ge0rG, OK, I don’t have strong opinions on that
jonas’as I assume that many implementations would handle <private/> even if <no-copy/> was absent if the XEP is worded vaguely
Ge0rGjonas’: that's my conclusion as well
Ge0rGOkay, thanks everybody for the fruitful discussion. I think I'm out of AOBs for now.
jonas’I sense sarcasm
jonas’dwd, do you want to elaborate on your AOB? :)
Ge0rGI'd never dare to
danielwhat are we achieving by stripping or not stripping that element?
Ge0rGdaniel: we get rid of legacy
danielby stripping it?
danielso you want to reintroduce legacy by telling servers to not strip it?
ZashI seem to have lost track of what exactly the question was
danielyes. me too
danielthat's why i'm asking
Ge0rGdaniel: I don't follow
Ge0rGdaniel: did you ask about no-copy or about private?
Ge0rG"that element" appears ambiguous in retrospect
Zashno-copy → strip from the XEP
private → don't strip from stanzas
Ge0rGwhat Zash said!
dwdIt seems to me that we've spent nearly half an hour doing protocol design in a Council meeting. Can we not write a proposal to the list, see if there's concensus to do anything (or nothing), and go from there?
Ge0rGputs it on his agenda
jonas’dwd is a smart person
jonas’let’s do what dwd s ays
jonas’any other AOB?
dwdNone from me.
danielnone here either
jonas’then I wish you all a pleasant rest of the day
jonas’8) Ite Meeting Est
Zashand thanks all
danielMessage Carbons is weird legacy anyway. I don’t thing we gain anything from messing with no-copy and private
danielyes it was a mistake to introduce no-copy
danielbut those extra bytes don’t matter
Ge0rGNo need to cement that mistake into eternity
danielconsidering the overhead that carbons has anyway
danieli really hope that Carbons don’t hang around for an eternity
dwdI'd be curious as to whether it matters if it *is* baked into eternity.
dwdI mean, if it's there already in implementations, does it matter?
danielplus looking at the history of the XEP it seems that stripping <private/> was a requirement before no-copy was even introduced
danielso the stripping of private is not to remove redundant information after the introducting of no-copy
danielit was there before
danieli don’t know why
danielso even if you were to remove no-copy you don’t need to mess with the stripping or not stripping of private
KevI think it was a mistake.
KevLooking at the changelog, the changelog seems to suggest it was trying to do the opposite of what it does.
KevNo, adding the stripping of private.
ZashEverything! Climbing down from the trees especially
danielconsidering that there are very few use cases for private/no-copy I suggest that we accept the fact that Carbons is not pretty but de facto draft and just leave everything as is and declare it as such
jonas’weren’t we there already last week?
Zashand try for a reasonable upgrade path to IM-NG?
jonas’however, the stripping of private might be considered actively harmful
KevI consider it is, yes.
jonas’so fixing that before moving to draft may be worthwhile
danielso remove no-copy don’t strip private?
Ge0rGremove stripping of private, remove no-copy from XEP
danielCan anyone think of a scenario of a receiving client that relies on the stripping?
danielBecause that's the breaking change here, right?
ZashAnyone remember why it's even stripped?
KevDepending on one’s definition of breaking, yes.
ZashISTR some privacy issue or something
KevZash: As I say above, I think it was a mistake. The changelog says that it was removed, but instead it was added.
Ge0rGI think there was a version of Carbons that required the *sending* server to strip, but then somebody realized that the receiving server needs that info as well
ZashMakes sense, I think Prosody still follows that 😕
Ge0rGZash: prosody will strip on the sending server?
ZashUnless I'm mistaken
danielOK. I've changed my mind. You have my blessing to remove the no-copy hint from the xep and remove the requirement to strip private
daniel(not that you need that since you are the author and the xep is experimental)
Ge0rGif that's true, the fact that nobody noticed it yet speaks tomes.
ZashHm, nm, seems to strip it on the receiving end only
Ge0rGso I've replaced the SDK shipped with AS by OpenJDK 12.✎