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
😉
debaclehas joined
mjkhas left
ralphm
FWIW: I think that the concept of ephemeral messages, with all the caveats in the spec, is a mis-feature.
mjkhas joined
djorzhas joined
jonas’
why do you think so?
Andrzejhas joined
adiaholichas left
Menelhas left
L29Ahhas joined
Menelhas joined
Menelhas left
Menelhas joined
moparisthebest
I think it's stupid too but you know it's the next "one thing (tm)" that XMPP is missing
antranigvhas joined
Andrzejhas left
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
Yagizahas left
mjkhas left
mjkhas joined
Maranda[x]has left
Maranda[x]has joined
Menelhas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
librehas left
Wojtekhas left
librehas joined
Maranda[x]has left
Maranda[x]has joined
antranigvhas left
Menelhas joined
archas left
archas joined
Menelhas left
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
Menelhas joined
Kevhas left
Menelhas left
gooyahas left
adiaholichas joined
Syndacehas left
Syndacehas joined
Menelhas joined
Menelhas left
adiaholichas left
Dele Olajidehas joined
Maranda[x]has left
Maranda[x]has joined
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)
marc0shas left
marc0shas joined
archas left
Menelhas joined
archas joined
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. »
Toxihas left
gooyahas joined
pep.
As for your second comment, hmm.
mhhas left
mhhas joined
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.
With a "I read and it's ok I'm willing to continue" before the rest shows up
mjk
Put it in abstract!
adiaholichas joined
alex11has left
krauqhas left
adiaholichas left
librehas left
librehas joined
Dele Olajidehas left
adiaholichas joined
beanhas left
mhhas left
mhhas joined
krauqhas joined
tykaynhas left
adiaholichas left
librehas left
librehas joined
Toxihas joined
Tobiashas left
Tobiashas joined
marchas left
Maranda[x]has left
Maranda[x]has joined
jonas’
who reads *that*?
adiaholichas joined
papatutuwawahas left
adiaholichas left
Menelhas left
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
adiaholichas joined
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
brunrobehas left
Mjolnir Archonhas left
Marandahas left
krauqhas left
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.
Tobiashas left
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
archas left
archas joined
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
krauqhas joined
msavoritiashas left
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.✎
atomicwatchhas left
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)
jcbrandhas left
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
adiaholichas left
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
konstantinoshas left
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
marchas joined
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"
pasdesushihas left
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
Sevehas left
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?
marc0shas left
marc0shas joined
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
marchas left
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
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
lovetox
yes, describe whatever is needed
goffihas left
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.
archas left
archas joined
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 >:)
mjkhas left
mjkhas joined
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
mjkhas left
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
mhhas left
mhhas joined
moparisthebest
Absolutely, gotta take the initiative and time to learn though
mjkhas joined
mjk
"don't let kids into the internet, they make it dumb!"
karoshihas left
mjk
(-er)
pep.
moparisthebest, I agree it's really hard nowadays when all we're doing is work in bs jobs..
qwestionhas left
gooyahas left
emus
Folks, is fine to review user expierence but I dont think such a meta discussion helps this topic
gooyahas joined
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
debaclehas left
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
librehas left
moparisthebest
Nope I fully agree with you
librehas joined
archas left
moparisthebest
Encourage them to learn their tools even
archas joined
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?
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.
marc0shas left
marc0shas joined
moparisthebest
Imho get rid of all that and simply send an "expires after" per message?
adiaholichas joined
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
marc0shas left
marc0shas joined
pep.
hmm, which part
marc0shas left
marc0shas joined
moparisthebest
What are you missing simply by saying "please delete this message after X" sent per message?
adiaholichas left
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
qwestionhas joined
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
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
brunrobehas joined
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
adiaholichas joined
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
wurstsalathas left
Maranda[x]has left
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
What about instead of all this complicated state management you simply send a TTL per message?
adiaholichas left
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
qwestionhas left
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
Mjolnir Archonhas joined
Marandahas joined
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
adiaholichas joined
mjk
it is?
pep.
ATM it is yes
mjkgoes 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 :/
adiaholichas left
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
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
Titihas left
mjk
a hack in the sense it's a sum type? like option<u32>
adiaholichas joined
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
archas left
archas joined
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
sonnyhas left
adiaholichas left
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
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
qwestionhas joined
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"
marc0shas left
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
marc0shas joined
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
djorzhas left
mjkhas left
mjkhas joined
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
mjktoo sleepy for consciou human anything
pep.
It'd still be weird to me that these two are merged
emushas left
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✎
librehas left
librehas joined
pep.
That means as long as not everybody implements it, we can't use the feature ✏
krauqhas left
librehas left
librehas joined
krauqhas joined
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
librehas left
librehas joined
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
> 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
adiaholichas joined
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
Ingolfhas joined
neshtaxmpphas left
neshtaxmpphas joined
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