Ge0rGralphm: it allows the server operator to derive the user's screen time in the xmpp client
ralphmThat has almost nothing to do with the GDPR.
UsLhas joined
ralphmAnd if it has, there's legitimate interest for processing this information, namely for ensuring a particular feature. Actively using it to track screen time, rather than temporarily stalling traffic, however, would require permission.
ralphmFinally, servers don't have control over why/when clients send CSI hints, and the specification leaves that entirely up to clients.
sezuanhas joined
Steve Killehas left
jabberjockehas left
jabberjockehas joined
sezuanhas left
Steve Killehas joined
adiaholichas joined
adiaholichas left
adiaholichas joined
pdurbinhas joined
zachhas left
zachhas joined
wurstsalathas joined
Ge0rGralphm: so "using it to track screen time" is the actual issue, yes. Also it's got potential implications in enterprise setups, where unions are very keen on not allowing anybody to measure the employees' activity times
ralphmI understand completely, but that's not what CSI's purpose is. If you continue in that direction, there are many activities one could theoretically track to do that.
adiaholichas left
ralphmNow, if there was a dedicated protocol to explicitly relay user activity stats, that'd be different.
Ge0rGYeah, but data collection is not solely about the original purpose of the data
ralphmThere is difference in processing for legitimate purposes, processing it for analytics, combining it with other data, etc.
ralphmAnd then if you store it, there are also concerns around retention and deletability.
ralphmI personally think that the issue as you describe it is not a GDPR issue, unless the server is processing the information for more than the purpose of minimizing battery use.
Ge0rGThis is getting similar to the discussion we had about the clarification of stored message content
Ge0rGralphm: I agree with that
ralphmWell yeah, there, if you agreed that the server keeps an archive for you, then that's fine.
APachhas left
ralphmAnd public channels have a clear way of finding this out before joining.
Nekithas left
Nekithas joined
Ge0rGralphm: the question was whether the content is PII or even special category PII
ralphmPII is an old term not valid for GDPR discussions. There, we have Personal Information, and that's broader than the US term.
jonas’and article 9.1 stuff
ralphmPersonal Data, I mean
Ge0rGralphm: oh, I wasn't aware those are different things
ralphmGe0rG: oh yeah
jabberjockehas left
pdurbinhas left
APachhas joined
ralphmEven if you, for example, have a unique identifier for a person, linked to some data, but you don't know who that is, that's still considered Personal Data.
ralphmSo often, just anonimising might not be sufficient.
murabitohas left
Ge0rGralphm: the question was whether the content is Personal Information or even Special Categories of Personal Information
murabitohas joined
ralphmWell, I think in this case, since the purpose of the protocol is not at all about knowing if somebody's screen is on, you don't get to the special categories. Especially since the server cannot know in which cases the client is going to send it.
ralphmIn principle CSI just says: hold that thought until I say when.
Ge0rGralphm: but you know the client implementation from disco#info, and you can derive those things
jonas’yes, but that is being actively evil
jonas’purposes and such
ralphmRight
jonas’you *can* do it, but as long as you don’t, you’re fine
ralphmE.g. not storing / logging it would be a good start
murabitohas left
murabitohas joined
ralphmIn any case of doubt, by the way, talk to lawyers.
jonas’-ENOLAWYER
jonas’lawyers are expensive
Ge0rGralphm: lawyers are there to _increase_ your doubt
ralphmjonas’, Ge0rG seems concerned about corporations, they (should) have lawyers as well as data protection officers.
ralphmUsually it is about three things: purpose, consent, and retention.
ralphmI've learned that engineers, including myself, generally don't have sufficient legal knowledge to make proper assertions in this area.
ralphmBut I learned quite a bit over the last few years.
jonas’ralphm, if that was true, the result would effectively be that we have to shut down all operations (free jabber servers and possibly even software development) right now.
jonas’except maybe daniel, because he might be able to afford a lawyer
Ge0rGWhile being an engineer as well, I've been doing a large chunk of GDPR consulting in the last two years or so
ralphmjonas’: there are totally things an engineer can do: log as little as possible, or at least not continuously of you're not debugging an issue, only process information for the stated purpose, give control over retention, inform about what is stored/processed.
eevvoorhas joined
ralphmGe0rG: I'm not saying you have to be a lawyer. I said 'generally' and 'when in doubt'.
Ge0rGralphm: right
jonas’hooking into the silence: I was thinking that we might want to set up a mentoring process for first-time XEP authors
jonas’and I’d volunteer right away to be a mentor to those
jonas’my main issue is with how to present this
jonas’and where
jonas’i.e. how to make people make use of that?
SeveHow that would be? would it be a document with guidelines and so? (It is a very good idea by the way)
ralphmWell, getting in contact with an Editor before/during submission seems like a good first step in general.
Ge0rGjonas’: I'd suggest adding a paragraph for prospective authors at https://xmpp.org/extensions/
Ge0rGmaybe linking to a wiki page that you maintain, listing best practices and mentors
jubalhhas joined
ralphmXEPs 0143 and 0134 should be good starting points to highlight, as is XEP-0001.
jonas’none of those is a good starting point
jonas’sorry, but no
ralphmWhy?
jonas’they describe processes from the inside, not from the outside
jonas’I think?
jonas’something like that
jonas’there is a lot of information in there, but a lot of that also does not matter for when you’re first writing a XEP
ralphmThat doesn't make sense to me.
ralphmHow does it not matter?
jonas’I’m trying to formulate what I mean
jonas’I mean, those documents are nice and all to get your document in a reasonable state, but I don’t think they deal well with the experience a newcomer has or might have when submitting a XEP while not having had a lot to do with the community before
VaulorAixo es el que vull veure
ralphmVaulor: English, please.
jonas’ralphm, the mentorship things would be about the non-technical parts of the stuff, really. What interactions to expect on the mailinglist? How to properly process feedback? What to do with a rejection by council?
jonas’none of that is, to my knowledge, clear from the XEPs you mentioned
SeveVaulor, hah, wrong tab, right? :D
ralphmjonas’: right, I think that the suggestion by Ge0rG is a great one, except a proper page on the website itself would be nice. Noting some initial tips, suggestion to get mentorship with Editors, and then reference those XEPs as formal procedures and detailed guidance.
VaulorYup, sorry wrong tab indeed
Ge0rGa "proper" page is fine with me
ralphmVaulor: 🙃
sezuanhas joined
eevvoorhas left
Mikaelahas joined
Douglas Terabytehas left
Douglas Terabytehas joined
ralphmjonas’: in any case: yay, go for it
zachhas left
zachhas joined
jonas’context: the Message Reactions XEP, I think the silence from the authors speaks for itself. I tried to reach out to them yesterday, no reply yet though.
Danieljonas’, what part about the process is unclear wrt to the reactions xep?
adiaholichas joined
Dele (Mobile)has joined
ralphmDaniel: it is entirely unclear to me why it hasn't been accepted (yet?)
jonas’Is your question still open after reading this, Daniel?
> 07:33:30 jonas’> ralphm, the mentorship things would be about the non-technical parts of the stuff, really. What interactions to expect on the mailinglist? How to properly process feedback? What to do with a rejection by council?
jonas’right, I don’t think the rejection was made clear and public in the thread even.
jonas’that’s something council should probably work on
jonas’(or maybe the editor)
Daniel> Daniel: it is entirely unclear to me why it hasn't been accepted (yet?)
yes. i kinda understand that. but that what raises the question on how 'mentorship of authors' can help with that
edhelashas left
edhelashas joined
larmahas left
Danieljonas’, i'm personally not really under the impression that the authors (of that particular xep) need help with any of these points
ralphmDaniel: so was it indeed rejected? Where can I see this? I tried looking at the recent vote tallies and yesterday's meeting logs
mathieuithe council on reactions was one month ago, I think?
Mikaelahas left
Mikaelahas joined
ralphmWhy was it on the agenda (item 5) for yesterday's meeting then?
Danielwasn’t that retractions?
ralphmOh wait that agenda was an older one. Sorry
mathieuiactually that was exactly one month ago
ralphmI see now that Kev vetoed it
Ge0rGdon't confuse reactions, retractions and references with each other.
larmahas joined
ralphmI found the minutes of that meeting: https://mail.jabber.org/pipermail/standards/2019-August/036345.html
Dele (Mobile)has left
Dele (Mobile)has joined
Ge0rGthis is where "post-factum mail tagging" could come in useful
Kevralphm: I followed that up with a long mail to the list with an offer to do the needful myself to remove my veto. Although that time has probably now passed as I had the cycles then and don't now.
ralphmWell, maybe having explicit, separate, rejection notifications would help here. I thought we had that done before, or suggested, but I missed this.
KevWhich is about as good as Council can do, I think.
jonas’re XEP-0353:
15:17:20 dwd> I'm +1 for this. Seems widely deployed and sensible.
Daniel claims otherwise on-list. Fight!
ralphmRight, I am looking for that mail
ralphmOh, crap, it was buried in the thread of the initial submission. Sorry, Kev
flowA pitty that we only require two implementations before a xep can advance only for 'final'
ralphmflow: because we have that problem a lot?
Danielso reactions passed?
ralphmDaniel: no
flowralphm: the problem that xeps advance without much implementation experience nor feedback? I think so
ralphmflow: we were talking about accepting XEPs in the the first place.
flowralphm, I was responding to jonas' comment regarding xep353
ralphmWhich moved to Draft, right?
mathieuiDaniel, vetoed on list by Kev
flowand regarding accepting XEPs: I really think we are missing a IETF I-D equivalent. Where people can just create a stable home for their ProtoXEP to work on
ralphmI don't see why that's a problem. I have concerns about XEP-0353, but it is not set in stone.
ralphmflow: we do, it is called proto xep
ralphmAnd also
Nekithas left
flowralphm, I'd argue we do not
Danielralphm, you can’t really edit a protoxep tho?
Danielor can I? maybe i should try
Nekithas joined
flowDaniel, it's not really specified or at least promoted that you can
ralphmGenerally council should accept those. I understand that Kev tried to prevent chaos by not accepting Reactions at this stage, but I am not sure I agree.
flowI guess you could PR against XEPs in inbox
flowBut if this is encouraged then we should promote it more
flowOtherwhise establish something like xmpp.org/extensions/protoxeps/my-kewl-new-xep.html
flowwhere authors could PR against without much review
Danielbecause I actually wanted to edit the aesgcm uri scheme one
Danielso let me try that and see what happens
flowgo for it :)
ralphmIf a XEP is not accepted, an author is encouraged to address the feedback. I don't see how you can have it reevaluted without submitting a new version to the inbox.
ralphmRe-evaluated
ralphmBut again, I think in general most of this should happen in experimental.
Kevralphm: I note that Kev didn't really 'not accept' in practical terms, given that he was ready to make the changes right away so it could be resubmitted.
ralphmI believe the concern with reactions specifically is that seems undesirable to have this end up in production clients in its current state
Danielthe expected quality for an experimental xep varies between councils and moods
flowWhat if I want to develop a protoxep without submitting it right away? Could I simply PR it into inbox?
ralphmKev: I appreciate that of course, but the end result now is limbo?
KevYes, I wasn't anticipating the authors not taking me up on the offer.
Daniel> I believe the concern with reactions specifically is that seems undesirable to have this end up in production clients in its current state
I'm not sure that blocking it from becoming experimental will help that
ralphmflow: eh, that's a good question
Danieli'd implement reactions now if it weren’t for other problems in Conversations
flowDaniel, it probably does not prevent it, but then again, what's the gain for having it accepted if it does not prevent it?
ralphmKev: I don't notice that offer, so maybe they haven't either? Maybe we should make non-acceptance notifications explicitly a new thread.
ralphmDidn't
ralphmDaniel: even given the concerns?
flowAnd why not raise the bar a little bit for experimental to not accept XEPs with issues *and* a solution?
Danielflow, that is an interesting question. probably stable home + discoveribility
flowDaniel, well you could argue that stable home is already extensions/inbox/reactions.xml
flowerr .html
flowAnd I'd say that it is a feature that it is, in its current state, not easily discoverable
ralphmWe've had tried discussion before, I think Experimental is that state, and adding another one just moves names around.
Danielralphm, what if i don’t share the concerns? (to be clear we are talking very hypothetical here because i'm not going to implement it anyway any time soon)
Danielbut i can see the point of 'my users want this now and it is good enough for me and i don’t want to wait for the very complex problem of archive message collapsing to be solved beforehand'
debaclehas joined
ralphmI agree with Kev that there are issues, I don't like that we now have a proposal with issues that is not Expirimental and now people can't, you know, experiment. I also think it would be bad to have in production clients with the expectance of large changes, but YOLO.
Danielbut if experimental is that state than reactions shouldn’t have been blocked?
ralphm^
Nekithas left
Daniel> I also think it would be bad to have in production clients with the expectance of large changes
I agree but i don’t think the xsf should try to prevent that
Danielbecause it won’t be able to anyway
Danieland the attempt has other problems
Nekithas joined
Danielalso 'experimental' comes with the warning of 'do not use this in production'
ralphmMy concerns:
1) Unclear what ids should be used, and if that works properly in all cases, particularly in MUCs. Document doesn't state it, and the single example seems to use the original stanza id.
2) Interaction with MAM. There are various situations where you can retrieve message from the archive without having the referred message.
3) There should likely be a summary/counts feature.
4) I'm not sure if I like the way updates are done.
flowI still wonder why nobody hasn't simply wrote a quick "Reference Other Stanza" XEP, doesn't appear to hard. And would probably kickoff the discussion and steer it hopefully into the right direction
ralphmDaniel: I agree that the XSF shouldn't block stuff implemented in clients when in experimental. I just think it is not a great idea. And I also think that we may need to move a bunch of things from Experimental to Draft.
ralphmindeed, XEP-0367 would need some work, and maybe a rename, but this was discussed here before as a possible basis.
Danielregarding (1)
ralphmDaniel: is this a progression on the not-accepted specification
ralphm?
Danielralphm, oh tbh i didn’t check
ralphmWell, I don't think it is wise to discuss alternative documents that aren't somehow covered by our IPR
ralphmpolicy
Danieli wasn’t aware that the documents didn’t match
flowAnother argument to establish an I-D equivalent for XEPs
Danielthat link was just the first one to shop up in my browser history
adiaholichas left
mathieuiflow, no support for updating or removing an element
mathieuiDaniel, the documents are strictly identical as far as I can tell
KevSee, I was really thinking that what I was doing was the pragmatic thing to do that
a) Got the XEP published ASARP
b) Got us to a state where further XEPs could do consistent things
c) It wouldn't be obviously harmful to have in production clients.
ralphmDaniel: they don't seem to be different. And what I meant is that it is a bit vague even with that text. More examples would help.
KevI wasn't expecting it to end up with the protoXEP being abandoned instead.
KevI thought the outcome would be that the XEP got accepted a fortnight later, in a much better state.
Danielralphm, sure. there are things that can and should be improved.
mathieuipings larma about it
ralphmWithout insight into the author's intentions, I'm not sure if it has already been abandoned. Maybe vacation got in the way.
Danielon the other hand we also have experimental XEPs that are literally 60% TODOs
Ge0rGKev: in that case you should have just moved on with your offer to make a PR
ralphmHaving at least a response on Kev's extensive notes would help.
ralphmKev waiting for a response seems reasonable.
KevGe0rG: Hindsight is a harsh mistress.
Ge0rGflow: IIRC, sending a PR against inbox will mean that the editors trigger a resubmission.
Ge0rGKev: indeed.
lskdjfhas joined
DanielKev
> Which is why I offered to the authors to fix this now so the XEP could be accepted, as I had some spare cycles at the time, but that offer wasn’t taken up. I very much want a reactions XEP published, and was willing to put the time in to make it happen.
How would that fix have looked like?
Danielusing attachments?
Daniel(or just link me to the 'offer')
ralphmKev: do you foresee a clearing in your time? I'd happily collaborate on this.
Ge0rGIf I got the authors right, they talked to Sam about 0367 and got told that it's not acceptable for Reactions.
ralphmMaybe they should instead come here or on list.
eevvoorhas joined
ralphmIncluding Sam
Ge0rGralphm: maybe this is one of the non-obvious things for new authors that jonas’ was talking about earlier
ralphmyeah
jonas’and I don’t think all of those non-obvious things can be written down
jonas’but someone who has more knowledge of the internal workings of the XSF and the process will be quickly able to answer it
adiaholichas joined
jonas’and it’d be good to have a person assigned to each newbie-proto-xep who’ll deal with that type of questions
ralphmI like Sam a lot, but I don't think he's been aware of all the discussions that were had on this topic (and all other things concerning things 'attached' to messages).
ralphmAlso, Message Attaching, References, etc. all need work.
KevI think the easiest thing if Sam doesn't want Attaching to be used for this might be to either ask Sam to let someone else take over Attaching, or to submit a ~= identical XEP intending to be used more generally, and retire Attaching.
Ge0rGralphm: what do you see missing from Message Attaching?
Ge0rGKev: let's hope nobody rejects that ~= identical XEP on the grounds of it being duplication of Attaching, then.
adiaholichas left
ralphmGe0rG: particularly around how we all store and retrieve these things from archives
Ge0rGKev: I think that asking Sam would be the polite route, while Council could easily take over Attaching, assign it to anybody standing up for it and let it be the right vehicle.
debaclehas left
ZashMaybe gather everyone at a Summit and reinvent all these message relation things from first principles? 🙂
KevI deliberately said 'ask', not 'reassign', yes.
Ge0rGralphm: this is a hugely complex topic that's absolutely deserving its own XEP
pdurbinhas left
ralphmGe0rG: yes, but if we don't start to address it early on, this might be a lot of pain
Ge0rGralphm: we are already half-in into that pain.
ralphmGe0rG: I don't think we've barely scratched the surface.
Ge0rGralphm: we have north of four different ways to reference one message from another.
Nekithas left
Nekithas joined
ralphmZash: I've been toying with the idea of having a spec-writing-sprint on this indeed. The Summit is too far out.
Ge0rGmaybe the Reactions authors are actually right. We won't get rid of those legacy ways, and having four or five different legacy ID lookups in the server isn't such a big piece of work, compared to the other challenges.
Ge0rG(I mean: the difference between having four vs five)
ralphmwell, isn't the text about ids in reactions not a copy-paste from XEP-0353?
ralphmThis alone is reason to think that one should use the other
Ge0rGITYM 0367
Danielwell if we had (or can create in a timely manner) a general id referencing mechanism that we know for sure to be a one size fits all solution we can use that
ralphmI meant 0367 of course
larmaI talked with several people about Reactions XEP as well as general purpose referencing. I personally think we are running in completely wrong direction with that right now (including the blocking of ProtoXEPs, but also with general purpose referencing in general), but as announced on the list, I am happy to do any changes to Reactions XEP or other XEPs needed to get it accepted if there was council advice what is the best/acceptable way to do it. Last status I am aware of is that there are at least two ways to do it and there is no consensus which is the right or better way
Ge0rGSpeaking of 0367, I think its biggest conceptual problem is that the payload to be attached is not inside of the <attach-to> element
Ge0rGThat makes it impossible to use <attach-to> as a general vehicle for a LMC to a message that is attached-to another message.
Ge0rG(do I need to draw ASCII art?)
mathieuiGe0rG, but then having it inside will break the LMC fallback for clients not implementing it
ralphmGe0rG: I'd like to see that art, indeed. I think I understand what you mean, but not sure if it really is a problem.
Ge0rGmathieui: right. bummer.
Danielto be fair the introduction of 367 even mentions emojis. so it seems like a somewhat good fit?
Danieland creating Message Attaching 2.0 that is 95% identical might only be more confusinig
Ge0rG<message from=romeo id=1>cat-pic</>
<message from=juliet id=2><attach-to 1/>awww, this is ctue!</>
<message from=juliet id=2><attach-to 1/><attach-to 2><lmc/></>awww, this is cure!</>
Ge0rGralphm: ^
ralphmlarma: I didn't see your response to the comments by Kev on list, in the thread, or on the council minutes. Great that you want to move forward!
linkmauvehas joined
ralphmGe0rG: oh, you mean attaching with a body?
ralphmGe0rG: well, this is what we have threads for. I don't think I'd see what you have there as a valid case.
Danieli think the issue occurs when lmc uses attach-to
Danielthen you don’t know which attach-to is which
ralphmah
Ge0rGralphm: attach-to is an element that's not embedding what you are attaching but going side by side with it. So if you reference two different messages in one, the recipient doesn't know the meaning of the individual attach-to elements
adiaholichas joined
ralphmI'm not sure if I'd like to see multiple attach-to elements in one stanza ever.
ralphmSo maybe, LMC (or hopefully a more general message editing proposal) shouldn't use attach-to. Storage wise it also seems different from attaching.
ralphmLMC (etc) are basically versioning on an original message
larmaattach-to is *not* suitable for general purpose referencing in its current versions as it can not be used when two messages are being referenced for different reasons. It would work for the purpose of Reactions though, at least I don't see any conflict with existing XEPs at that point if its done (but one needs to be careful in the future about it)
Danielwell if the content of the attach-to were to be a child of the attach-to element you could simply treat it as to indivudal attaches. but yeah i agree that lmc is different to attaching and therfor should not use attach-to
Ge0rGDaniel: but if you stuff the payload into the attach-to element, you lose backward compatibility.
eevvoorhas left
Danielwell for some things that's good
eevvoorhas joined
Danielbecause for reactions we don’t want a fallback anyway
Ge0rGralphm: what about delivery receipts or read markers? Are those suitable for <attach-to>? How many different reference mechanism are actually needed?
ralphmXEP-0367 currently also says you can't have multiple.
Ge0rGDaniel: who is "we"?
DanielGe0rG, in that case the majority of people on the mailinglist
larmaIf we can't / don't want use attach-to for LMC, we need something else than attach-to for the general purpose referencing for thin client MAM
mathieuiGe0rG, most people who can envision how hellish a reactions fallback would be
larmaBecause both LMC and Message Attaching should be attached in the thin client MAM usecase
Ge0rG> Ge0rG, in that case the majority of people on the mailinglist
🤷
Danielputting the stuff inside the attach-to element would also limit what a MAM archive has to store
ralphmGe0rG: I am not sure if receipts or markers are a good fit either, indeed. When I think of attaching I think of use cases currently covered by References, SIMS, reactions.
Ge0rGralphm: yeah, so what's the cut-off point for use-case specific syntax vs. using a general attach-to vehicle?
Ge0rGThe current Attaching XEP is _obviously_ good for everything that appends visible content to another message.
ralphmAnd MAM wise, you probably want entirely different handling between: 1) LMC/editing, 2) reactions, 3) References/SIMS, 4) receipts, 5) markers.
Ge0rGbut then again, a receipt checkmark icon is also visible content attached to the message.
ralphmGe0rG: I see the latter more as meta data than an attachment
Ge0rGralphm: let's see...
1) store all edits together, deliver them all together
2) store all reactions together with the message, deliver them all together
3) same as 1 and 2
4) _maybe_ send receipts on behalf of the archive; don't forward receipts from each client of the user because once is enough(?)
5) same as 4?
pep.“ralphm: I also think it would be bad to have in production clients with the expectance of large changes” < it's probably been said already, but what goes into "production", whatever that means, is up to the dev and not the xsf.
larmaBtw, I'd also like to bring up the issue of SCE because we don't have enough complexity on this issue yet: When we have SCE and want to use thin client MAM, the reference must be outside of the encryption so that the server can attach. However the encryption usually also provides authenticity, thus the reference must also be inside the encryption. The thing outside the encryption should also carry minimal information, so should only be <ref id=A/> or similar as any information what kind of reference it is leaks information outside ot SCE (which kind of is its sole purpose). Additionally the server can't do any merging on content in SCE cases.
Ge0rGDaniel: is conversations making any use of per-contact-device markers/receipts?
ralphmpep.: I said I agreed with that indeed.
Ge0rGlarma: agreed. but there most probably will be a set of elements that a sending client must put both into and outside of SCE
pep.“flow: I still wonder why nobody hasn't simply wrote a quick "Reference Other Stanza" XEP, doesn't appear to hard” < if you read the reactions thread, Marvin volunteered
Ge0rGthe interesting thing is when you put content inside of the <attach-to>
Ge0rG...and if you read today's discussion in here, it IS hard.
pep.And no it's not exactly 367. From what I understand 367 wasn't meqbt to be used how council is pushing it to be (quote from the author, Sam)
adiaholichas left
pep.And no it's not exactly 367. From what I understand 367 wasn't meant to be used how council is pushing it to be (quote from the author, Sam)
Ge0rGpep.: a ref to that quote please?
ralphmGe0rG:
1) Not sure you want to deliver all edits. Maybe just the last one.
2) Store together (probably a separate dimension), retieve a summary, when needing more info (like when hovering), retrieve them all.
3) I'm not sure actually
4/5) markers are interesting in that you may have a bunch in groups, and you may want summaries, like with reactions
Ge0rGralphm: so we need four different ways to reference messages, for the purposes of Future MAM?
ralphmpep.: The goal of Council is to give guidance on protocol development. This might indeed conflict with an author's original intentions, and I am not sure if this is a problem.
zachhas left
zachhas joined
ralphmpep.: i.e. once a document is in the process, we rely on general consensus with guidance by council.
ralphmGe0rG: well, I'd say that the id handling is the same for all of them, but how such things are processed is different. I'm not sure if it should all be forced into a single element.
ralphmGe0rG: and yes, MAM handling itself is going to be much more involved than the currently naive single dimension.
Ge0rGralphm: from a MAM service implementers point of view, I don't just want to know the relationship graph (IDs), but also the type of edge invovled, so that I can do useful processing
adiaholichas joined
ralphmyes
Ge0rGralphm: so maybe "this message is some kind of reference of that message" is only useful if you want a naive two-dimensional store where the original messages are stored as a relationship group
Ge0rGbut not if you plan the things you outlined above
pep.“Ge0rG: pep.: a ref to that quote please?” < either I got it from the reactions thread from Marvin, or I heard it directly from Marvin who asked Sam when writing reactions
pep.(Still catching up with messages on this channel)
Ge0rGpep.: the last mails from Sam were purely sarcastic, it seems
larmaGe0rG, what I wanted to say: the general purpose referencing XEP would have to have some kind of usage attribute on it, so we can do something like `<ref id=A usage=attaching /><ref id=B usage=lmc />` (not necessarily this combination, but I am certain it will happen that we want one message to reference two others). Now if we put these <ref />s with usage outside of encryption we are leaking information.
I am arguing for the ref outside of the encryption being somehow different than the ref inside. As the ref outside may be manipulated by a MITM, it shouldn't be trusted by the recipient at all and be completely ignored. It should become a server annotation only, which is not relevant for the message as displayed in a client, but can be used for thin client message attaching (in which case a MITM attacker can only manipulate the message such that it is not displayed in thin clients at all, which they can anyway).
I'd prefer if we somehow write up what will be the usecases of the general purpose referencing so that we can actually find its requirements, before we force XEPs like Reactions to use something that makes little sense in practice later on.
ralphmGe0rG: well, I suppose the storage itself could be multiple tables or a DAG, or whatever. I'm not sure t.b.h., but the retrieval patterns differ.
eevvoorhas left
Ge0rGlarma: this is an interesting point in the current discussion ralphm and I have
pep.Ge0rG: mails from larma
ralphmlarma: what is SCE again?
adiaholichas left
jonas’stanza content encryption
Ge0rGralphm: Stanza Content Encryption
adiaholichas joined
pep.420
Ge0rGpep.: those don't count.
Ge0rGpep.: I'm looking for a statement from Sam, directly.
pep.Ge0rG: same
ralphmLarma: I'm not sure about the various cases in-or-outside encryption. I'd expected you'd want to encrypt all the things.
Ge0rGralphm: you can't encrypt for the MAM store
ralphmGe0rG: yes of course
Ge0rGThis is conflicting with "encrypt all the things"
ralphmGe0rG: I'm not sure if having some bits encrypted and some not is a useful thing.
Ge0rGralphm: nobody said it would be easy.
ralphmI.e. I don't think having server side archiving mixes with e2ee
Ge0rGralphm: it has to mix
ralphmWhy?
Ge0rGyou could argue that you can't have a "thin e2ee client", but I think there are people doing OMEMO in Converse.js
larmaPeople will want to a) have e2ee and b) use MAM and thin clients. We must make sure that it works.
Ge0rGpersonally, I think that XMPP and E2EE don't mix well, and that XMPP should be used in scenarios where E2EE is not wanted. But my opinion is very unpopular.
ralphmI mentioned this before, I am a bit skeptical about OMEMO and e2ee in XMPP context in general. You can't have all the things, I think.
Ge0rGralphm: we have to accept what the users want and try to make it work out
ralphmlarma: how, bar the protocols itself, do you think this is achievable?
Ge0rGwe already are the blackberry of instant messengers.
ralphmGe0rG: I haven't got any offers for narcotics yet.
Ge0rGralphm: didn't you complain about spam just some days ago?
ralphmyes, no narcotics :/
Ge0rGI'm sure there were also offers for illegal drug markets.
Ge0rGmaybe you couldn't read them because they were encrypted with Russian.
ralphmhm
larmaralphm, e2ee works with thin clients if minimal thin client annotations are attached outside the encryption. You are not leaking a lot of information by that, but still get the advantage of thin clients
DanielGe0rG, in my very personal experience a not insignificant amount of users are fine with the limited scope of omemo/otr/27 only encrypting the body
Danieli rarly get asked for sce
pep.Daniel: do they even know?
ralphmlarma: you mean that the act of referring is outside the encryption, but not the payload of said referencing
pep.What kind of user tells you that
larmaralphm, exactly and also the reason for referencing should not be mentioned outside
ralphmlarma: that might theoretically work, but it is probably a pain for proper handling of all the use cases I mentioned above.
Ge0rG> ralphm, exactly and also the reason for referencing should not be mentioned outside
this conflicts with Smart MAM
ralphmSMAM :-P
Ge0rGralphm: maybe a useful degradation would be "store all the grouped message in bulk, deliver them in bulk"
Danielpep., good question. i don’t know. the ones that are just using e2ee for the good feels probably not. but we don’t need to 'fix' it for them
ralphmGe0rG: I guess.
Ge0rGGiven that meta-data kills, XMPP E2EE is a huge scam.
Danielother than that i reckon it is not 'unknown' that the existing e2ee methods don’t do sce
larmaGe0rG, Not sure how smart your MAM should be, but if your server-side information is limited, obviously you cannot be super-smart
DanielGe0rG, i'd argue that the meta data that kills is mostly the who with whom
Nekithas left
Danieland not 'has read a message'
larmaAlso IMHO this is mostly hypothetical, the smart MAM will probably be adopted as fast as MIX
Ge0rGDaniel: speaking of which, somebody just complained over in prosody@ that their Conversations is sending a file encrypted via socks5 bytestream to gajim, but gajim doesn't decrypt it
Nekithas joined
Ge0rGlarma: normally I'm the one with the pessimistic adoption rate estimations
ralphmlarma: standards development is a) not easy, b) not fast. MIX has a lot going for it, but these concepts are hard and people's time is limited. If somebody would be hire me to work on this full time, I would.
Ge0rGyeah, can't we get our own cryptocurrency billionnaire sponsor?
Ge0rGI'd be glad to work on XMPP full time as well.
larmaA "MAM delivering grouped messages in bulk" would work and is rather easy to implement both server and client side. It's not a perfect optimization, but it solves the problem of thin clients.
ajhas left
ralphmAnd just to be sure, the reference itself should also be inside the encypted payload, to prevent spoofing, right?
Ge0rGright
ralphmAnyway, I am still curious: in which cases would one have to reference two different messages from one stanza?
Ge0rGa type-less reference outside, and a typed reference (LMC / reaction / ...) inside
Ge0rGralphm: the current go-to example is an LMC of a message with a reference
ralphmYeah, I don't see that use case.
Ge0rGwhy not?
Ge0rGbecause you want a dedicated protocol for LMC?
ralphmNo
ralphmI think that you'd either have loosely coupled messages in threads (using thread ids), or actual attachments. If you want to LMC the former, you can. I am not sure the latter would need to support edits.
ralphmOther than, maybe retraction, which is still not LMC
Ge0rGtechnically, LMC and retraction are very close
Ge0rGexcept for the moderator use case
ralphmBut for retraction you can just refer to the thing you are retracting. You don't need the whole thing.
Ge0rGso you mean a retraction lacks a payload?
ralphmI think so
ralphmLike in PubSub
Ge0rGI'd actually like to see retraction re-worded as a payload-less LMC, but I see there are reasons against that
ralphmI'd like edits instead of LMC
Ge0rGOTOH, we could extend LMC with a @by attribute denoting who did the edit
ralphmand retractions separate
Ge0rGI'm using LMC as a synonym for arbitrary edits. The "last message" limitation is the worst thing about that XEP
ralphmlet's kill it then
Ge0rGIf I had unlimited time, I'd rewrite LMC into "Message Edits"
Ge0rGralphm: what would you do differently with "Message Edits", in comparison to LMC?
Danielhas left
Danielhas joined
adiaholichas left
adiaholichas joined
ralphmMake sure it has the same id handling as the other things we've been discussing, lift the limitation on the last message, change the title?
ralphmI /don't/ think we should support editing messages by others in any form. This is why I think we should have a separate thing for deletion.
ralphmeh. retraction
Ge0rGralphm: speaking of ID handling, we haven't figured out yet all cases of how to edit a message that we didn't receive back from a MAM yet.
ralphmModerators should surely be able to retract others' messages
ralphmGe0rG: I think all of this discussion hinges on figuring that out
Ge0rGralphm: I think it's useful to have editing of messages by moderators.
ralphmGe0rG: why?
Ge0rGYou could remove expletives for example. mod_pastebin could be implemented in terms of editing.
ralphmI think that opens quite a can of worms
ralphmEither a message is acceptable, or it isn't.
Ge0rGBecause we have a good server side mechanism to enforce what's acceptable, that can be used by moderators?
ralphmI'm not thrilled about a way that allows moderators to edit random messages. It makes it hard to see whose message it was. I suppose you also need to be able to trust the MUC server in any case.
zachhas left
zachhas joined
ralphmI'd much rather have a situation where people are in control of their own words, and if that's not acceptable, the message is retracted in its entirety.
ralphmThat also makes it much easier to have edits override the original. If others can edit, you need to also be able to retrieve the original.
adiaholichas left
GuusIs having the XSF not wanting to deploy specific features reason to prevent a XEP that implements exactly that feature from being standardized?
GuusI'm not liking content editing by third parties either - but should we therefor not allow such a XEP to exist?
ralphmReading back, it still isn't clear to me how Sam thinks XEP-0367 should be used, and how Council wants something else.
GuusI'm not liking content editing by third parties either - but should we therefor not allow such a XEP to be standardized?
ralphmGuus: well, I don't think it is wrong for Standards JID to have an opiniated process.
matkorhas joined
ralphmGuus: we deal with privacy and security concerns, so maybe yes that could mean we won't standardize a particular feature.
ralphmGuus: and that in turn might mean that you'd have to have a private extension, or write an IETF draft
flow> larma: "However the encryption usually also provides authenticity, thus the reference must also be inside the encryption."
I am not sure about the "must" here. And I also think this is a good example for something we should not bother with at this stage. I do believe can't solve the metadata issues with e2ee in XMPP right now, and probably ever.
ralphmflow: I have the same feeling about metadata
Nekithas left
Nekithas joined
flow\o/
matkorHi! By who's lack of activity https://xmpp.org/extensions/xep-0396.html is Deferred?
ralphmmatkor: usually this means the Author, but in principle 'all of us'
flowmatkor, everyone. As in, someone just needs to work on the XEP
flowmatkor, but why do you bother about it being deferred?
flowif you implemented it, then please provide feedback
flowideally that leads to an update of the XEP, un-deferring it
flowRe attach-to/reference: Why not simply have a <reference-ohter-stanza/> without childs which references at most one stanza regarding one concern?
flows/at most/exaclty/
matkorflow, I am just newbie XMPP user trying to transfer files encrypted between gajim and conversations. Not sure what is "right way" to do it
flowmatkor, that's the question we ask yourselfs here daily: What is the right way :)
matkorSeems Conversation uses XEP-0396 with success I wondered why gajim is lacking it.
Ge0rGflow: "references exactly one stanza regarding one concern" so what do I do if I want to reference two stanzas regarding different concerns?
flowmatkor, the answer is usually because nobody implemented it
ralphmflow: yes, I was just discussing with Ge0rG whether there are cases you'd need to refer to multiple messages, and I stated that I don't think there is one, really.
flowGe0rG, send two stanzas
ralphmGe0rG: still like to see that use case
Dele (Mobile)has left
flowor maybe it is not clear to me what "want to reference two stanzas regarding different concerns" means
Ge0rGflow: what, if the same content relates to two stanzas in different ways?
flowGe0rG, send two stanzas?
Dele (Mobile)has joined
flowalso, please provide a more-or-less real-world example
matkorflow, sure, but there are usually reasons why sth is not implemented like a) there is better way, b) sth is obsolete
flowotherwise it is hard to reason about it
ralphmmatkor: c) nobody has found the time, yet
flowmatkor, the most common reason is because nobody did it
Ge0rGralphm, flow: I don't have a convincing example at hand, but I'm pretty sure we'll end up wanting to edit a message that's attached-to another message.
flowGe0rG, edit as in? LMC?
Ge0rGflow: yes
Ge0rGflow: see my discussion with ralphm above regarding "edit" vs LMC
flowGe0rG, the LMC that message that is attached-to another message with the yet-to-be-invented generic attach-to mechanism
flow*then LMC that
Ge0rGflow: but I want LMC to use the generic attach-to mechanism!
Ge0rGit's not generic if it doesn't cover LMC
flowthen bump LMC to do so
Ge0rGflow: but then I have double references.
larma`<message><body>this and that message</body><ref id=A start=0 end=4 /><ref id=B start=8 end=12 /></message>` = message referencing two other messages, although these references are probably not relevant at all for thin client MAM
Nekithas left
Nekithas joined
flowGe0rG, double references?
Ge0rGflow: two references in one message
flowWhere?
ralphmlarma: that is a good use case indeed
Ge0rGflow: 1) this is an edit of my message X; 2) this is a reaction/attachment/whatever to message Y
Ge0rGralphm: I'm sure Message References does cover that one ;)
ralphmGe0rG: except if you want to use XEP-0367 for doing referring to another messages.
flowlarma, how often do you reply in one mail to two mails in a mailing list? That is one of the seldom uses features of mailing lists and MUAs
flowthe mail protocol allows it, but is very seldom used
Ge0rGflow: in the context of Message References, you can also reference users, URLs, etc.
Ge0rGflow: so it would be perfectly fine to have a message with 64 references, containing the nickname of each other occupant of this MUC
flowGe0rG, probably, but that is not the context discussed here
Ge0rGflow: if only we had thread references.
wurstsalathas left
flowWe are strictly taking about referencing stanzas, and the question is: Do we want to introduce additional complexity by allowing one stanzas to reference more then one other stanza
wurstsalathas joined
larmaflow, so you are proposing to change from "seldom used with XMPP" to "I use email instead because XMPP doesn't support it"
pdurbinhas joined
Ge0rGralphm: but only because 0372 lacks support to reference messages ;)
ralphmThere's a difference between pointing to a message with some id (which can be documented seperately), and use cases thereof: creating a secondary message that attaches to, or edits, a particular message, v.s. a separate message that wants to 'refer' to what was said before. FWIW, I'm not sure how to render larma's example.
Ge0rGflow: I've given an example above.
flowlarma, no, I am saying that I never once in my life found myself in the situation that I wanted to reply two more than one "post" with a single "post"
flowbe it xmpp or mail
flowand I believe this to be true for the majority of users
Ge0rGI was multiple times in a situation where I wanted to reply to multiple mails from subthreads of the same thread. On standards@.
Ge0rGArguably, I'm not the majority of users.
flowGe0rG, then why didn't you do?
ralphmI think larma is more like including hyperlinks
ralphmlarma's example
Ge0rGflow: because I had no idea how.
larmaflow, But what does that imply? That we shouldn't be able to handle it on a technical level?
adiaholichas joined
flowlarma, I don't believe the increased complexity is justified. Please note that I am strictly talking about referencing stanzas
ralphmXEP-0372 has a way to include hyperlink references to URIs and we may want to construct a way to express a pointer to a particular message, either in private context, or in MUCs, but I don't think this is the same as the other use cases.
flowGe0rG, let's assume you didn't know how is because your MUA either does not provide the feature or because it is very well hidden. Then you can ask yourself why that's the case…
larma`<message><body>look at that previous message</body><reply-to id=A /><reference-back-to id=B /></message>`
ralphmI.e. you can still have a URI that points to an XMPP message, or a tweet, or a something else.
flowthat that URI potentially would not be processed by the message archive in any way, which is probably fine
ralphmlarma: we don't have reply-to, really, we have threads
ralphmflow: indeed
Ge0rGbut nobody uses threads, so we should replace them with generic references.
ralphmgod no
larmaralphm, we don't have X so we should never ever support it
Ge0rGbut if we do that, we have a convincing example of why it makes sense to have two references in one message.
flowso we can have references with a exactly-one limit, which is processed by the message archive, and references with a one-or-more semantic, which are then not processed by the archive. That sounds like a good comprosmise
Ge0rGreferences and References.
flowalthough I am not sure if we need the one-or-more semantic references ever
ralphmlarma: not at all. We do have 20 years of prior work, and Ge0rG's assumption that nobody uses threads is probably not true.
KevIt's probably not true, but it's pretty close to it.
ralphmIn the end this discussion is about the tightness of coupling
flowlarma, it's not "never support it", but be obviously should not design protocols with things that do not exists (and are not going to exists in the near future) in mind
pdurbinhas left
Ge0rGflow: I disagree on this one. We should take into account the long-term delelopment of the protocol when adding new XEPs
Ge0rGOtherwise, we end up with MAM and Carbons.
KevI can't catch up with all the backlog, but re: multiple references, I think you have one "This message follows on from this other message" reference (attaching, if you will), but potentially have a message reference many other things (some of which may be messages). e.g.:
"re: Ralph's mesage<AttachmentReference>
Hey @<Reference>Ralph, I agree, but did you see @<Reference>Ge0rG's <reference>message earlier?"
flowGe0rG, I did not say that we should not take the long-term development into account. But I have never heard of anyone talking about introducing reply-to
KevWhich is why I'm quite happy with the idea of keeping attaching and references distinct.
Nekithas left
KevBe it the two XEPs, or two different annotation types in a single XEP.
flowKev, does that matter much?
Ge0rGKev: I'm not quite sure what you mean by "follows on"
KevYes, and I realise there's essentially three reference types, as you say that.
Ge0rGKev: but I assume 0372 is about showing a kind of hyperlinks inside of the body, whereas 0367 is about structural order of messages in the archive, delivery and display?
Ge0rGKev: three?
KevThere's In-Reply-To, which was my first reference in that message, there's "Here are some other data relevant to the message", which were the others, but there's also "I am hanging this message off the other and it doesn't make sense in isolation", like Reactions and Editing/Correction.
ralphmIf a message is strictly about another message (this message is marking up that other message with hyperlinks, and I'm referring to characters 4-6 in this other message, References), Reactions, Edits, Markers, then I'd say we can come up with a generic mechanism for including such a singular reference. E.g. by using attach-id. If you want to point to other things loosely (again References, but the *target* of the link is elsewhere) you can use URIs or somesuch.
Ge0rGIn-Reply-To is what threads are for. But isn't a Reaction also In-Reply-To?
KevI am happy to limit 372 to the second type. I originally intended to cover everything, but I'm not dogmatic about that.
ralphmGe0rG: you can model it all kinds of ways. In e.g. Slack, a textual reaction is a separate thing, that itself can have emoji reactions, marking up (references), etc.
Ge0rGralphm: I'm trying to understand all the implication, and maybe to find a good way forward.
Ge0rGI think that the trinity proposed by Kev is a good approximation
ralphmKev: I'm saying that in 372 you have two types of things to refer to: 1) the plain text you are marking up, with char refs, 2) hyperlinks to tie to those hot texts.
andrey.ghas left
Nekithas joined
Kev(Incidentally, I don't think threads necessarily are fit for purpose, but I'm happy with just saying it's a distinct requirement and excluding it from discussion)
Kevralphm: There are two halves of that type of reference, yes.
ralphmfor 1) you need something like attachments, 2) URIs are great
Ge0rGralphm: for 1 you need what's written in 0372
Ge0rGunless you want to make the marking-up a separate message from the original text
KevGe0rG: Which I think has value.
Ge0rGin which case, you attach-to the original message a set of reference-markups
Keve.g. a MUC service that annotates a message once it's fetched an async resource.
ralphmGe0rG: this is about 'anchor' v.s. 'uri'
ralphmGe0rG: we can replace 'anchor' with 0367.
Ge0rGralphm: now I'm totally confused.
ralphmAnd then make it easier to mark up multiple parts of the text without having to repeat the anchor.
Ge0rGralphm: to quote from 0372, which is anchor and which is uri?
1 <reference xmlns='urn:xmpp:reference:0'
2 begin='72'
3 end='78'
4 type='mention'
ralphmGe0rG: a link has two parts: the text you want underlined, the URI you want to jump to. Clear?
KevLet's see if I can avoid distraction long enough to gist some example thoughts.
LNJhas joined
Ge0rG 5 uri='xmpp:juliet@capulet.lit'/>
Ge0rGralphm: so 2+3 is the anchor, and 5 is the uri
Ge0rGralphm: and if you want to make the <reference> a stand-alone message, you need to attach-to the list of <references> to the original message.
ralphmGe0rG: XEP-0372 has two examples: one with a plain text included, there's no anchor here, because you are referring to the included body. The other has no body element, so you want to reason over some other, earlier message. So that example has an anchor attribute, and I'm saying that we can replace the latter with 0367.
ralphmGe0rG: yes
andrey.ghas joined
ralphmThe former is section 3.2, the latter is 3.4.
ralphmOne flaw with XEP-0372 as it is now is that you can have a single message that has references with two different anchors. I think that's confusing and stupid, and having that replaced with XEP-0367 would be a lot cleaner.
linkmauvehas left
Ge0rGralphm: wwhen do you need two different anchors?
KevYes, I think your 12:04 XML is roughly equivalent to what I pasted in intent.
ralphmKev: but at most one, right?
larmaI'd also like to consider that there is semantically two types of attachments: Those that only the original sender and maybe a MUC (admin) can do (LMC, Retraction, Attaching?) and those that everyone can do (Reactions, replies)
Ge0rGokay, "low effort" actually means you need to extract attach-to skeletons
KevAh, hi larma.
balu_der_baerhas joined
KevYes, I was thinking about ACL on this stuff earlier. I suspect this doesn't affect the wire protocol, but I'm aware a MUC might need to e.g. whitelist attach-to payloads.
balu_der_baerhas left
ralphmlarma: that is a good point, clients would need to check for this
Kevhttps://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a updated again
larmaGe0rG, why is the body outside the attach-to? looks wrong to me
Ge0rGlarma: because of backward compatibility to pre-LMC clients
larmaBut semantically what you wrote is "attach the lmc marker to the message and have a message with this body"
Ge0rGthe lmc-marker is meant to signify that.
flowis backward compatiblity really something we should be concerned in this case?
Ge0rGflow: yes.
ralphmThis is also why I wondered if it wouldn't be just as fine to have the attach-to be empty and a sibling.
UsLhas left
KevI think, in as far as we do fallbacks at all, we might have to consider having duplicate content here.
ralphmKev: you last example, message 6, would have backwards compat issues
Ge0rGralphm: it's not elegant, and only workable as long as you have at-most-one attach-to. Also it makes parsing in "Smart" MAM way harder.
ralphmGe0rG: still want that more than one example.
Ge0rGralphm: just because we two can't come up with one, it doesn't mean there is none
larmaI think having attach-to a sibbling makes sense for those messages that do work as standalone, i.e. when you don't have the previous message (LMC, replies), but not for those that don't (reactions, retraction)
Ge0rGlarma: good point
KevUpdated.
Ge0rGKev: what's wrong with my <lmc-marker/>?
ralphmlarma: for reactions, retraction, you wouldn't point to two different messages in one stanza.
KevGe0rG: Maybe just that I missed it in the flow.
larmaKev, I totally dislike the duplication of the body for backwards compat
Kevlarma: Good, me too :)
Ge0rGKev: 12:12:49
larmaralphm, that's for those that only point to one (attach-to, not references)
KevGe0rG: That might work.
Ge0rGralphm: what about reaction retraction?
Ge0rGlarma: 0372-style references are a different topic
ralphmGe0rG: you can just retract the stanza of the initial reaction, like message 4 in Kev's example
Ge0rGKev: yeah
larmaKev, that's implying that you can only change the body with LMC
ralphmYes, that's what it is for.
Ge0rGralphm: no, it's for any kind of payload.
larma> Correction MUST only be used to change the logical content details of a stanza (e.g. the message body) and not to change the nature of the stanza
KevIn this example, the attachment payload is still within the attachment element, which is good, it's just that it's then a pointer (careful not to say reference) elsewhere in the stanza.
KevYou're both right.
KevOr all three.
Syndacehas joined
KevYou can replace any payloads, but not rewrite the logical-type of the stanza.
Ge0rGKev: rename the element to <message-edit/>
KevYou mean s/body-is-edit/message-edit/?
Nekithas left
Ge0rGKev: yes. or maybe message-is-edit
Ge0rGedited-message
Ge0rGBike shedding!
Dele (Mobile)has left
KevThese are details I feel don't need to be in a pseudo-exmaple.
Dele (Mobile)has joined
KevWhat's really relevant, I think, is that the LMC instruction lives within the attach-to.
KevAnd that references can also live within an attach-to, as can reactions.
Ge0rGAnd that we can have multiple attach-to elements with different payloads in one message!
ralphmWhy is that better than as a sibling (trying to get my head straight)
larmaI think having the message a sibbling of the attach-to but still put something inside the attach-to is semantically broken. Either the content of the attach-to is attached, or the sibblings, but this combination is just awkward
ralphmGe0rG: or we stop thinking we need multiple.
Ge0rGralphm: it makes processing for Smart MAM easier, because you don't need to analyze all the siblings and derive conclusions from their presence
Kevralphm: Clear hierachy. Sometimes you have 'extra noise' in stanzas, and it's much more convenient to be clear which bits apply where.
KevGe0rG: I don't yet understand the need for multiple attach-to in a single stanza.
KevAnd yes, what Ge0rG says about nesting, too.
Ge0rGKev: nobody does, but in a year we've codified that There Can Only Be One, and somebody comes up with a compelling use case that can't be implemented any more
Ge0rGKev: 0184 would have been so much better with multiple payloads
ralphmKev: ok. I'm asking because back in the day, Blaine thought we should have originally gone with allowing Atom payloads next to the pubsub event wrapper, so that you could interpret the notification even if you didn't understand pubsub.
flowGe0rG, I am not sure that this means that it can't be implemented any more
Ge0rGbut nobody came up with the use case of offline message mass-acking
KevSo SMAM would see an attach-to, and process its children (this is also a motivation for having the LMC body within attach-to, not external)
flowI sure would require a ns bump
Ge0rGflow: an ns bump and server-side conversion modules.
flowpoint is, it is easy to go from a exactly-once to one-or-more semantic, but not the other way around
flowor "easier"
Ge0rGflow: or clients adding multiple versions of attach-to elements with different semantics into one message.
KevI'm not sure I'd say it was 'easy', but 'easier', yes.
Ge0rGwith the proposed semantics, is there a reason NOT to have multiple attach-to in one message?
ralphmflow: well, since it moves into attach-to, you don't actually need to change the namespace for backwards compat. Of course older clients now see multiple messages, because they don't know attach-to
KevGe0rG: If everything is properly nested, no. But if we allow leakage outside the attach-to, kinda yes.
flowGe0rG: and if we ever go from a esactly-once to a one-or-more semantic, you can say "told you so"
ralphmflow: and then file bug reports for clients that only hanlde one
Ge0rG> point is, it is easy to go from a exactly-once to one-or-more semantic, but not the other way around
I think the opposite is true: if you have implemented parsing for N elements, and the message only may contain one, your code just works™
flow"feature requests"
KevI do find flow's argument about ease of switching fairly compelling, though. We could publish with one, and see if anyone has a counter-argument while it' sexperimental.
Nekithas joined
Ge0rGKev: "A receiving entity SHOULD be able to process multiple attach-to payloads"
zachhas left
zachhas joined
flowGe0rG, I don't see how parsing is the heavweight thing yo'd have to change here
KevGe0rG: That's the worst of all worlds, isn't it? :)
Ge0rGHey, I could edit all my messages to the same text with one message!
Ge0rGflow: not parsing but interpreting.
ralphm:headdesk:
ralphmThat's exactly what I want to prevent.
Ge0rGflow: `AttachTo message.getAttachToPayload()` vs. `List<AttachTo> message.getAttachToPayloads()`
flowimplementing interpreation of exactly-once is probably way easier than one-or-more
ralphmWe've removed batch stuff in several protocols, like pubsub.
larmaIf we have
Unencrypted: `<message to=room from=ralph id=4><attach-to id=3><reaction>👍🏻</reaction></attach-to></message>`
Encrypted: `<message to=room from=ralph id=4><attach-to id=3 /><ENCRYPTED><attach-to id=3><reaction>👍🏻</reaction></attach-to></ENCRYPTED></message>`
This confuses me a bit: Is attach-to now to be semantically understood to
a) attach sibbilings
b) the full message
c) the content of the attach-to element
Kevlarma: The content of the attach-to. Although in the case of LMC there's this open question about whether it's ok to referer out to the body or not.
Ge0rGlarma: what about <attach-to id=3><ENCRYPTED/></>
larmaGe0rG, that would be the logical consequence, but then this is going to be terrible with legacy fallbacks
pep.Kev: btw, nit (but not really), you don't need the "@" if you have References type mention.
Ge0rGralphm: the user's client should replace `@user` with `user` and a reference, then! :P
larmaGe0rG, how would you do if you attach multiple subblings?
ralphmGe0rG: if could
Ge0rGlarma: have multiple <external-sibling/> elements. Or just define the ns if they all share one
ralphmGe0rG: I meant 'it could'
Ge0rGralphm: I'm clearly thinking of the Slack UX here
ralphmGe0rG: Slack doesn't actually remove the @
wurstsalathas left
KevShowing the @ is fairly usual in modern clients, I think.
wurstsalathas joined
KevBut I don't think this is the most important of the discussed details :)
ralphmnah
ralphmI like how this is shaping up.
Ge0rGKev, ralphm: am I overengineering things with <external-sibling>?
ralphmGe0rG: yes
Ge0rGMuch?
ralphmyes
Ge0rGA more pragmatic alternative?
KevI don't know, honestly.
KevI don't entirely understand why it needs to be alongside rather than nested, yet.
Ge0rGI mean, the reference-tracking implications of that are really bad.
Ge0rGKev: the default would be nested
ralphmI think having an empty attach-id is fine. If the encrypted payload is unwrapped, it can override it.
KevWhen would you external it?
Ge0rGthe only real use-case I see is message edits with legacy.
Kevralphm: I think an empty attach-id is pointless. It doesn't allow the archive to do anything useful, and other recipients are able to decrypt.
Ge0rGKev: it allows the archive to group related messages
ralphmKev: this was discussed arelier
ralphmKev: so that you could still have a limited two-dimensional grouping in MAM, even though you don't know about the encrypted bits.
Ge0rGKev: a thin E2EE client still benefits from that grouping
KevGe0rG: I am seriously considering whether the best thing for legacy fallback might be to have <fallback/> inside the attach-to, and then clients will need to understand <attach-to/fallback> in order to show a fallback.
ralphmI.e. retrieve all the encrypted attachments in one go
Kevralphm: But you can't have any grouping if there's no id, can you?
Ge0rGKev: what would <fallback/> mean?
ralphmKev: I mean no payload
KevGe0rG: It'd be a plaintext that can be shown to the user if your client doesn't support that type of attachment.
KevSo you need your client to understand attach-to/fallback, but once it does it can render a fallback sensibly for any other attachment type.
ralphmKev: MAM can know that this thing belongs to 3, but the real thing is inside
Kevralphm: Yes, that seems arguably ok. That's not an empty id though :)
ralphmI didn't say empty id
Kev"I think having an empty attach-id is fine" :)
ralphmoh, I did
ralphmwhoops
KevIf you didn't mean an empty attach id there, I don't know what you meant :)
ralphmSee, now I need edit
KevBut yes, empty attach-to other than the id seems reasonable.
KevSuboptimal, but the best you can get if you want encrypted payloads.
larmaIs `<message id=A><body>First</body></message>`+`<message from=B><attach-to id=A><any-attachment /></attach-to></message>` then considered to be compacted to something like `<message id=A><body>First</body><attached from=B><any-attachment /></attached></message>` server-side? (the not so smart version of thin client MAM, the smart version would probably look into `<any-attachment />` and make some special handling for it)
Ge0rGlarma: could you please reformat your messages for the XML to begin at new lines, and maybe have some more structure?
KevI don't think it's compacted, no.
rionhas left
rionhas joined
ralphmWhat do you mean compacted?
larmaralphm, for the usecase of thin client MAM
larma(which seems to be the main use-case of all of this after all)
KevThe attach-to lives in its own right, linked to the first message, rather than replacing the message itself.
KevSo you'd be able to query the attachments of a message through SMAM.
ralphmlarma: the only optimization a MAM server should do in this dumber case, is to ensure that when you retrieve a message, you get the attachments, too.
KevBut, by default, when requesting through MAM you'd not get them.
KevWait, what? :)
Ge0rGralphm: also vice-versa? When you query for an attached message, to receive the original first?
ralphmlarma: for the slightly smarter interaction, you probably don't want to retrieve all the things. Like with reactions, I'd say we'd have an element with a summary of reactions that's returned when you receive a message from MAM, but you need to query for all the individual ones to show who sent them.
larmaralphm, OK makes sense to me, just want to ensure we are not missing the actual goal of all of this, as we already talked about over-engineering
ralphm(like in Slack, you only see the counts, until you hover over them)
Ge0rGbut that means you need to deliver a map(reaction -> count)
ralphmyes
larmaIf we don't have any special semantic meaning of the content of <attach-to> I'd say it is better to not actually put stuff in there and make it always a sibbling
KevI'm happyish to punt solving how you do the archive queries to later, as long as we're confident we're encoding enough in teh protocol that we /can/ solve it later.
KevI'm happyish to punt solving how you do the archive queries to later, as long as we're confident we're encoding enough in the protocol that we /can/ solve it later.
ralphmKev: oh, MAM is a going to be quite another topic, indeed
Kevlarma: I think we do have semantic meaning of the children of attach-to.
Ge0rGlarma: but we actually _want_ to have semantic meaning for the children
Ge0rGjust not generally.
Ge0rGthe two exceptions being E2EE and legacy Edits
pep.“ralphm: Slack doesn't actually remove the @”, then the other side can put it back, but this has nothing to do on the wire.
Kevpep.: And thus isn't worth discussing at the moment :)
pep.still trying to catch-up with what's been said in here
larma> but that means you need to deliver a map(reaction -> count)
Ge0rG, yes this implies that the SMAM server understands reactions, has special handling of it and doesn't make use of the generic attach-to feature (which is kind of funny as we are mostly talking about the generic feature for exactly that usecase)
Ge0rGlarma: oh, of course it would rely on the generic attach-to feature
KevSorry, why isn't SMAM using attach-to?
zachhas left
Ge0rGit would just make better use of it
zachhas joined
ralphmpep.: what I believe Slack does is always send the original thing (plaintext) and then updates to it to mark it up. On slow connections you can see this happening sometimes.
larmaKev, Ge0rG, If the server needs to be able to understand what reactions means in `<attach-to id=A><reactions /></attach-to>` it could also just understand what reactions means in `<reactions id=A />`
ajhas joined
KevBut it doesn't /need/ to understand what reactions mean, does it?
ralphmlarma: the idea is definitely that a MAM server with knowledge about attachments, will have a more efficient storage retrieval.
KevThere may be value in it doing so, but it doesn't fall apart if it doesn't.
ralphmRIght
larmaKev, If it wants to build a map(reaction -> count) as suggested by Ge0rG it needs to understand
KevYes. If it wants to be very smart, it can (and that is a good thing).
ralphmYes, it would be a discoverable feature.
KevBut a somewhat-less-smart option is also available.
Ge0rGlarma: yes; but when we introduce another kind of attached-to payload, SMAM will automatically provide the grouping for it, just without an improved summary
KevAnd it's already smart enough that it can know that it's a {ns}reaction child in the attach-to, so a client that doesn't support those won't bother retrieving them, even if the server doesn't do the mapping and summary.
larmaSo there is GMAM (grouped MAM) and SMAM (smart MAM). GMAM would rely on attach-to and SMAM would actually look into the reactions?
KevThere's a hierachy of smarts, yes, if you want to call them GMAM and SMAM.
KevSo SMAM is an improvement on GMAM is an improvement on MAM.
ralphmYou could have a way to say: give me all the messages (but without attachments), and then if it knows about reactions might include summaries. Then later you might retrieve the attachments.
KevDo I need to make another gist once I've thrown some lunch in the oven?
ralphmYes
ralphmDoing the same
ralphmHmm bapao
KevThis is very much not what I needed to get done today!
ralphmKev: yes you did. Your boss may complain to me.
ralphmAlso thank you
larmaI'd like to see an example of a message attachment being edited
Ge0rGspeaking of gists https://gist.github.com/ge0rg/a255cb521e45bbcb89573aa3218f0cd5
ralphmlarma: I don't really
Ge0rGis that a valid summary of today's discussion? ^
Kev"Can be sent by anyone" - unclear to me, more thought needed.
ralphmlarma: I'd rather see retraction and then a new one
Kev"wide consensus, except for Ge0rG" - I think I'd like to hear if anyone has an example where it's beneficial; I'm not dead-set against it.
Kev"i.e." - you mean "e.g." ;)
Kev"an without a payload" - missing some words, I think.
KevBut yes, I think that's pretty close to a summary, and is useful to capture, thanks Ge0rG.
larma> You could have a way to say: give me all the messages (but without attachments)
ralphm, but you'd actually want to also put some attachments directly, like message retraction, no?
KevI don't believe retraction should be an attachment.
KevBecause it has different semantics from attachments, for exactly this reason.
matkorhas left
ralphmIndeed. And retractions should be consolidated by the server
matkorhas joined
KevAh, are we talking about retracting an attach-to, or retracting a source message?
ralphmboth, I suppose
KevI think they're very different.
larmaKev, so you'd want always special handling for retraction, even in GMAM. Obviously makes sense in SMAM
larmaIn case of SCE, do we encrypt the retraction element?
ralphmKev: they are, but the protocol doesn't have to be
Kevralphm: Yes, it does :)
KevOr, rather, makes a lot of sense to be.
ralphmKev: why? You can retract the stanza. If the stanza is an source message, then everything goes. If the stanza is an attach-to, then its payload goes?
KevBecause I don't think that retracting attach-to by the id of the carrying stanza is entirely sensible.
ralphmwhy?
ralphm(is there a way for Gajim to show typing notifications in MUCs?)
KevSo I think it makes more sense to have
<message><attach-to><retract-message/></attach-to><message>
for retracting a source message, and
<message><attach-to type='remove'>describepayload</attach-to></message>
Nekithas left
larmaI agree that one shouldn't reference attach-to messages at all
KevI'm just thinking of the pain of implementing things in the server archive at the moment. This is all going to be moderately painful (desirable features, so pain we have to accept, but still painful), and I'd rather keep the pain as low as we can. I believe that different paths for removing attachments and for redacting messages is simpler.
Nekithas joined
ralphmI was thinking more about:
`<message><retract id='...'/></message>`
for both.
pep.Kev: on these channels, "the moment" is whenever somebody talks about it, so here it is. It's not relevant for this discussion but it's relevant nonetheless.
KevAnd I also believe that storing attachments as attachments is probably easier than storing them as messages.
ralphmKev: yeah, we talked about dimensions before, and I'm not sure yet what the MAM protocol should look like.
larmaKev, but often the message containing the attachment has relevant information, like the person that attached the message
pep.Also re reactions being "compressed", "I have a use-case" for wanting individual payloads that have been sent (that is, even for just one user, have all the intermediate payloads they've sent)
ralphmBut semantically, calling a retraction an attachment is a bit odd.
zachhas left
zachhas joined
larmaMatrix does the same IIRC 😀
Kevralphm: Yes, I would be happiest with just <message><retract...></>
Kevpep.: I don't think we're suggesting not storing them, just that it's most useful to present to a client as a summary usually.
ralphmpep.: didn't I say we would have the ability to retrieve all the things?
Kevlarma: Yes, there's some metadata involved.
KevWe did talk about all this at the summit, I wonder if any of it was captured in the minutes.
ralphmKev: if you'd be happier with my example, what is the problem with it then?
ralphmKev: the lookup?
KevYour example was to retract attach-to message wrappers in the same way as to retract messages, wasn't it?
KevI'm certainly not happier with that.
KevI'm happier when messages are retracted in one way, and attach-to retracted in another.
ralphmSo like we have retract item and delete node in pubsub?
adiaholichas left
KevSomewhat, yes.
ralphmI thought it might be easier to just say to undo a stanza being sent, but not a hill for me to die on
pep.ralphm: OK i right have misread
ralphmNo worries. Things were going FAST
Nekithas left
Nekithas joined
adiaholichas joined
zachhas left
zachhas joined
sonnyhas joined
pdurbinhas joined
pdurbinhas left
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
zachhas left
zachhas joined
Ge0rGSorry, I had to vanish into a call. Now that I'm back, the last hour of log doesn't make much sense to me.
MattJYou had to be there
Ge0rGYou want message retraction to explicitly use a different mechanism than Attach-To? What about Message Edits, should that stay Attach-To?
ZashWhich direction does the relation go?
Ge0rGZash: the new message references the old message
adiaholichas left
adiaholichas joined
pep.That doesn't specify the relation between the two though. Is there a case of a new message becoming the parent of an older one
ZashBut does the new message belong to the old message or the reverse?
adiaholichas left
adiaholichas joined
Ge0rGcan we leave the philosophical questions for later, please, and focus on the protocol?
zachhas left
zachhas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
nycohas joined
nycotest
waqashas joined
Guusa+
ralphm.
adiaholichas left
adiaholichas joined
SeveTest passed
Guuswe meet?
zachhas left
zachhas joined
nycoouch
MattJOh wow, it's Thursday again :/
GuusWelcome to my thoughts, 10 minutes ago.
Guus(only because I got a calendar reminder 😉 )
ralphm0. Welcome
ralphmHope everybody is reconnected, there was a strange disconnect with xmpp.org from here.
GuusI've seen everyone say something.
SeveHi
MattJwfm
ralphmyay
ralphm1. Minute taker
Guusassuming we can't find someone from the floor, I'll do 'm this time
ralphmThanks!
ralphm2. Badges
nycothx
ralphmI have reached out to mray. He responded and asked the following:
ralphm“I'd be interested in the kind of combinations that the system needs to
cover. Maybe you can break it down for me without the entire context of
XMPP compliance. Eventually even a complete set of possible combinations?”
ralphmWho can create such a list?
nycoother submissions did that, no?
Guuscombinations of what, exactly?
nycoeach requirements
SeveLevels of compliance I guess
ralphmAll combinations of thingies to appear in the badges
ralphmSo basically, he did 3 examples, and we now come up with all the combinations we'd like him to construct as actual badges
Guusfrom the XEP:
> This document defines Categories based on typical use cases (Core, Web, IM, Mobile) and Levels (Core, Advanced) based on functionality in the respective category.
Guusso, we need each combination of Category with Level, and add a year / edition to it?
GuusAlthough Core/Core 2019 seems weird.
nyco2019 would be cool
ralphmHe doesn't want to read the document, he just wants:
(XMPP LOGO) | CLIENT | Advanced ) IM | 2019
(XMPP LOGO) | SERVER | Advanced ) IM | 2019
etc.
adiaholichas left
adiaholichas joined
ralphmor somesuch
GuusI'll wrap up a list
ralphmThanks!
ralphmAlso thanks nyco fo sending the results out to the list.
SeveThank you guys
nycoin a spreadsheet?
ralphmmaybe
ralphm3. Roadmap
ralphmApart from this huge discussion this morning, afternoon, I haven't gotten to this.
ralphmGood progress on the former, though.
ralphm4. AOB
ralphm?
MattJNone here
GuusI've got two
SeveNone here
ralphmGuus: shoot
Guusisn't it about time we organize new elections?
nycoyou mean Boris Jonhson?
ralphmUsually Alex picks this up in September.
Guusack.
nycomissing id
nyco_has joined
ralphmNext Guus?
Guus2) I've been approached by https://openvoipalliance.org/ - they're interested in involving XMPP in this.
nycohas left
nycohas joined
Alexyes, elections are on my radar, have a reminder in my cal for Sept. 1st. Will open the application process after our current voting period
GuusI'd like to see if there's benefit for us in actively becoming a partner in that effort.
Guus(Thanks Alex)
ralphmGuus: interesting. I see they already use XMPP and converse.js
SeveI didn't know about it
ralphmBut yes, I'd be interested to know how they would like us to get involved.
ralphmGuus: can you send me the e-mail? I'd be happy to follow-up.
Guuswhat email? we're talking over XMPP. 🙂
nycohas left
ralphmoh hehe
SeveNiiice :)
adiaholichas left
adiaholichas joined
GuusI'll see if we can arrange for a groupchat of sorts
ralphmThanks
zachhas left
zachhas joined
ralphmAnything else?
GuusFIN
ralphm5. Date of Next
ralphm+1W
ralphm6. Close
MattJwfm
ralphmThanks all!
ralphmbangs gavel, and retroactively at the start of the meeting
SeveI really like this " You can chat with us through our XMPP server to see if your project fits." but would need to check exactly what it is and what can we do
SeveThank you for the meeting, glad to see all of you today
nycohas joined
nycothx all
adiaholichas left
adiaholichas joined
lumihas joined
nycomore glitches from the xmpp.org server?
ZashGlitches?
nycohas left
adiaholichas left
adiaholichas joined
matkorhas left
matkorhas joined
Guusralphm I've updated https://trello.com/c/J97CukTU/358-contact-mray-to-confirm-chosen-badge-design with the requested list of badge element combinations.
pep.Zash: ip6 issues apparently? Says Ge0rG
nycohas joined
Ge0rGThe connection hung. Looks like a kick against the tires helped.
XSF Discussion - 2019-08-29