XSF Discussion - 2022-01-29


  1. pep.

    Just as a nit, following the pubsub-ns ml thread and pubsub#type, I want to note that "Atom" is also semantics, otherwise we'd have put XML in there I guess :)

  2. pep.

    (this didn't require to revive the thread..)

  3. pep.

    So with my ephemeral messages I've got an issue. I decided I couldn't trust people/clients to fetch all MAM to see that I've "negociated" ephemeral messages, so I include that in every message, this way I'm more or less sure they get the drill. This is fine. Now how do I stop doing ephemeral messages? I can't just stop sending the tag otherwise I'm breaking a MUST (or whatever) that says I honor the timer I receive as long as I advertise the feature. So I also have to negociate it. Do I also need not to trust MAM and include <I-want-out/> in every single of my messages now?

  4. pep.

    This is an issue I have not only with ephemeral messages. I hope you can see the genericity of the situation :x

  5. pep.

    Otherwise I have to negociate with every single device I encounter, which may be none if I don't have a directed presence

  6. pep.

    (with iqs)

  7. Menel

    Sounds like the xep should say, its only an ephemeral message as long the tag is included?

  8. pep.

    That'd work in the case there's no negociation to be made

  9. dwd

    pep., By "ephemeral", you mean a "message burn" type facility?

  10. pep.

    Not sure what that is. But ephemeral is also not very clear anyway I give you

  11. pep.

    Yeah, some kind of message that'll go away at some point, but the user agreed to it in this case

  12. pep.

    (they can also disagree)

  13. dwd

    pep., What does the negotiation do?

  14. Menel

    Its about this right? https://xmpp.org/extensions/inbox/ephemeral-messages.html#support

  15. pep.

    Menel, yes but I'm not reusing the XEP for now. I'll compare afterwards how close I am

  16. Menel

    Ah

  17. dwd

    pep., So, for some context, the company I worked at until yesterday did ephemeral messages (not according to any specification). It included a "burn time" in each such message. But, it was a (partly) closed system, with a restricted client, and the client would check the time on the local device etc. So in other words, the system as a whole could enforce it.

  18. pep.

    Clients negotiate a delay after which messages are discarded. And they'll use the same. Really what I call negotiation here is "send a message with a tag and a delay", and that's it. If the other party wants a different delay, then it sends another message (or "implicit negociation", no body) with a new delay

  19. pep.

    Yeah I'm not planning to enforce anything, and that's not my issue here anyway :x

  20. dwd

    pep., Whereas, I think Council rejected ephemeral messaging before because it couldn't be enfrced in any reasonable way, and therefore ran the risk that it would generate a false sense of security. And if a client does enforce it, I would argue that on an open messaging system the user ought to be in control of how they handle messages they receive anyway.

  21. pep.

    I don't want that and I explicit it in the document

  22. pep.

    This is not a security feature to me

  23. pep.

    And if the XSF rejects it, oh well. I can host that somewhere

  24. pep.

    It's mostly about shifting the "log everything forever" thing around, at least in some circles. I'd go about changing client defaults but I feel that's a close to impossible task

  25. pep.

    And I don't want to fork every client I use

  26. pep.

    “Privacy by default”, they said.

  27. Menel

    Not privacy from your chat partner, nobody said that

  28. pep.

    hmm?

  29. pep.

    But my chat partner's logs can be seen by people both of us don't trust. I guess we don't want that

  30. pep.

    (Same as mine, fwiw)

  31. pep.

    (actually trust doesn't necessarily come into play here. "People these messages weren't destined to" is good enough)

  32. mdosch

    Then I have to run each client in debug mode for the case meassages disappeared before I read them?

  33. pep.

    mdosch, or you can choose not to ues the feature

  34. pep.

    It's still up to you and your chat partner. I'm only proposing protocol. I hope people talk about things

  35. pep.

    "Hey what's this, it says my messages are going to disappear" "yeah I enabled it" "ah, I'd rather not" "ok/nok"

  36. pep.

    Also, I explicitely choose a timer and not a timestamp for this use-case. I don't want people to miss messages just because they were in holidays. I leave this role to server storage policies

  37. pep.

    Also, I explicitely chose a timer and not a timestamp for this use-case. I don't want people to miss messages just because they were in holidays. I leave this role to server storage policies

  38. mdosch

    I see

  39. flow

    servers establish an extra s2s stream to components of a remote server, correct? there is no mechanism to share the stream of the component's server for that?

  40. rocco

    > It's mostly about shifting the "log everything forever" thing around, at least in some circles. I'd go about changing client defaults but I feel that's a close to impossible task I think inforcing disappearing messages in 1to1 communications isnt a good choice on an open and federated network. It would risk to create a false sense of security because there would be always a way to cheat. If two peaple want to exchange ephimeral messages they can set an autodestruction timer autonomously (conversation permit that) or erase manually their log of the conversation. 1to1 chat needs to be trustless from third party - but the peaple talking need to trust each others. Its a semantic constatation first, and only then is a messaging design problem.

  41. pep.

    So apart from people who like to comment on a feature they don't know much about (specifics not yet published), I haven't had any hint of an answer to my somewhat generic question :(

  42. pep.

    I knew I was right the other day not to mention it

  43. MattJ

    I didn't quite understand the generic question, and I'm mostly trying to have the weekend off so I didn't try too hard yet

  44. pep.

    :)

  45. MattJ

    But as for acceptance, I am generally of the opinion that this is a popular feature of many messaging apps, and it has been shown that there is interest by some parties to do this over XMPP. I believe it's the XSF's responsibility to assist with standardizing "if you want X, this is how you should do it"

  46. MattJ

    We all know the impossibility of true ephemeral messaging

  47. MattJ

    Which is partly why it needs to be written down how to do it in a sensible way, with the long list of security considerations

  48. MattJ

    Then for the client developers who do want to implement it, they can have interoperable implementations

  49. pep.

    Also to be noted, many things go behind this name :/