XSF Discussion - 2022-04-26


  1. ralphm

    jonas’: is that new XEP ephemeral itself, or is it just a broken link?

  2. jonas’

    ralphm, thanks for pointing it out, I fixed it

  3. jonas’

    (I had forgotten to actually deploy the new stuff to the server)

  4. ralphm

    😉

  5. ralphm

    FWIW: I think that the concept of ephemeral messages, with all the caveats in the spec, is a mis-feature.

  6. jonas’

    why do you think so?

  7. moparisthebest

    I think it's stupid too but you know it's the next "one thing (tm)" that XMPP is missing

  8. lovetox

    i dont see this working ..

  9. lovetox

    whats with the negotiation .. why?

  10. moparisthebest

    it's ok all it needs to do is give people a false sense of security

  11. lovetox

    every user should just choose when his messages going to be removed

  12. moparisthebest

    signal has it after all

  13. lovetox

    why negotiate something

  14. mjk

    lovetox: because any participant's message could incriminate any other participant (even without considering >quoting)

  15. mjk

    The falseness of security sense is up to client UI designers to dispell, I'd hope :)

  16. mjk

    No need to follow misleading ui of $super_recure_messenger

  17. mjk

    pep.: 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)

  18. pep.

    mjk, that non-binding must is clarified in the implementation notes

  19. mjk

    Ok, I'll take a look

  20. pep.

    Or was it business rules

  21. 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. »

  22. pep.

    As for your second comment, hmm.

  23. 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. »

  24. moparisthebest

    should you mention annoying things like apps preventing screenshots from being taken of them etc ?

  25. pep.

    I think that summarizes it

  26. mjk

    Yeah, so best effort. I just think it would be better to pre-iterate that in sect. 2, it being read one of the first

  27. pep.

    moparisthebest, no it's exactly what I don't want this spec to be

  28. moparisthebest

    I think that's what "the signal" does

  29. pep.

    Read the security considerations

  30. moparisthebest

    oh, well then that can be the next "one thing (tm)" preventing xmpp adoption

  31. pep.

    Yeah I'm not worried about that, there's always something :)

  32. pep.

    I guess I should put security considerations as the first section really.

  33. mjk

    :d

  34. mjk

    :D

  35. pep.

    With a "I read and it's ok I'm willing to continue" before the rest shows up

  36. mjk

    Put it in abstract!

  37. jonas’

    who reads *that*?

  38. ralphm

    The 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.

  39. ralphm

    The 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.

  40. ralphm

    But sure it checks a box 🤷

  41. jonas’

    is this the right place to point out that not all XMPP deployments are federated or with free choice of apps used?

  42. Guus

    ralphm: I don't fully agree. There is nothing that prevents you to use XMPP in a controlled environment.

  43. jonas’

    ^5 Guus

  44. Guus

    we're on a roll today, jonas’

  45. msavoritias

    Isnt 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

  46. ralphm

    Yes, 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.

  47. jonas’

    right, but *that* is definitely outside the XSF' scope

  48. jonas’

    (screenshots etc.)

  49. 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

  50. ralphm

    I 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.

  51. jonas’

    I don't agree

  52. ralphm

    But having a single spec for the intent is better than everyone reinventing the wheel, badly.

  53. ralphm

    I 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.

  54. pep.

    Then again all I'm reading here is "I haven't read security considerations"

  55. ralphm

    Scroll back to my first message

  56. pep.

    "I still think it is not great. Screenshots, photos of screens, etc."

  57. pep.

    :/

  58. ralphm

    (19:18 UTC)

  59. pep.

    Yeah but you're still talking about screenshots, and that's not related to this spec

  60. ralphm

    It 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.

  61. 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

  62. ralphm

    My context also includes vulnerable users. Like young teens.

  63. ralphm

    pep.: 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.

  64. pep.

    Sorry this wasn't really clear because it's been rejected for this exact reason before as well

  65. mjk

    ralphm: 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.

  66. mjk

    ralphm: 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.

  67. 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

  68. pep.

    Maybe the issue is the name, because there are expectations from other messengers

  69. Link Mauve

    mjk, a very common usecase is to think you can trust your contact but then it turns out they were the attacker all along.

  70. pep.

    (Even though a client doesn't have to reuse this name obviously)

  71. ralphm

    mjk: my PoV includes people that cannot make such determinations, because they are a-technical or don't have a developed pre-frontal cortex.

  72. 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

  73. mjk

    Link Mauve: that shoud apply to communications in general, not deletion specifically :)

  74. Link Mauve

    Yes to both.

  75. Link Mauve

    But when you make automated deletion an advertised feature, people will tend to use it in cases where it is ill-suited.

  76. pep.

    "don't have a developed pre-frontal cortex" what

  77. Link Mauve

    The usual nude that will be deleted ten seconds later, which then gets posted widely to the Internet.

  78. mjk

    ralphm: fair. :) A sufficient barrier to entry might mitigate this concern, like having to go install a plugin or enable a well-hidden feature...

  79. 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

  80. pep.

    You may have done it anyway if deletion wasn't advertized

  81. pep.

    Ask kids who use snapchat

  82. Link Mauve

    I only know dealers who use snapchat. ^^'

  83. mjk

    "hey kid, wanna see some real free software?"

  84. 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

  85. pep.

    Even just to have all your clients follow the same logging policy I think it's worth it

  86. Link Mauve

    Couldn’t that be a PEP node which configures that, if you want to change the logging policy?

  87. pep.

    I don't want to change just mine

  88. Link Mauve

    Or pretty much any policy which should be synchronised between clients.

  89. 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

  90. lovetox

    im on the side that XSF should not care about "Users"

  91. pep.

    What does this mean exactly? Even though I don't think I agree whatever this means :P

  92. lovetox

    The way should be Users tells client dev wishes -> Client dev tells XSF protocol needs

  93. lovetox

    XSF is not here for Users, and is not there to shild and protected users from bad client devs

  94. lovetox

    otherwise you need to remove all XEPs ever

  95. 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

  96. lovetox

    Users = Users of Clients

  97. pep.

    Sure

  98. lovetox

    no, sorry, they dont usually come here and tell what they want

  99. pep.

    The XSF doesn't live in a vacuum

  100. lovetox

    they create issues on client developer issue trackers

  101. lovetox

    Users dont care about xml which is sent here and there

  102. 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.

  103. lovetox

    no pep. there is handfull of users of thousands here in the chat

  104. pep.

    "and many people gravitating around the XSF [..] are able to report user expectations"

  105. lovetox

    correct, client / server devs report users expectations for features, and XSF makes protocol

  106. pep.

    So we're saying the same thing?

  107. 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

  108. lovetox

    the job is to make a protocol, maybe write down common pitfalls and requirements

  109. 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

  110. lovetox

    but not to say: Uh we are federated, im not sure 100% of devs implement this 100% secure

  111. lovetox

    so lets not even start to make a protocol

  112. pep.

    lovetox, yeah but XEPs aren't made in vacuum either. They answer a demand

  113. lovetox

    yeah for sending xml over networks, not to make sure users are not mislead by clientand serve rdevelopers

  114. pep.

    I don't understand what you're answering to here

  115. lovetox

    to the common answer about epheral messages: Uh but what if client X does not delete the message

  116. pep.

    I guess I understand you're defending the spec? But it's still a weird position to me

  117. lovetox

    yeah its none of your business

  118. lovetox

    *XSF

  119. lovetox

    because what if servers store messages although user deactivated it in archiving preferences?

  120. lovetox

    what if server routes message wrong altough RFC says otherwise

  121. lovetox

    what if client does encryption wrong, altough XEP says otherwise

  122. lovetox

    like i can make a million errors as developer

  123. lovetox

    for none of them any one in the XSF would held be responsible

  124. 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

  125. lovetox

    yes, describe whatever is needed

  126. 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.

  127. lovetox

    with 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"

  128. lovetox

    the argument against this XEP is always the same, BUT what if one client does not respect the deletion wish"

  129. lovetox

    and i think its not really a useful argument

  130. 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

  131. mjk

    well said

  132. moparisthebest

    As council I'll pass the spec if it's sound from a technical perspective

  133. moparisthebest

    As moparisthebest I'm definitely publishing patches for all clients that implement this to claim to implement it but never actually delete anything >:)

  134. ralphm

    pep.: 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.

  135. 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?

  136. moparisthebest

    pep.: correct

  137. pep.

    ..

  138. Sam

    Yes, children should not have phones.

  139. moparisthebest

    And teach them that once you send anything over the internet there is no pulling it back

  140. pep.

    What have I started

  141. pep.

    Ok so I guess we should also remove old people's phones because they don't know how to use them

  142. ralphm

    pep.: I don't know if you have kids yourself or in your extended family, but yes this is a difficult trade-off.

  143. 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

  144. pep.

    What else

  145. moparisthebest

    If you don't know how to use something you should indeed not use it

  146. pep.

    moparisthebest, I disagree

  147. pep.

    You should be able to receive proper training

  148. moparisthebest

    Absolutely, gotta take the initiative and time to learn though

  149. mjk

    "don't let kids into the internet, they make it dumb!"

  150. mjk

    (-er)

  151. pep.

    moparisthebest, I agree it's really hard nowadays when all we're doing is work in bs jobs..

  152. emus

    Folks, is fine to review user expierence but I dont think such a meta discussion helps this topic

  153. emus

    Internet has many bad ibfluences to people. lets stop with real-time communciation?

  154. ralphm

    Disagree

  155. pep.

    emus, yeah definitely, way to go :)

  156. emus

    ^^

  157. moparisthebest

    I don't think anyone said that, my point was simply that people should understand the tools they use, it's dangerous not to

  158. 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

  159. moparisthebest

    Nope I fully agree with you

  160. moparisthebest

    Encourage them to learn their tools even

  161. emus

    I tend to think the same

  162. mjk

    And we're back to good (=educational) UI :)

  163. pep.

    That's prerequisite yeah (though my comment was a lot more general about society :P)

  164. ralphm

    I 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.

  165. emus

    I missed the beginning. but as there is a proto-xep people can implement it regardless of our discussion right?

  166. moparisthebest

    emus: https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html

  167. ralphm

    The great thing about XMPP is that yes you can generally do what you want

  168. 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.

  169. emus

    moparisthebest: yes I know the xep, but thanns

  170. emus

    pep.: ok

  171. pep.

    (That is, I actually got feedback nowhere.)

  172. moparisthebest

    pep.: Technical wise I'm not sure the reason for https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html#example-3

  173. emus

    understood

  174. ralphm

    Sorry I didn't really get into the protocol itself. I hope you can appreciate my input anyway.

  175. moparisthebest

    Or the "they will expire in X from now on" language

  176. emus

    thx, but gn8

  177. moparisthebest

    Shouldn't each message just have it's own individual timer and that's it?

  178. 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

  179. moparisthebest

    Also makes the strange <i-want-out/> thing go away, but I might be missing a reason?

  180. moparisthebest

    The time is per message though? Shouldn't each message just have a timer?

  181. pep.

    i-want-out is because I have no clue how to do, see the TODO

  182. pep.

    Please help.

  183. moparisthebest

    Imho get rid of all that and simply send an "expires after" per message?

  184. pep.

    Getting rid of the negociation is kinda changing the idea of the spec isn't it

  185. pep.

    I want to implicate users around me when I do this

  186. 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

  187. moparisthebest

    Unclear what you mean

  188. pep.

    hmm, which part

  189. moparisthebest

    What are you missing simply by saying "please delete this message after X" sent per message?

  190. pep.

    Is it still about the implicit timer thing?

  191. moparisthebest

    And, maybe something in disco hinting they might do it

  192. moparisthebest

    Yea that part is confusing to me, seems needlessly complicated

  193. pep.

    Ok remove the implicit timer thing, I feel there's something more that bothers you but I'm not sure what

  194. pep.

    Is it not clear why I need a way to opt-out (once I've opted-in)

  195. moparisthebest

    I'm saying don't have a way to opt in or out

  196. moparisthebest

    Just a TTL per message only

  197. pep.

    Maybe you're missing the point of the spec?

  198. pep.

    (naively asking)

  199. pep.

    Or maybe you're right but I don't see it

  200. pep.

    "This specification encourages a shift in privacy settings wrt. logging policies."

  201. moparisthebest

    I might be that's what I'm asking

  202. pep.

    I'm not aiming at this being just an isolated user wanting their messages deleted

  203. moparisthebest

    Wait is the TTL not actually per message but modifies a per conversation setting?

  204. pep.

    Yeah the TTL isn't per-message, it's per-"chat"

  205. pep.

    Well, "per-chat-from-now-on"

  206. moparisthebest

    That sounds like it should be in pep then no?

  207. pep.

    Not sure how to call that

  208. pep.

    Which PEP?

  209. pep.

    of the two person in 1:1

  210. moparisthebest

    Like a public user setting for their contacts?

  211. pep.

    And if they're not in my contacts

  212. pep.

    and in MUC?

  213. moparisthebest

    Please delete all my messages after X

  214. pep.

    Read the spec, this question is already in there

  215. moparisthebest

    This can't even work in a muc

  216. pep.

    why not

  217. moparisthebest

    At least not a public one

  218. pep.

    If not I'll make it work

  219. pep.

    That's a social issue

  220. pep.

    technically it works

  221. moparisthebest

    Because you are pep. Now doesn't mean the pep. Who sends the next message is you

  222. pep.

    I'm not sure where you're getting at

  223. pep.

    I'm not sure what you're getting at

  224. moparisthebest

    I don't have your jid

  225. pep.

    Why is that needed

  226. moparisthebest

    What about instead of all this complicated state management you simply send a TTL per message?

  227. moparisthebest

    Seems like the same result, and servers could expire from mam, and you don't need to figure out opting out and all that?

  228. pep.

    Well I'm doing this, but not really. The negociation is so that all participating clients behave the same way (if possible)

  229. 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?

  230. moparisthebest

    I mean keep the disco feature, but then simply send a TTL per message

  231. pep.

    So the disco feature would mean what

  232. moparisthebest

    If they send a TTL then you delete it, if not, your choice

  233. moparisthebest

    disco is just a pinky promise that you intend to honor the TTL on this client

  234. 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

  235. moparisthebest

    I don't understand how that changes anything

  236. pep.

    I want this to be a timer for the conversation (on all participating-and-implementing devices), not for one message

  237. moparisthebest

    That seems overcomplicated with no use cases not covered by per message TTL ?

  238. pep.

    Basically what I hear when you say this is that user will have to go enable the thing themselves

  239. pep.

    I mean,

  240. pep.

    They'll have to somehow learn about the thing and enable it maybe. Basically only nerds will enable it

  241. moparisthebest

    It can be a default, or you can suggest the client sets the TTL for their outgoing messages to the first one received?

  242. 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)

  243. 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

  244. moparisthebest

    To 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

  245. moparisthebest

    Considering sometimes you read mam backwards or have holes, that seems bad

  246. moparisthebest

    Where as a per message TTL gives you the same experience but is stateless

  247. pep.

    I agree that does complicate things but it's also not the same goal.

  248. pep.

    And if there's a way to answer this technically I'd be happy to know

  249. moparisthebest

    You can keep the same goal with a per message TTL though right?

  250. pep.

    Well I'm not sure no

  251. moparisthebest

    I *think* I understand your goal now anyway, I didn't initially

  252. moparisthebest

    Basically keep the spec the same, but you don't store/calculate TTL seperately from the messages

  253. pep.

    Tbh if there could be like, one PEP node negociated for the current chat, that might make things a lot easier..

  254. moparisthebest

    You can still use the last messages TTL to show the user and send in your next message etc

  255. 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

  256. moparisthebest

    The difference being you don't need to replay all history in order to calculate current TTL, only look at the last message

  257. pep.

    You don't "calculate" the TTL, it IS sent with every message

  258. mjk

    it is?

  259. pep.

    ATM it is yes

  260. mjk goes re-reading the xml

  261. mjk

    it is.

  262. 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"

  263. pep.

    And I didn't find a way to get feedback before the protoxep so here it is..

  264. moparisthebest

    What do you do if you send me a message with the ephemeral tag and I respond without one?

  265. pep.

    If you don't implement the feature then so be it. Otherwise you should send the same back

  266. pep.

    And "so be it" if you don't do it anyway

  267. pep.

    I can't control your client

  268. moparisthebest

    I mean, is that your cancel mechanism?

  269. moparisthebest

    "Well they don't want me deleting their messages now" ?

  270. pep.

    That's where I'm stuck :/

  271. pep.

    How do I opt-out once I've opted-in

  272. moparisthebest

    I'd vote either that or a TTL of 0

  273. moparisthebest

    But if code has to handle both the same don't bother with both

  274. pep.

    "that" isn't good I guess

  275. pep.

    "that" isn't good I guess

  276. pep.

    Because any non-implementing client would make me stop the TTL

  277. pep.

    When MAM and stuff

  278. pep.

    So there needs to be a <thing/>

  279. pep.

    And it needs to be seen.

  280. mjk

    if 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

  281. pep.

    ttl=0 seems like a hack, but yeah that's the idea of the <i-want-out/>

  282. moparisthebest

    Shouldn't non implementing clients make you stop though?

  283. pep.

    Maybe @timer should be Option<u32>

  284. moparisthebest

    I mean UI should indicate the other client won't listen anymore

  285. pep.

    moparisthebest, no, same problem as usual

  286. pep.

    Yes

  287. pep.

    That's specified

  288. moparisthebest

    I don't think 0 is a hack, a real TTL of 0 makes no sense

  289. pep.

    Non-implementing clients shouldn't make anybody stop from using specific features because MAM and the like

  290. pep.

    But that's annoying I get it

  291. mjk

    a hack in the sense it's a sum type? like option<u32>

  292. moparisthebest

    If 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

  293. 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?

  294. pep.

    Do I stop sending you ttl'd messages?

  295. pep.

    Do I send two different messages to your fulljids? :P

  296. mjk

    also, with mam, any non-implementing client can retrieve later and store forever. that's always a possibility

  297. 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"

  298. moparisthebest

    pep.: Yea you stop sending them if you need them deleted

  299. pep.

    Where that's not my spec is about

  300. pep.

    Well that's not my spec is about

  301. moparisthebest

    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?"

  302. pep.

    "Abstract This specification encourages a shift in privacy settings wrt. logging policies."

  303. pep.

    It's fine if a message isn't deleted

  304. moparisthebest

    Same as when you are having an OMEMO conversation with someone and they suddenly send a few unencrypted

  305. pep.

    This isn't a security spec

  306. moparisthebest

    If you aren't trying this spec is useless

  307. moparisthebest

    This isn't even some strange edge case, it needs covered

  308. 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

  309. pep.

    And I'm not going the way "then don't store in MAM"

  310. pep.

    Because I want clients to still be usable

  311. pep.

    fwiw that's what the old version was doing

  312. moparisthebest

    You can't because then you are back to not working on iOS

  313. 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

  314. pep.

    This isn't technically possible

  315. pep.

    Or it is but you're willing to go to lengths this spec isn't, because it's not the goal

  316. mjk

    i mean, it's up to implementation to notice and warn the user

  317. moparisthebest

    If you wanted to try real hard you'd require encryption and sign the promise with keys and only encrypt to keys that promised ?

  318. pep.

    Yeah but I'm not doing that

  319. 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

  320. moparisthebest

    mjk: 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. ?

  321. pep.

    (I also do have logs on my poezio and I don't understand why, it's useful sometimes, ok, but not really important)

  322. moparisthebest

    You can continue sending ephemeral in your messages of course

  323. moparisthebest

    pep.: I have the solution for that

  324. 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)."

  325. pep.

    In the spec ^

  326. moparisthebest

    I 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

  327. 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."

  328. pep.

    moparisthebest, :D

  329. moparisthebest

    pep.: 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?

  330. moparisthebest

    I don't think it does, therefore not getting it should be your opt out message

  331. pep.

    When a client says "I opt out", the receiving client can show a status message or something

  332. pep.

    "TTL has be removed"

  333. moparisthebest

    It should show the same if they switched to a different client?

  334. pep.

    Show the same what?

  335. pep.

    TTL hasn't be removed for a non-supporting client, it was never supported

  336. moparisthebest

    The result is the same

  337. pep.

    The result is the same, but I'd warn in different places

  338. moparisthebest

    In both cases they know their contact won't delete the messages

  339. pep.

    The non-supporting client might have been listening all along and that's fine

  340. pep.

    Yes

  341. pep.

    Because they've been told when activating the feature

  342. 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

  343. moparisthebest

    Then I'm back to why have an opt out at all

  344. moparisthebest

    If you aren't going to show any special warnings

  345. pep.

    I just told you I would

  346. pep.

    (?!?!?)

  347. moparisthebest

    > Because they've been told when activating the feature

  348. moparisthebest

    You said one warning at the beginning is all?

  349. pep.

    And pep.> When a client says "I opt out", the receiving client can show a status message or something pep.> "TTL has be removed"

  350. moparisthebest

    And it should show the same when receiving no TTL at all...

  351. pep.

    No

  352. pep.

    Well I don't think so

  353. moparisthebest

    It's the same effect

  354. 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

  355. mjk

    > it's not the same thing because there's probably a conscious human decision behind the latter

  356. moparisthebest

    Maybe they explicitly switched to the unsupporting client?

  357. moparisthebest

    I don't think they have a meaningful distinction

  358. pep.

    Maybe they did, and maybe they'll tell the sending client to stop, like in human speech

  359. pep.

    That's a thing also :P

  360. pep.

    Whether the client wants to merge UI for this is ok, but protocol-wise I'll keep that different

  361. mjk too sleepy for consciou human anything

  362. pep.

    It'd still be weird to me that these two are merged

  363. moparisthebest

    I think it's dangerous to allow them to handle it differently

  364. moparisthebest

    Because inevitably someone will, and that'll be wrong

  365. pep.

    Well say we handle them the same way

  366. pep.

    That means while not everybody implements it, we can't use the feature

  367. pep.

    That means as long as not everybody implements it, we can't use the feature

  368. moparisthebest

    This is introducing a nullable Boolean into the spec

  369. moparisthebest

    And saying "treat null the same as false"

  370. moparisthebest

    Instead of just making it non nullable

  371. pep.

    Yeah no sorry I don't want to live in a maybe monad

  372. moparisthebest

    > That means as long as not everybody implements it, we can't use the feature I'm not following

  373. moparisthebest

    The client behaves the same either way

  374. 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

  375. pep.

    I'm probably stop using it before I even start

  376. pep.

    I'll probably stop using it before I even start

  377. pep.

    As I said this spec isn't a security spec

  378. 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

  379. pep.

    wat

  380. pep.

    Ok I didn't get what you mean then

  381. moparisthebest

    Like you said mam and other clients might come back online etc

  382. pep.

    So what changes

  383. pep.

    Both clients might have been listening all the time. Because suddenly you decide from one shouldn't change anything to me

  384. 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

  385. moparisthebest

    Right, other than you warn the user that they won't be deleting them now

  386. pep.

    "now"?

  387. pep.

    Both clients were listening from the start

  388. pep.

    The sending user has been warned already

  389. pep.

    Ah, the receiving client may not delete these messages though.. because they don't include the TTL.

  390. pep.

    Is that another issue or is it what you were pointing at for all this time

  391. pep.

    I mean..

  392. pep.

    The client receiving non-TTL'd messages