ralphmjonas’: is that new XEP ephemeral itself, or is it just a broken link?
jonas’ralphm, thanks for pointing it out, I fixed it
jonas’(I had forgotten to actually deploy the new stuff to the server)
ralphmFWIW: I think that the concept of ephemeral messages, with all the caveats in the spec, is a mis-feature.
jonas’why do you think so?
moparisthebestI think it's stupid too but you know it's the next "one thing (tm)" that XMPP is missing
lovetoxi dont see this working ..
lovetoxwhats with the negotiation .. why?
moparisthebestit's ok all it needs to do is give people a false sense of security
lovetoxevery user should just choose when his messages going to be removed
moparisthebestsignal has it after all
lovetoxwhy negotiate something
mjklovetox: because any participant's message could incriminate any other participant (even without considering >quoting)
mjkThe falseness of security sense is up to client UI designers to dispell, I'd hope :)
mjkNo need to follow misleading ui of $super_recure_messenger
Dele Olajidehas joined
mjkpep.: some wording feedback, I guess... Better late than never, lol
> Provide a way to specify a timer value after which message contents must be deleted from user devices.
'Must' seems a bit too strong here, even not in all-caps. I think something along the lines of 'expected to be' or 'agreed to be' would convey the intention more precisely.
> A way to securely ensure that logs won’t be kept by parties included in chats.
I'd emphasize that _untrusted_ parties are meant here (iiuc)
pep.mjk, that non-binding must is clarified in the implementation notes
mjkOk, I'll take a look
pep.Or was it business rules
pep.« Discarded messages shall be removed from memory and disk on a best effort basis.
Timers do not have to be exactly exact, the definition of "seen" or "read" not being consistent, and clock issues might also be a thing (use NTP?). This is also a best effort basis. »
pep.As for your second comment, hmm.
pep.« § Security Considerations
Ephemeral messages are not to be considered "secure" in any way.
Even within well-meaning entities, requiring that messages be discarded and made impossible to retrieve, requires a lot more scrutiny in the specification and in implementations, and even then, is a really technically challenging task, to say the least. »
moparisthebestshould you mention annoying things like apps preventing screenshots from being taken of them etc ?
pep.I think that summarizes it
mjkYeah, so best effort. I just think it would be better to pre-iterate that in sect. 2, it being read one of the first
pep.moparisthebest, no it's exactly what I don't want this spec to be
moparisthebestI think that's what "the signal" does
pep.Read the security considerations
moparisthebestoh, well then that can be the next "one thing (tm)" preventing xmpp adoption
pep.Yeah I'm not worried about that, there's always something :)
pep.I guess I should put security considerations as the first section really.
pep.With a "I read and it's ok I'm willing to continue" before the rest shows up
mjkPut it in abstract!
Dele Olajidehas left
jonas’who reads *that*?
ralphmThe difference with Signal and WhatsApp are that they are controlled environments. And even then there are cases where a request to delete a message may fail to be honored. I really dislike the false sense of security it gives to the use. Federation, as with the open XMPP network makes this even less useful.✎
ralphmThe difference with Signal and WhatsApp are that they are controlled environments. And even then there are cases where a request to delete a message may fail to be honored. I really dislike the false sense of security it gives to the user. Federation, as with the open XMPP network makes this even less useful. ✏
ralphmBut sure it checks a box 🤷
jonas’is this the right place to point out that not all XMPP deployments are federated or with free choice of apps used?
Guusralphm: I don't fully agree. There is nothing that prevents you to use XMPP in a controlled environment.
Guuswe're on a roll today, jonas’
msavoritiasIsnt the "false sense of security" up to the client?
No user is gonna read the XEP.
So its up to the client to make it clear. And implement it or not.
I mean clients choose to implement or not XEP all the time. Plus there are a lot of XEPs that are tricky to implement due to the extensibility of the protocol like MIX or the new OMEMO. Doesnt mean its not worthwhile
Mjolnir Archonhas left
ralphmYes, iff you have a fully controlled environment, including the federation part, then yes it may work. I still think it is not great. Screenshots, photos of screens, etc.
jonas’right, but *that* is definitely outside the XSF' scope
jonas’so I'd say we go for a spec even if it never ends up in the compliance suites or somesuch because of the inherent issues with federation
ralphmI think it is much more useful to tell users: as soon as you hit enter, you can no longer trust that your message will not end up in places you don't want them.
jonas’I don't agree
ralphmBut having a single spec for the intent is better than everyone reinventing the wheel, badly.
ralphmI get what you're saying, but I have issues with so-called secure messaging systems. They generally fail to communicate the full picture. Whether something is secure depends on your threat model.
pep.Then again all I'm reading here is "I haven't read security considerations"
ralphmScroll back to my first message
pep."I still think it is not great. Screenshots, photos of screens, etc."
pep.Yeah but you're still talking about screenshots, and that's not related to this spec
ralphmIt is, people generally don't understand technology. If you present them with a feature that says that says 'delete for all users', or 'this message will self-destruct in 10 seconds', it makes a promise you can't keep.
pep.Anyway if this doesn't go through with the XSF, again, I'll host it somewhere else so that it can be implemented anyway because yes that's a feature people want so maybe someday we can answer the demand instead of staying in our little enterprisy world
ralphmMy context also includes vulnerable users. Like young teens.
ralphmpep.: I'm not objecting to the spec, I'm objecting to the feature. That's not on you. Again, having a spec for a feature I don't like is better than not.
pep.Sorry this wasn't really clear because it's been rejected for this exact reason before as well
mjkralphm: re. false sense if security. What sense of security is meant here, exactly? When you trust your contact and their opsec practices, trust the client software used by both of you and use verified-key e2e encryption, what remains to trust here? Security of secure deletion implementation? I think this is a (majoro point that should be conveyed clearly by client devs in the ui. Like, what exactly is the deletion impl.✎
mjkralphm: re. false sense if security. What sense of security is meant here, exactly? When you trust your contact and their opsec practices, trust the client software used by both of you and use verified-key e2e encryption, what remains to trust here? Security of secure deletion implementation? I think this is a (major) point that should be conveyed clearly by client devs in the ui. Like, what exactly is the deletion impl. ✏
pep.But anyway, I'm happy with the feature as it is now. I mean there,s lots of technical holes that I'd like filled, and I need feedback on this, but otherwise I'd be happy that progressively people stop logging stuff forever
pep.Maybe the issue is the name, because there are expectations from other messengers
Link Mauvemjk, a very common usecase is to think you can trust your contact but then it turns out they were the attacker all along.
pep.(Even though a client doesn't have to reuse this name obviously)
ralphmmjk: my PoV includes people that cannot make such determinations, because they are a-technical or don't have a developed pre-frontal cortex.
pep.Link Mauve, in this case it's not a technical problem it's a social problem and no amount of technicality is going to fix this
mjkLink Mauve: that shoud apply to communications in general, not deletion specifically :)
Link MauveYes to both.
Link MauveBut when you make automated deletion an advertised feature, people will tend to use it in cases where it is ill-suited.
pep."don't have a developed pre-frontal cortex" what
Link MauveThe usual nude that will be deleted ten seconds later, which then gets posted widely to the Internet.
mjkralphm: fair. :) A sufficient barrier to entry might mitigate this concern, like having to go install a plugin or enable a well-hidden feature...
pep.Link Mauve, where is it ill-suited to ask the other client to delete your nude? It's only unfortunate that the other client doesn't ""support"" it
pep.You may have done it anyway if deletion wasn't advertized
pep.Ask kids who use snapchat
Link MauveI only know dealers who use snapchat. ^^'
mjk"hey kid, wanna see some real free software?"
pep.Anyway, of course UX is important, and I'm not sure why I'm answering on security concerns here when the whole point of this spec is privacy. Have the client find a way to present it to the user as a non-security feature
pep.Even just to have all your clients follow the same logging policy I think it's worth it
Link MauveCouldn’t that be a PEP node which configures that, if you want to change the logging policy?
pep.I don't want to change just mine
Link MauveOr pretty much any policy which should be synchronised between clients.
mjk> Have the client find a way to present it to the user as a non-security feature
Like, e.g., Conversations does for years in file deletion modal dialog
lovetoxim on the side that XSF should not care about "Users"
pep.What does this mean exactly? Even though I don't think I agree whatever this means :P
lovetoxThe way should be
Users tells client dev wishes -> Client dev tells XSF protocol needs
lovetoxXSF is not here for Users, and is not there to shild and protected users from bad client devs
lovetoxotherwise you need to remove all XEPs ever
pep.It's not here to "shield users from bad client devs" no, whatever that means, but it's here to answer user's expectations. When something is wanted by users in the community, the XSF should probably get onto it
lovetoxUsers = Users of Clients
lovetoxno, sorry, they dont usually come here and tell what they want
pep.The XSF doesn't live in a vacuum
lovetoxthey create issues on client developer issue trackers
lovetoxUsers dont care about xml which is sent here and there
pep.Many users gravitate around here, and many people gravitating aroudn the XSF are devs and are able to report user expectations. And I think the XSF should hear this and react.
lovetoxno pep. there is handfull of users of thousands here in the chat
pep."and many people gravitating around the XSF [..] are able to report user expectations"
lovetoxcorrect, client / server devs report users expectations for features, and XSF makes protocol
pep.So we're saying the same thing?
pep.I do think the XSF should care about users. Of course users don't care about the ways it goes on the wire and that's fine
lovetoxthe job is to make a protocol, maybe write down common pitfalls and requirements
mjk> im on the side that XSF should not care about "Users"
If anything, I think this is rather an argument _for_ not against the advancement of the xep at hand :3
lovetoxbut not to say: Uh we are federated, im not sure 100% of devs implement this 100% secure
lovetoxso lets not even start to make a protocol
pep.lovetox, yeah but XEPs aren't made in vacuum either. They answer a demand
lovetoxyeah for sending xml over networks, not to make sure users are not mislead by clientand serve rdevelopers
pep.I don't understand what you're answering to here
lovetoxto the common answer about epheral messages: Uh but what if client X does not delete the message
pep.I guess I understand you're defending the spec? But it's still a weird position to me
lovetoxyeah its none of your business
lovetoxbecause what if servers store messages although user deactivated it in archiving preferences?
lovetoxwhat if server routes message wrong altough RFC says otherwise
lovetoxwhat if client does encryption wrong, altough XEP says otherwise
lovetoxlike i can make a million errors as developer
lovetoxfor none of them any one in the XSF would held be responsible
pep.Well again, no. The XSF isn't of course responsible of everything devs do, but it should ensure the document it produces are understandable and warn users about common pitfalls, as you said above. And if it's still not clear / hard to do, I'd say the XSF could point to example / reusable implementations
lovetoxyes, describe whatever is needed
pep.Great we agree about this. I still don't agree that the XSF shouldn't care about users. Of course it should. XEPs aren't written just to be pretty (at least I'm not hanging any framed on my walls), they're written to serve a purpose and answer users demand.
lovetoxwith care about users i meant, caring in a way parents care, "i will not publish this XEP because i fear you are not able to comprehend the implications"
lovetoxthe argument against this XEP is always the same, BUT what if one client does not respect the deletion wish"
lovetoxand i think its not really a useful argument
pep.Note that I'm not trying to argue against my own spec here. I think the spec AND the feature are fine as it is and it's possible to implement it in such a way that it's not misleading. PLUS, users are demanding such feature so it's about time we start doing something about it
moparisthebestAs council I'll pass the spec if it's sound from a technical perspective
moparisthebestAs moparisthebest I'm definitely publishing patches for all clients that implement this to claim to implement it but never actually delete anything >:)
ralphmpep.: the brains of kids till the age of 23 are not fully developed. This causes them to generally be unable to properly oversee the outcomes of their actions.
pep.ralphm, so we should be good parents and prevent them from using their phone? instead of telling them it has to be used with caution?
SamYes, children should not have phones.
moparisthebestAnd teach them that once you send anything over the internet there is no pulling it back
pep.What have I started
pep.Ok so I guess we should also remove old people's phones because they don't know how to use them
ralphmpep.: I don't know if you have kids yourself or in your extended family, but yes this is a difficult trade-off.
pep.And maybe we should also remove poor people's phones because they've got less time to fiddle with them and they are less used to them, they're not getting much training
moparisthebestIf you don't know how to use something you should indeed not use it
pep.moparisthebest, I disagree
pep.You should be able to receive proper training
moparisthebestAbsolutely, gotta take the initiative and time to learn though
mjk"don't let kids into the internet, they make it dumb!"
pep.moparisthebest, I agree it's really hard nowadays when all we're doing is work in bs jobs..
emusFolks, is fine to review user expierence but I dont think such a meta discussion helps this topic
emusInternet has many bad ibfluences to people. lets stop with real-time communciation?
pep.emus, yeah definitely, way to go :)
moparisthebestI don't think anyone said that, my point was simply that people should understand the tools they use, it's dangerous not to
pep.I think people should be given the chance to learn the tools they use, rather. I prefer this wording because yours dangerously makes me think that you'd want to limit people who have access to these tools
moparisthebestNope I fully agree with you
moparisthebestEncourage them to learn their tools even
emusI tend to think the same
mjkAnd we're back to good (=educational) UI :)
pep.That's prerequisite yeah (though my comment was a lot more general about society :P)
ralphmI think it is very useful to discuss these things in this forum. And yes, the world isn't perfect. I personally have tried to teach my teen daughter about the dangers of putting information out there, e.g. on Instagram, Snapchat, etc. She generally understands, but also it is very hard, if not impossible, to make the 'right' judgement calls. Besides lacking the part of their brain responsible for such choices, there are also things like peer pressure and what is considered 'normal'. So she will get it wrong sometimes and I just hope that it'll work out reasonably well.
That all said, this doesn't mean that we should just throw up our hands and blindly implement things. Having an opinion on whether a feature is the right thing to do, is just ok. And we can disagree. But the discussion itself is useful.
emusI missed the beginning. but as there is a proto-xep people can implement it regardless of our discussion right?
ralphmThe great thing about XMPP is that yes you can generally do what you want
pep.There is a protoxep. People can't implement it just yet because it's not technically complete and I was hoping for this step to get feedback, because I haven't managed to get technical feedback on this before.
emusmoparisthebest: yes I know the xep, but thanns
pep.(That is, I actually got feedback nowhere.)
moparisthebestpep.: Technical wise I'm not sure the reason for https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html#example-3
ralphmSorry I didn't really get into the protocol itself. I hope you can appreciate my input anyway.
moparisthebestOr the "they will expire in X from now on" language
emusthx, but gn8
moparisthebestShouldn't each message just have it's own individual timer and that's it?
pep.moparisthebest, it's to reflect changes when there's an action in the UI. userX configures it as timeX and userY sends new message with timeX
moparisthebestAlso makes the strange <i-want-out/> thing go away, but I might be missing a reason?
moparisthebestThe time is per message though? Shouldn't each message just have a timer?
pep.i-want-out is because I have no clue how to do, see the TODO
moparisthebestImho get rid of all that and simply send an "expires after" per message?
pep.Getting rid of the negociation is kinda changing the idea of the spec isn't it
pep.I want to implicate users around me when I do this
pep.I'm not doing this in isolation. I don't just want my messages to be erased, I want my circles to also benefit from this
moparisthebestUnclear what you mean
pep.hmm, which part
moparisthebestWhat are you missing simply by saying "please delete this message after X" sent per message?
pep.Is it still about the implicit timer thing?
moparisthebestAnd, maybe something in disco hinting they might do it
moparisthebestYea that part is confusing to me, seems needlessly complicated
pep.Ok remove the implicit timer thing, I feel there's something more that bothers you but I'm not sure what
pep.Is it not clear why I need a way to opt-out (once I've opted-in)
moparisthebestI'm saying don't have a way to opt in or out
moparisthebestJust a TTL per message only
pep.Maybe you're missing the point of the spec?
pep.Or maybe you're right but I don't see it
pep."This specification encourages a shift in privacy settings wrt. logging policies."
moparisthebestI might be that's what I'm asking
pep.I'm not aiming at this being just an isolated user wanting their messages deleted
moparisthebestWait is the TTL not actually per message but modifies a per conversation setting?
pep.Yeah the TTL isn't per-message, it's per-"chat"
moparisthebestThat sounds like it should be in pep then no?
pep.Not sure how to call that
pep.of the two person in 1:1
moparisthebestLike a public user setting for their contacts?
pep.And if they're not in my contacts
pep.and in MUC?
moparisthebestPlease delete all my messages after X
pep.Read the spec, this question is already in there
moparisthebestThis can't even work in a muc
moparisthebestAt least not a public one
pep.If not I'll make it work
pep.That's a social issue
pep.technically it works
moparisthebestBecause you are pep. Now doesn't mean the pep. Who sends the next message is you
moparisthebestWhat about instead of all this complicated state management you simply send a TTL per message?
moparisthebestSeems like the same result, and servers could expire from mam, and you don't need to figure out opting out and all that?
pep.Well I'm doing this, but not really. The negociation is so that all participating clients behave the same way (if possible)
pep.Imagine I don't negociate and only I send the TTL. Does that mean I'm going to delete messages I receive from the other as well because I care? What about messages that the other sends that's logged on their device?
moparisthebestI mean keep the disco feature, but then simply send a TTL per message
pep.So the disco feature would mean what
moparisthebestIf they send a TTL then you delete it, if not, your choice
moparisthebestdisco is just a pinky promise that you intend to honor the TTL on this client
pep."moparisthebest> If they send a TTL then you delete it, if not, your choice" yeah and that's not the spirit of the spec
moparisthebestI don't understand how that changes anything
pep.I want this to be a timer for the conversation (on all participating-and-implementing devices), not for one message
moparisthebestThat seems overcomplicated with no use cases not covered by per message TTL ?
pep.Basically what I hear when you say this is that user will have to go enable the thing themselves
pep.They'll have to somehow learn about the thing and enable it maybe. Basically only nerds will enable it
moparisthebestIt can be a default, or you can suggest the client sets the TTL for their outgoing messages to the first one received?
pep.Whereas if all participants in a chat agree on it, that's all the more people that are made aware of it (dialog or status message or whatever)
pep.I have to admit I'm also not clear on why it's best as a per-chat thing, but I think there's an important difference
moparisthebestTo me this reads like a complicated state machine where you have to read all messages in order to figure out when to delete each message
moparisthebestConsidering sometimes you read mam backwards or have holes, that seems bad
moparisthebestWhere as a per message TTL gives you the same experience but is stateless
pep.I agree that does complicate things but it's also not the same goal.
pep.And if there's a way to answer this technically I'd be happy to know
moparisthebestYou can keep the same goal with a per message TTL though right?
pep.Well I'm not sure no
moparisthebestI *think* I understand your goal now anyway, I didn't initially
moparisthebestBasically keep the spec the same, but you don't store/calculate TTL seperately from the messages
pep.Tbh if there could be like, one PEP node negociated for the current chat, that might make things a lot easier..
moparisthebestYou can still use the last messages TTL to show the user and send in your next message etc
pep."You can still use the last messages TTL to show the user and send in your next message etc" well in practice that's what happens
Mjolnir Archonhas joined
moparisthebestThe difference being you don't need to replay all history in order to calculate current TTL, only look at the last message
pep.You don't "calculate" the TTL, it IS sent with every message
pep.ATM it is yes
mjkgoes re-reading the xml
pep.Anyway.. This protoxep is less of a "hey I know what I'm doing I exactly want this" it's more "I have these goals, how do I achieve them plz"
pep.And I didn't find a way to get feedback before the protoxep so here it is..
moparisthebestWhat do you do if you send me a message with the ephemeral tag and I respond without one?
pep.If you don't implement the feature then so be it. Otherwise you should send the same back
pep.And "so be it" if you don't do it anyway
pep.I can't control your client
moparisthebestI mean, is that your cancel mechanism?
moparisthebest"Well they don't want me deleting their messages now" ?
pep.That's where I'm stuck :/
pep.How do I opt-out once I've opted-in
moparisthebestI'd vote either that or a TTL of 0
moparisthebestBut if code has to handle both the same don't bother with both
pep.Because any non-implementing client would make me stop the TTL
pep.When MAM and stuff
pep.So there needs to be a <thing/>
pep.And it needs to be seen.
mjkif one of your contact's clients doesn't implement the xep, you shouldn't treat no-ttl as i-want-out, so zero ttl sounds sane
pep.ttl=0 seems like a hack, but yeah that's the idea of the <i-want-out/>
moparisthebestShouldn't non implementing clients make you stop though?
pep.Maybe @timer should be Option<u32>
moparisthebestI mean UI should indicate the other client won't listen anymore
pep.moparisthebest, no, same problem as usual
moparisthebestI don't think 0 is a hack, a real TTL of 0 makes no sense
pep.Non-implementing clients shouldn't make anybody stop from using specific features because MAM and the like
pep.But that's annoying I get it
mjka hack in the sense it's a sum type? like option<u32>
moparisthebestIf you expect your messages to me to be deleted and I suddenly tell you I won't, you certainly shouldn't keep sending assuming I will
pep.moparisthebest, so we started chatting both with supporting clients, we agree on a ttl, you've switched clients for 2 messages and it doesn't support the spec, you afk but I keep sending you messages. What should I do?
pep.Do I stop sending you ttl'd messages?
pep.Do I send two different messages to your fulljids? :P
mjkalso, with mam, any non-implementing client can retrieve later and store forever. that's always a possibility
pep.Yeah, any client you own I don't know about can read these messages. So I'd rather wait for an explicit "nope" than something that can be misunderstood for "I don't implement it"
moparisthebestpep.: Yea you stop sending them if you need them deleted
moparisthebestIn your example in the xep they'd respond like "hey you switched to a client that won't keep this private can you switch back?"
This specification encourages a shift in privacy settings wrt. logging policies."
pep.It's fine if a message isn't deleted
moparisthebestSame as when you are having an OMEMO conversation with someone and they suddenly send a few unencrypted
pep.This isn't a security spec
moparisthebestIf you aren't trying this spec is useless
moparisthebestThis isn't even some strange edge case, it needs covered
pep.No because there's no way I know about clients you haven't even told me yet that are going to have access to MAM
pep.And I'm not going the way "then don't store in MAM"
pep.Because I want clients to still be usable
pep.fwiw that's what the old version was doing
moparisthebestYou can't because then you are back to not working on iOS
mjk> In your example in the xep they'd respond like "hey you switched to a client that won't keep this private can you switch back?"
I agree that this would be in line with 'best effort' nature of the spec
pep.This isn't technically possible
pep.Or it is but you're willing to go to lengths this spec isn't, because it's not the goal
mjki mean, it's up to implementation to notice and warn the user
moparisthebestIf you wanted to try real hard you'd require encryption and sign the promise with keys and only encrypt to keys that promised ?
pep.Yeah but I'm not doing that
pep.I just want to change the default storing policies in clients but no implementation will follow me because for some reason I can't understand they all like their logs
moparisthebestmjk: yes exactly, and I think the implementation then has to show the same warning for "I opt out" and "they aren't sending it anymore" no pep. ?
pep.(I also do have logs on my poezio and I don't understand why, it's useful sometimes, ok, but not really important)
moparisthebestYou can continue sending ephemeral in your messages of course
moparisthebestpep.: I have the solution for that
pep."If this includes sending to non-supporting clients, and they can be detected, sending clients SHOULD warn the user in some way. Clients MAY warn users anyway if non-supporting clients cannot be detected (e.g., when they don’t get a directed presence)."
pep.In the spec ^
moparisthebestI have my conversations set to delete all messages older than a week, not because I want to, but because the database is too slow with too many messages lol
pep.Maybe I should change that to "You never know what new client is going to have access to MAM so you should warn anyway."
moparisthebestpep.: right so then how does "I opt out" differ from "I have a different client that won't do it" if you show the same message to the user?
moparisthebestI don't think it does, therefore not getting it should be your opt out message
pep.When a client says "I opt out", the receiving client can show a status message or something
pep."TTL has be removed"
moparisthebestIt should show the same if they switched to a different client?
pep.Show the same what?
pep.TTL hasn't be removed for a non-supporting client, it was never supported
moparisthebestThe result is the same
pep.The result is the same, but I'd warn in different places
moparisthebestIn both cases they know their contact won't delete the messages
pep.The non-supporting client might have been listening all along and that's fine
pep.Because they've been told when activating the feature
mjk> "If this includes sending to non-supporting clients, and they can be detected, sending clients SHOULD warn the user in some way. Clients MAY warn users anyway if non-supporting clients cannot be detected (e.g., when they don’t get a directed presence)."
> In the spec ^
okay, I admit I don't usually read through the entire discussion subject :D
moparisthebestThen I'm back to why have an opt out at all
moparisthebestIf you aren't going to show any special warnings
pep.I just told you I would
moparisthebest> Because they've been told when activating the feature
moparisthebestYou said one warning at the beginning is all?
pep.> When a client says "I opt out", the receiving client can show a status message or something
pep.> "TTL has be removed"
moparisthebestAnd it should show the same when receiving no TTL at all...
pep.Well I don't think so
moparisthebestIt's the same effect
pep.In one case the user has been warned that there might be non-supporting devices receiving this. In the other case a client has explicitely asked for the feature to stop. Yes in both cases messages won't be deleted, but no it's not the same thing
mjk> it's not the same thing
because there's probably a conscious human decision behind the latter
moparisthebestMaybe they explicitly switched to the unsupporting client?
moparisthebestI don't think they have a meaningful distinction
pep.Maybe they did, and maybe they'll tell the sending client to stop, like in human speech
pep.That's a thing also :P
pep.Whether the client wants to merge UI for this is ok, but protocol-wise I'll keep that different
mjktoo sleepy for consciou human anything
pep.It'd still be weird to me that these two are merged
moparisthebestI think it's dangerous to allow them to handle it differently
moparisthebestBecause inevitably someone will, and that'll be wrong
pep.Well say we handle them the same way
pep.That means while not everybody implements it, we can't use the feature✎
pep.That means as long as not everybody implements it, we can't use the feature ✏
moparisthebestThis is introducing a nullable Boolean into the spec
moparisthebestAnd saying "treat null the same as false"
moparisthebestInstead of just making it non nullable
pep.Yeah no sorry I don't want to live in a maybe monad
moparisthebest> That means as long as not everybody implements it, we can't use the feature
I'm not following
moparisthebestThe client behaves the same either way
pep.If every time you switch devices my client stops sending the TTL, I'm gonna have to reenable it when I know you're on a supporting client. That looks like a pretty shitty user experience to me
pep.I'm probably stop using it before I even start✎
pep.I'll probably stop using it before I even start ✏
pep.As I said this spec isn't a security spec
moparisthebest> If every time you switch devices my client stops sending the TTL, I'm gonna have to reenable it when I know you're on a supporting client.
Don't do that! Keep sending it
pep.Ok I didn't get what you mean then
moparisthebestLike you said mam and other clients might come back online etc
pep.So what changes
pep.Both clients might have been listening all the time. Because suddenly you decide from one shouldn't change anything to me✎
pep.Both clients might have been listening all the time. Because suddenly you decide to write from the other shouldn't change anything to me ✏
moparisthebestRight, other than you warn the user that they won't be deleting them now
pep.Both clients were listening from the start
pep.The sending user has been warned already
pep.Ah, the receiving client may not delete these messages though.. because they don't include the TTL.
pep.Is that another issue or is it what you were pointing at for all this time