XSF Discussion - 2022-01-29

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

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

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?

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

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

(with iqs)

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

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

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

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

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

(they can also disagree)

pep., What does the negotiation do?

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

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

Ah

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.

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

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

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.

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

This is not a security feature to me

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

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

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

“Privacy by default”, they said.

Not privacy from your chat partner, nobody said that

hmm?

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

(Same as mine, fwiw)

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

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

mdosch, or you can choose not to ues the feature

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

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

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 ✏

I see

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?

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

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 :(

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

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

:)

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"

We all know the impossibility of true ephemeral messaging

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

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

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