-
ralphm
jonas’: 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)
-
ralphm
😉
-
ralphm
FWIW: 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?
-
moparisthebest
I think it's stupid too but you know it's the next "one thing (tm)" that XMPP is missing
-
lovetox
i dont see this working ..
-
lovetox
whats with the negotiation .. why?
-
moparisthebest
it's ok all it needs to do is give people a false sense of security
-
lovetox
every user should just choose when his messages going to be removed
-
moparisthebest
signal has it after all
-
lovetox
why negotiate something
-
mjk
lovetox: because any participant's message could incriminate any other participant (even without considering >quoting)
-
mjk
The falseness of security sense is up to client UI designers to dispell, I'd hope :)
-
mjk
No need to follow misleading ui of $super_recure_messenger
-
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)
-
pep.
mjk, that non-binding must is clarified in the implementation notes
-
mjk
Ok, 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. »
-
moparisthebest
should you mention annoying things like apps preventing screenshots from being taken of them etc ?
-
pep.
I think that summarizes it
-
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
-
pep.
moparisthebest, no it's exactly what I don't want this spec to be
-
moparisthebest
I think that's what "the signal" does
-
pep.
Read the security considerations
-
moparisthebest
oh, 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.
-
mjk
:d✎ -
mjk
:D ✏
-
pep.
With a "I read and it's ok I'm willing to continue" before the rest shows up
-
mjk
Put it in abstract!
-
jonas’
who reads *that*?
-
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.✎ -
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. ✏
-
ralphm
But 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?
-
Guus
ralphm: I don't fully agree. There is nothing that prevents you to use XMPP in a controlled environment.
-
jonas’
^5 Guus
-
Guus
we're on a roll today, jonas’
-
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
-
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.
-
jonas’
right, but *that* is definitely outside the XSF' scope
-
jonas’
(screenshots etc.)
-
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
-
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.
-
jonas’
I don't agree
-
ralphm
But having a single spec for the intent is better than everyone reinventing the wheel, badly.
-
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.
-
pep.
Then again all I'm reading here is "I haven't read security considerations"
-
ralphm
Scroll back to my first message
-
pep.
"I still think it is not great. Screenshots, photos of screens, etc."
-
pep.
:/
-
ralphm
(19:18 UTC)
-
pep.
Yeah but you're still talking about screenshots, and that's not related to this spec
-
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.
-
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
-
ralphm
My context also includes vulnerable users. Like young teens.
-
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.
-
pep.
Sorry this wasn't really clear because it's been rejected for this exact reason before as well
-
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.✎ -
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. ✏
-
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 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.
-
pep.
(Even though a client doesn't have to reuse this name obviously)
-
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.
-
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
-
mjk
Link Mauve: that shoud apply to communications in general, not deletion specifically :)
-
Link Mauve
Yes to both.
-
Link Mauve
But 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 Mauve
The usual nude that will be deleted ten seconds later, which then gets posted widely to the Internet.
-
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...
-
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 Mauve
I 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 Mauve
Couldn’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 Mauve
Or 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
-
lovetox
im 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
-
lovetox
The way should be Users tells client dev wishes -> Client dev tells XSF protocol needs
-
lovetox
XSF is not here for Users, and is not there to shild and protected users from bad client devs
-
lovetox
otherwise 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
-
lovetox
Users = Users of Clients
-
pep.
Sure
-
lovetox
no, sorry, they dont usually come here and tell what they want
-
pep.
The XSF doesn't live in a vacuum
-
lovetox
they create issues on client developer issue trackers
-
lovetox
Users 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.
-
lovetox
no 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"
-
lovetox
correct, 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
-
lovetox
the 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
-
lovetox
but not to say: Uh we are federated, im not sure 100% of devs implement this 100% secure
-
lovetox
so lets not even start to make a protocol
-
pep.
lovetox, yeah but XEPs aren't made in vacuum either. They answer a demand
-
lovetox
yeah 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
-
lovetox
to 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
-
lovetox
yeah its none of your business
-
lovetox
*XSF
-
lovetox
because what if servers store messages although user deactivated it in archiving preferences?
-
lovetox
what if server routes message wrong altough RFC says otherwise
-
lovetox
what if client does encryption wrong, altough XEP says otherwise
-
lovetox
like i can make a million errors as developer
-
lovetox
for 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
-
lovetox
yes, 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.
-
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"
-
lovetox
the argument against this XEP is always the same, BUT what if one client does not respect the deletion wish"
-
lovetox
and 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
-
mjk
well said
-
moparisthebest
As council I'll pass the spec if it's sound from a technical perspective
-
moparisthebest
As moparisthebest I'm definitely publishing patches for all clients that implement this to claim to implement it but never actually delete anything >:)
-
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.
-
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?
-
moparisthebest
pep.: correct
-
pep.
..
-
Sam
Yes, children should not have phones.
-
moparisthebest
And 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
-
ralphm
pep.: 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
-
pep.
What else
-
moparisthebest
If 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
-
moparisthebest
Absolutely, gotta take the initiative and time to learn though
-
mjk
"don't let kids into the internet, they make it dumb!"
-
mjk
(-er)
-
pep.
moparisthebest, I agree it's really hard nowadays when all we're doing is work in bs jobs..
-
emus
Folks, is fine to review user expierence but I dont think such a meta discussion helps this topic
-
emus
Internet has many bad ibfluences to people. lets stop with real-time communciation?
-
ralphm
Disagree
-
pep.
emus, yeah definitely, way to go :)
-
emus
^^
-
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
-
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
-
moparisthebest
Nope I fully agree with you
-
moparisthebest
Encourage them to learn their tools even
-
emus
I tend to think the same
-
mjk
And we're back to good (=educational) UI :)
-
pep.
That's prerequisite yeah (though my comment was a lot more general about society :P)
-
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.
-
emus
I missed the beginning. but as there is a proto-xep people can implement it regardless of our discussion right?
-
moparisthebest
emus: https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html
-
ralphm
The 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.
-
emus
moparisthebest: yes I know the xep, but thanns
-
emus
pep.: ok
-
pep.
(That is, I actually got feedback nowhere.)
-
moparisthebest
pep.: Technical wise I'm not sure the reason for https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html#example-3
-
emus
understood
-
ralphm
Sorry I didn't really get into the protocol itself. I hope you can appreciate my input anyway.
-
moparisthebest
Or the "they will expire in X from now on" language
-
emus
thx, but gn8
-
moparisthebest
Shouldn'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
-
moparisthebest
Also makes the strange <i-want-out/> thing go away, but I might be missing a reason?
-
moparisthebest
The 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
-
pep.
Please help.
-
moparisthebest
Imho 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
-
moparisthebest
Unclear what you mean
-
pep.
hmm, which part
-
moparisthebest
What are you missing simply by saying "please delete this message after X" sent per message?
-
pep.
Is it still about the implicit timer thing?
-
moparisthebest
And, maybe something in disco hinting they might do it
-
moparisthebest
Yea 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)
-
moparisthebest
I'm saying don't have a way to opt in or out
-
moparisthebest
Just a TTL per message only
-
pep.
Maybe you're missing the point of the spec?
-
pep.
(naively asking)
-
pep.
Or maybe you're right but I don't see it
-
pep.
"This specification encourages a shift in privacy settings wrt. logging policies."
-
moparisthebest
I might be that's what I'm asking
-
pep.
I'm not aiming at this being just an isolated user wanting their messages deleted
-
moparisthebest
Wait 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"
-
pep.
Well, "per-chat-from-now-on"
-
moparisthebest
That sounds like it should be in pep then no?
-
pep.
Not sure how to call that
-
pep.
Which PEP?
-
pep.
of the two person in 1:1
-
moparisthebest
Like a public user setting for their contacts?
-
pep.
And if they're not in my contacts
-
pep.
and in MUC?
-
moparisthebest
Please delete all my messages after X
-
pep.
Read the spec, this question is already in there
-
moparisthebest
This can't even work in a muc
-
pep.
why not
-
moparisthebest
At least not a public one
-
pep.
If not I'll make it work
-
pep.
That's a social issue
-
pep.
technically it works
-
moparisthebest
Because you are pep. Now doesn't mean the pep. Who sends the next message is you
-
pep.
I'm not sure where you're getting at✎ -
pep.
I'm not sure what you're getting at ✏
-
moparisthebest
I don't have your jid
-
pep.
Why is that needed
-
moparisthebest
What about instead of all this complicated state management you simply send a TTL per message?
-
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?
-
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?
-
moparisthebest
I mean keep the disco feature, but then simply send a TTL per message
-
pep.
So the disco feature would mean what
-
moparisthebest
If they send a TTL then you delete it, if not, your choice
-
moparisthebest
disco 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
-
moparisthebest
I 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
-
moparisthebest
That 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.
I mean,
-
pep.
They'll have to somehow learn about the thing and enable it maybe. Basically only nerds will enable it
-
moparisthebest
It 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
-
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
-
moparisthebest
Considering sometimes you read mam backwards or have holes, that seems bad
-
moparisthebest
Where 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
-
moparisthebest
You can keep the same goal with a per message TTL though right?
-
pep.
Well I'm not sure no
-
moparisthebest
I *think* I understand your goal now anyway, I didn't initially
-
moparisthebest
Basically 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..
-
moparisthebest
You 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
-
moparisthebest
The 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
-
mjk
it is?
-
pep.
ATM it is yes
- mjk goes re-reading the xml
-
mjk
it is.
-
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..
-
moparisthebest
What 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
-
moparisthebest
I 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
-
moparisthebest
I'd vote either that or a TTL of 0
-
moparisthebest
But if code has to handle both the same don't bother with both
-
pep.
"that" isn't good I guess✎ -
pep.
"that" isn't good I guess ✏
-
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.
-
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
-
pep.
ttl=0 seems like a hack, but yeah that's the idea of the <i-want-out/>
-
moparisthebest
Shouldn't non implementing clients make you stop though?
-
pep.
Maybe @timer should be Option<u32>
-
moparisthebest
I mean UI should indicate the other client won't listen anymore
-
pep.
moparisthebest, no, same problem as usual
-
pep.
Yes
-
pep.
That's specified
-
moparisthebest
I 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
-
mjk
a hack in the sense it's a sum type? like option<u32>
-
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
-
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
-
mjk
also, 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"
-
moparisthebest
pep.: Yea you stop sending them if you need them deleted
-
pep.
Where that's not my spec is about✎ -
pep.
Well that's not my spec is about ✏
-
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?"
-
pep.
"Abstract This specification encourages a shift in privacy settings wrt. logging policies."
-
pep.
It's fine if a message isn't deleted
-
moparisthebest
Same as when you are having an OMEMO conversation with someone and they suddenly send a few unencrypted
-
pep.
This isn't a security spec
-
moparisthebest
If you aren't trying this spec is useless
-
moparisthebest
This 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
-
moparisthebest
You 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
-
mjk
i mean, it's up to implementation to notice and warn the user
-
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 ?
-
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
-
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. ?
-
pep.
(I also do have logs on my poezio and I don't understand why, it's useful sometimes, ok, but not really important)
-
moparisthebest
You can continue sending ephemeral in your messages of course
-
moparisthebest
pep.: 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 ^
-
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
-
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."
-
pep.
moparisthebest, :D
-
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?
-
moparisthebest
I 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"
-
moparisthebest
It 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
-
moparisthebest
The result is the same
-
pep.
The result is the same, but I'd warn in different places
-
moparisthebest
In 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.
Yes
-
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
-
moparisthebest
Then I'm back to why have an opt out at all
-
moparisthebest
If you aren't going to show any special warnings
-
pep.
I just told you I would
-
pep.
(?!?!?)
-
moparisthebest
> Because they've been told when activating the feature
-
moparisthebest
You said one warning at the beginning is all?
-
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"
-
moparisthebest
And it should show the same when receiving no TTL at all...
-
pep.
No
-
pep.
Well I don't think so
-
moparisthebest
It'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
-
moparisthebest
Maybe they explicitly switched to the unsupporting client?
-
moparisthebest
I 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
- mjk too sleepy for consciou human anything
-
pep.
It'd still be weird to me that these two are merged
-
moparisthebest
I think it's dangerous to allow them to handle it differently
-
moparisthebest
Because 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 ✏
-
moparisthebest
This is introducing a nullable Boolean into the spec
-
moparisthebest
And saying "treat null the same as false"
-
moparisthebest
Instead 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
-
moparisthebest
The 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.
wat
-
pep.
Ok I didn't get what you mean then
-
moparisthebest
Like 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 ✏
-
moparisthebest
Right, other than you warn the user that they won't be deleting them now
-
pep.
"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
-
pep.
I mean..
-
pep.
The client receiving non-TTL'd messages