jonaswyou know that I’m not fond of Ephemeral messages, but voting on it based on "it is NTP over XMPP" was incorrect I think. I was unable to find any NTPy thing in there, and the person who suggested that on the ML backed out of that claim.
jonaswalso, I’d like to see reasons for the other -1s
DaveWell, it's synchronizing timers and things. I'm basically not convinced of the security guarantees it's possible to offer around ephemeral messaging in general, and this seemed a particularly poor (and over complicated) rendition.
jonaswit’s not really synchronizing timers. all it does is saying "hey, your client should keep this message for at most N seconds"
jonaswthere’s no synchronization going on
KevThere's synchronisation of what you want the timers to be.
KevThere isn't synchronisation of the time.
KevAt least, given my reading.
KevBut given that I found it very hard to read and extract what it intended people to do, I think that's a fair reason to reject it at the moment.
jonaswI disagree. The ability to extract the intent from the text is (in this case, I think) mostly matter of language and structure, and thus editorial. That should not be reason to reject it from going to Experimental.
jonasw(as much as I dislike the thing)
flowwhat jonasw said
KevI'm happy for an Editor to try to clear it up so that it's possible to read it sensibly, but as things stand I can't judge the XEP properly because I can't understand what it's trying to do properly.
jonaswso we’re going to reject this based on lack of manpower in the editor team, essentially? ;-)
KevI'm fairly sure that once it's clear what it's trying to do it'll be clear that it would be rejected for technical reasons.
KevSo no, not really.
KevFrom what I can tell, it's got this overcomplicated and underspecified synchronisation protocol for the expiry values, which seems out of place here.
KevAs well as having this weird overlap between "This isn't for security, it's just for hinting" and "Here's all this extra work we're doing to try to guarantee security".
danieli see if i can find some time next week to come up with a protoxep that’s just the hint
jonaswthis might offend the authors of that XEP
jonaswdifferent question: would adding a note which hints to how things were done in the past (clearly marked up as "note" and "things in the past, but still around in some implementations") be editorial?
jonaswI’m "asking for a friend" who wants to add such a note to XEP-0045.
Kev"It depends" is I think the answer.
KevI'd normally expect editorial changes in a Draft XEP to be typos and grammar corrections and things.
jonaswgonna make a proper PR instead
jonaswthere you go: https://github.com/xsf/xeps/pull/664
Davejonasw, You can't possibly be arguing that a XEP that's too badly written for council to understand should be accepted, can you?
jonaswDave, when you put it that way it sounds horrible.
jonaswI don’t think though that it’s impossible to understand and that it can be fixed
DaveSo you're agreeing it can't be fixed, then? ;-)
jonaswlanugage is hard
jonaswit can be fixed I mean
DaveThe thing is, I don't believe one can design something that gives a message an expiry for security reasons in an open interoperable way. To get those guarantees, you need restrictions on the server and clients that are unprovable.
jonaswbut isn’t it worthwhile to have a common way to do this, even if it only makes sense in specialised deployments?
jonaswthat would reduce the setup/development cost for those deployments.
KevMaybe, yes, but I think most of what's in the XEP is trying and failing to get security guarantees it can't achieve.
danielDave: but arguably it is still valuable to have it standardized and then get library support so people who are using xmpp in closed environments (which I guess is the majority of people) have working solution ready
DaveI live in "specialised deployments", so I appreciate the sentiment. We hgave XEPs for adding classifications etc to messaging, for example. I'm all in favour of that. But those cases still provide guarantees outside of those environments. I'd be worried about the implication, so I'd want - from the outset - a clear scope on such a XEP.
KevBut I'm not convinced that /this/ document is the way we would choose to standardise it for closed environments either.
DaveKev, +1 there.
danielKev: no it's not
jonaswnow I wish those arguments make it into the council minutes
jonaswbecause having "it does NTP" as rejection reason there isn’t great
danielalso i think one has to use signal to understand what a timer setting update is
danielbecause i dont
danieli mean i get that you annotate each message with a burner. but why do you need to send updates?
danieland what does it update?
jonaswthe update is intended to make sure that the other side will use the new timer value on their next message
A and B have agreed on timer value X
A wants to use timer value Y, so sends timer update
B sends their next message with timer value Y
flowFWIW I assumed timer updates to sync all devices a a user
jonaswah, other devices of the same user, too
danielok. a) weirdly i have never been requested to implement this feature b) arguably it should use different syntax then
danielis this only signal that does this? where my contact can dictate the timeout message?
jonaswI really wonder what type of people use this feature.
jonasw(well, except people who really, truely need things like that)
danielthat seems a bit dangerous. so if i'm just in the process of sending a password or other delicate information my contact increases the time out from 60s to 5 years
pep.But this is not a security feature after all so I shouldn't really on this to hide a password right. Or is it still in the context of closed environments
jonaswI think the latter, pep.
KevThat's the confusion. It's both trying not to be a security document, and also trying to be a security document.
danielno it’s a just a hint; so in case of passwords it's like here i'm sending you information which you should copy paste into your password manager and then delete from the devices history
danieland arguably it is doing that job
daniel(speaking about burner messages in general now. not that particular xep)
pep.daniel, burner messages as in "marking messages as [sensitive/private]"?
danielno burner messages as in 'hey it's a good idea to delete that message after you mentally or (otherwise) processed that information
daniela friendly reminder between friends
daniela friendly reminder between friends is also what i'm going to call the XEP
danielso there wont be any confusion
pep.err, s/really/rely in a previous sentence
Davepep., Marking messages as sensitive/private is already covered by XEP-0258, incidentally.