msavoritiasI think what moparisthebest said is correct. Basically i see it going like this:
1. User enables the feature. Client says something like: "We cant quarantee the messages are not screenshoted or forwarded or the feature bypassed in some way. The deleting will be done best effort".
The user bob enables the ephemeral messages with user alice. And from here we have 2 scenarios that we need to warn the user about.
1. Alice's client sends back that it doesnt support the feature. So we say to the user this cant be enabled here because it wont work. I feel like this is the best responce to send to the user since we know for sure in this scenario.
2. Alice's client sends back that it supports the feature. At a later date/time she switches to her desktop client that doesnt support the feature.
I think two things should be clear here:
a. We shouldnt expect the users to know when or if their client supports or not the feature.
b. We should communicate to the user that their contact changed to a client not supporting the xep which meant the spec cant be honored. Personally here i see the only good choice from a client perspective to be to disable the feature.
That probably does get us to a MIX or OMEMO situation as you said pep. in which you have to wait for a lot of clients to implement it before we can use it. I am not sure how else it can be done though. Personally i wouldnt want to ignore and keep it enabled when somebody switched to an unsupported client.
Maybe it can be done as it was mentioned to get a list of the devices in the begining and query from there if they support it.
marc0shas left
marc0shas joined
jonas’> Alice's client sends […]
It may not even be online (and most likely isn't if it's an iOS device).
goffihas joined
tykaynhas joined
L29Ahhas left
archas left
lovetoxhas left
harry837374884has left
archas joined
intosihas left
msavoritiasAlso true. So querying doesnt even work. Also Alice may start using new clients.
Maybe it should just be when the client get message that doesnt have the timer field he disables the feature because he cant trust the client anymore.
inkyhas left
restive_monkhas left
mjkhas joined
restive_monkhas joined
konstantinoshas left
adiaholichas joined
lovetoxhas joined
debaclehas left
lskdjfhas joined
adiaholichas left
debaclehas joined
intosihas joined
intosihas left
intosihas joined
pasdesushihas joined
inkyhas joined
millesimus> 1. User enables the feature. Client says something like: "We cant quarantee the messages are not screenshoted or forwarded or the feature bypassed in some way. The deleting will be done best effort".
I'd suggest the clients say something like: "Ephemeral messages are a technical way of asking your chat partner to delete the messages. If you ask them directly, there is no way to control their behaviour; and it's the same with ephemeral messages."
Ephemeral messages are no security feature, but they are way less awkward then asking your chat partner to delete the messages.
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
restive_monkhas left
Guushas left
Guushas joined
lovetoxhas left
Dele Olajidehas left
Dele Olajidehas joined
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
lovetoxhas joined
konstantinoshas joined
marc0shas left
marc0shas joined
intosihas left
ti_gj06has left
stphas joined
Andrzejhas left
marc0shas left
marc0shas joined
intosihas joined
Wojtekhas joined
Ingolfhas joined
Andrzejhas joined
mjk> b. We should communicate to the user that their contact changed to a client not supporting the xep which meant the spec cant be honored.
It still can, counter-intuitively! :) A supporting client may come online a minute after the conversation is done, fetch archive, see no TTLs and go "welp, no can do, Imma keepin this forever!"
restive_monkhas joined
archas left
antranigvhas left
antranigvhas joined
archas joined
lovetoxhas left
tykaynhas left
stphas left
adiaholichas joined
restive_monkhas left
adiaholichas left
raucaohas left
archas left
raucaohas joined
archas joined
archas left
intosihas left
COM8has joined
COM8has left
archas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
debaclehas left
Marandahas left
Mjolnir Archonhas left
brunrobehas left
marc0shas left
marc0shas joined
Menelhas left
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
restive_monkhas joined
lovetoxhas joined
Menelhas joined
brunrobehas joined
restive_monkhas left
Ingolfhas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
debaclehas joined
Andrzejhas left
lovetoxhas left
Marandahas joined
Mjolnir Archonhas joined
gooyahas joined
lovetoxhas joined
archas left
archas joined
adiaholichas joined
ti_gj06has joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
atomicwatchhas left
atomicwatchhas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
restive_monkhas joined
archas left
Toxihas left
adiaholichas left
archas joined
adiaholichas joined
atomicwatchhas left
atomicwatchhas joined
harry837374884has joined
adiaholichas left
Maranda[x]has left
Maranda[x]has joined
archas left
beanhas joined
harry837374884has left
harry837374884has joined
adiaholichas joined
archas joined
Toxihas joined
COM8has joined
COM8has left
adiaholichas left
archas left
archas joined
adiaholichas joined
sonnyhas left
adiaholichas left
harry837374884has left
harry837374884has joined
ti_gj06has left
emushas joined
adiaholichas joined
restive_monkhas left
adiaholichas left
adiaholichas joined
lovetoxhas left
konstantinoshas left
վարյաhas joined
konstantinoshas joined
sonnyhas joined
վարյաhas left
վարյաhas joined
adiaholichas left
Samhas joined
adiaholichas joined
վարյաhas left
վարյաhas joined
lovetoxhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
harry837374884has left
adiaholichas left
harry837374884has joined
վարյաhas left
վարյաhas joined
konstantinoshas left
restive_monkhas joined
konstantinoshas joined
adiaholichas joined
վարյաhas left
վարյաhas joined
mjkhas left
mjkhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
restive_monkhas left
վարյաhas left
վարյաhas joined
adiaholichas left
sonnyhas left
robertooohas left
antranigvhas left
վարյաhas left
վարյաhas joined
antranigvhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
antranigvhas left
antranigvhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
antranigvhas left
antranigvhas joined
sonnyhas joined
adiaholichas joined
Menelhas left
robertooohas joined
Toxihas left
Toxihas joined
antranigvhas left
twisted firestarterhas left
konstantinoshas left
Wojtekhas left
archas left
archas joined
Guushas left
Guushas joined
վարյաhas left
վարյաhas joined
adiaholichas left
վարյաhas left
վարյաhas joined
antranigvhas joined
adiaholichas joined
վարյաhas left
վարյաhas joined
xeckshas left
xeckshas joined
kurisuhas left
L29Ahhas joined
antranigvhas left
վարյաhas left
վարյաhas joined
mjkhas left
mjkhas joined
Guushas left
Guushas joined
archas left
Guushas left
Guushas joined
վարյաhas left
վարյաhas joined
archas joined
վարյաhas left
վարյաhas joined
adiaholichas left
adiaholichas joined
archas left
archas joined
վարյաhas left
վարյաhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
librehas joined
librehas left
վարյաhas left
վարյաhas joined
librehas joined
librehas left
librehas joined
archas left
restive_monkhas joined
stphas joined
archas joined
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
southerntofuhas joined
archas left
archas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
Dele Olajidehas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
վարյաhas left
վարյաhas joined
adiaholichas left
raghavgururajanhas joined
chipmnkhas left
վարյաhas left
վարյաhas joined
harry837374884has left
neshtaxmpphas left
neshtaxmpphas joined
adiaholichas joined
վարյաhas left
վարյաhas joined
Dele Olajidehas joined
adiaholichas left
վարյաhas left
վարյաhas joined
adiaholichas joined
harry837374884has joined
tykaynhas joined
Calvinhas joined
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
adiaholichas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
librehas left
Calvinhas left
Calvinhas joined
adiaholichas joined
marc0shas left
marc0shas joined
edhelasWould it be interesting to expose the account creation date ?
edhelasFor spam purpose it could be interesting
edhelasBut also for clients to know when the user joined the network
moparisthebestedhelas, so the server is injecting it then ?
edhelasOf course the servers can lie about it
ZashLies, on the Internet? UNPOSSIBLE
millesimushas left
millesimushas joined
pep.edhelas, I'd rather not encourage that :/
Guushas left
Guushas joined
Guushas left
Guushas joined
վարյաhas left
վարյաhas joined
lovetoxhas left
restive_monkhas left
wladmishas left
Calvinhas left
Danielhas left
Danielhas joined
wladmishas joined
adiaholichas left
lovetoxhas joined
Link Mauveedhelas, some servers don’t have this information.
gooyahas left
restive_monkhas joined
Guushas left
Guushas joined
վարյաhas left
վարյաhas joined
kurisuhas joined
marc0shas left
marc0shas joined
adiaholichas joined
L29Ahhas left
Menelhas joined
archas left
archas joined
restive_monkhas left
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
atomicwatchhas left
BASSGODhas left
archas left
archas joined
Andrzejhas joined
վարյաhas left
վարյաhas joined
adiaholichas left
adiaholichas joined
Dele Olajidehas left
L29Ahhas joined
վարյաhas left
վարյաhas joined
BASSGODhas joined
adiaholichas left
atomicwatchhas joined
L29Ahhas left
վարյաhas left
վարյաhas joined
adiaholichas joined
BASSGODhas left
վարյաhas left
վարյաhas joined
Dele Olajidehas joined
Calvinhas joined
վարյաhas left
Paganinihas joined
marc0shas left
marc0shas joined
վարյաhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
TheCoffeMakerRegarding the ephemeral messages ... What will happend with CC if like exposed msavoritias we have a mix of client supporting or not that feature?✎
TheCoffeMakerRegarding the ephemeral messages ... What will happend with CC, if like exposed msavoritias, we have a mix of client supporting or not that feature? ✏
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
վարյաhas left
վարյաhas joined
pep.In the current spec, the message is still being sent, because the goal isn't to break compatibility with existing clients, the goal is medium to long term to have clients switch their default logging policy: either using this feature, or by having users bully clients to change their default storage policy (because it's a thing that works, unfortunately.. free software projects aren't the most democratic), rendering this spec obsolete.
TheCoffeMaker👌
librehas joined
restive_monkhas joined
librehas left
adiaholichas left
Guushas left
Guushas joined
crypthas joined
twisted firestarterhas joined
gooyahas joined
BASSGODhas joined
վարյաhas left
վարյաhas joined
konstantinoshas joined
adiaholichas joined
վարյաhas left
վարյաhas joined
Guushas left
Guushas joined
gooyahas left
gooyahas joined
Guushas left
Guushas joined
Steve Killehas left
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
stphas left
konstantinoshas left
twisted firestarterhas left
վարյաhas left
վարյաhas joined
adiaholichas left
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
Steve Killehas joined
վարյաhas left
վարյաhas joined
wladmishas left
wladmishas joined
Guushas left
Guushas joined
stphas joined
archas left
archas joined
djorzhas joined
archas left
Andrzejhas left
xnamedhas left
marc0shas left
marc0shas joined
վարյաhas left
վարյաhas joined
archas joined
BASSGODhas left
archas left
archas joined
restive_monkhas left
adiaholichas joined
Maranda[x]has left
Maranda[x]has joined
jgarthas joined
gooyahas left
վարյաhas left
վարյաhas joined
gooyahas joined
Dele Olajidehas left
վարյաhas left
վարյաhas joined
Andrzejhas joined
Fishbowlerhas left
Fishbowlerhas joined
Steve Killehas left
moparisthebest> free software projects aren't the most democratic
What? They are the *most* democratic, don't like something, you fork it and everyone that agrees with you switches to your fork?
Ingolfhas joined
gooyahas left
ti_gj06has joined
gooyahas joined
neshtaxmpphas left
neshtaxmpphas joined
վարյաhas left
վարյաhas joined
SamVoting with your wallet or labor isn't the same as democratic.
SamI dunno why all free software should be democratic or not though, there are lots of different governance models.
moparisthebestForcing a maintainer to implement or maintain something they don't want certainly isn't democratic
harry837374884has left
moparisthebestIt's free software, that's the entire point, you do what you want with it
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
SamOf course not, who said it was?
Alexhas left
xnamedhas joined
pep.moparisthebest: no they're not democratic for most, you vote with your skills
marc0shas left
marc0shas joined
moparisthebestSkills anyone is free to aquire
SamThat's obvious nonsense; who the hell has time to go to school when you're busy holding down a job that takes all your time?
restive_monkhas joined
SamEither way, even if you could, that's still not what democratic means and both the original statement and your reply to it just don't make sense.
moparisthebestWho said anything about school
gooyahas left
Sevehas left
SamYou said anyone could aquire the skills. Most people can't afford to go to school, or spend a ton of time practicing or reading up on software.
վարյաhas left
վարյաhas joined
pep.Everyone doesn't have equal access to education indeed, nor has the time for it because $job
MattJRelevant: https://postmeritocracy.org/
moparisthebestpep.: So those people should force others to do their whim or?
pep.It's an exchange
marchas left
marchas joined
pep.As a developer I also benefit from people using my software. Of course I have limited resources and priorities but these priorities can change depending on user input
վարյաhas left
վարյաhas joined
Sevehas joined
marc0shas left
marc0shas joined
moparisthebest> As a developer I also benefit from people using my software.
In what way?
KevMattJ: I hadn't (I think) seen that, thanks.
վարյաhas left
վարյաhas joined
pep.moparisthebest: directly, being somewhat socially rewarded as the thing is useful, getting thanks, feedback, and various contributions that aren't especially code. indirectly, maybe these users are developers themselves and I'm using their software, etc.
xnamedhas left
ti_gj06has left
pep.MattJ: yeah that's a good example. I don't remember exactly what's in it but I remember stumbling upon it a while back
moparisthebestOnly if the changes benefit you though, no developer would make changes that helped others but hurt them
pep.It depends
pep.What do you value most. Your own (software) comfort or do you value more collective goals
moparisthebestI still think everyone that uses software can and should know how to program
xnamedhas joined
moparisthebestJust like everyone who drives a car should be able to change the oil and change the tire etc
moparisthebestIf you are too lazy and/or busy fine but you are the one that will suffer, your choice
pep.There are many features implemented in XMPP that I don't like and I'm still gonna advocate for it, even though at a personal level it's not benefiting me
GuusMumble mumble everyone that has kids should know how to raise them grumble
raghavgururajanhas left
ti_gj06has joined
վարյաhas left
վարյաhas joined
harry837374884has joined
tykaynhas left
moparisthebestHonestly this kind of willfull ignorance is how the desire for ephemeral messages even exists:
Ignorant user: I want to be able to unsay something on the internet
Anyone with basic knowledge: sorry that's not possible
Ignorant user: wwwwaaaaaaaa I want it just do it for me
վարյաhas left
վարյաhas joined
gooyahas joined
moparisthebestFrom MattJ 's link:
> We have an ethical responsibility to refuse to work on software that will negatively impact the well-being of other people.
moparisthebestThe more I think about it I'm wondering if it's unethical to even hint to a user that we'll try to delete their messages when we know it's not possible?
վարյաhas left
վարյաhas joined
DanielI actually think it's not about unsaying something on The Internet but about unsaying something on your own phone.
ZashNo responsibility without compensation!
Zashpoints at MIT license and then proceeds to fall asleep on the couch
moparisthebestYou can always delete from your own device
moparisthebestConversations even implements this, no XEP required
Alexhas joined
pep.Conversations defaults to "Never delete"
pep.Every single client out there defaults to that, I think
DanielYes. But an auto delete automates this and does this on a per chat and a per message basis
Ingolfhas left
ZashWe already have message retractions. Don't we have some time-delay thing, AMP or whatsitcalled?
pep.Daniel: an autodelete?
moparisthebestpep.: where's your PRs to change the default? And/or forks
Daniel> Conversations defaults to "Never delete"
> Every single client out there defaults to that, I think
It's not about defaults. I don't think that if Conversations were to implement ephemeral messages it would default them to something other than never
ZashOr just think of it as time-delayed message retraction, with exactly the same blbubrbl somethig words
pep.moparisthebest: from a quick ask around, they're all gonna be refused
lovetoxmoparisthebest, you think of the use case that you want to delete something because you want nobody to see it out of shame or whatever
restive_monkhas left
lovetoxbut in my work for example i often just delete messages, to not confuse people because i said something wrong
moparisthebestpep.: Then fork, and ask your contacts to switch
lovetoxand dont want to write 3 messages to take it back
pep.moparisthebest: lol
moparisthebestlovetox: we already have that right?
pep.Not sure if serious
moparisthebestThat spec doesn't lie to users that no one will ever see the original✎
pep."Fork all clients and make your users switch"
lovetoxand pep. spec say that?
lovetoxi doubt it highly :)
moparisthebestThat spec doesn't mislead users into thinking that no one will ever see the original ✏
lovetoxand thats already again the wrong argument
lovetoxno user reads XEPs
lovetoxXEPs are standards for implementing features by developers
lovetoxnot Users reading what the client does or not does
adiaholichas left
moparisthebestRight, but if we have an ethical obligation to avoid doing things to hurt users, do we not have an ethical obligation to reject XEPs that hurt users?
adiaholichas joined
lovetoxwe dont have a ethical obligation to hurt users
lovetoxwhat are you talking about
lovetoxXSF needs to provide standards for clear use cases
moparisthebestTo avoid hurting users
lovetoxno ..
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
lovetoxto give devs a way to implement something
lovetoxand not everyone needs to invent something themself
pep.If we have an ethical obligation to avoid doing things to hurt users, why do we have specs for military usage
gooyahas left
moparisthebestWhy did we deprecate xhtml-im and _xmppconnect etc? Because they hurt users right?
Daniel> If we have an ethical obligation to avoid doing things to hurt users, why do we have specs for military usage
I don't think we have that obligation
վարյաhas left
pep.I wasn't the one to say it :p
վարյաhas joined
moparisthebestpep.: military helps users that's why :)
pep.Hah
lovetoxmoparisthebest, _xmppconnect, because its not secure, no client who implements the spec can do it in a secure way, so its not sound
moparisthebestpep.: Ukraine shouldn't have military? How would that work out?
moparisthebestlovetox: so same with ephemeral messages then?
lovetoxevery client can implement message deletion and educate its users in a honest way
lovetoxso no not at all the same
moparisthebestWith server side mam and multiple clients they can't
lovetoxand thats the point
lovetoxat the one side you have something that cannot be done technically
pep.moparisthebest: military is controlled by the state, and no, the state isn't here to protect people, that's generally one of the biggest source of oppression
lovetoxon the other side *you* think that people going to do bad things
lovetoxand you think you need to save users
moparisthebestThe only honest thing a client can do is say "I can delete my own messages locally and that's it"
cryptThis is a fascinating topic that goes beyond the ephemeral message proposal.
Unlike proprietary clients that share the same feature-set across devices (Signal, Telegram, WhatsApp), current XMPP clients don't have feature parity.
It seems just like how your XMPP server informs your client of what XEPs it supports, clients also need to announce to each other the features they provide.
With this mechanism in place, **clients can show or hide features to each other based on feature discovery**. Another benefit to this... users can deactivate features they don't wish to announce.
lovetoxmoparisthebest, you can say "we will ask the other client to delete the message"
lovetoxand thats all people want :)
վարյաhas left
moparisthebestlovetox: as devs we know that's all they can have, I think they actually want something else
վարյաhas joined
Link Mauvecrypt, this is already how it works, mostly.
lovetoxbut thats not the problem of the xsf, its the problem of client devs
lovetoxthere can well be a messenger that is a walled garden and enforces what the user wants
lovetoxand they then need a protocol for it
Link MauveI’m not aware of any client hiding features based on user preferences, but some clients have plugin which lead to extending the features advertised.
moparisthebestlovetox: XSF doesn't make XEPs we know are impossible to implement though
lovetoxbut its not impossible, you fighting a strawman, the xep does not say "This standard guarantees that all messages are deleted forever"
Daniel> moparisthebest, you can say "we will ask the other client to delete the message"
It's more like "we are going to announce our retention policy to the other party and suggest that it might be a good idea to adopt a similar one"
> and thats all people want :)
lovetoxif it would say this, of course i would be with you
pep.I specifically did not want to say this
crypt> Link Mauve:
> 2022-04-27 12:19 (CDT)
> I’m not aware of any client hiding features based on user preferences, but some clients have plugin which lead to extending the features advertised.
Would be great to disable calls, for example, if I so choose.
Link MauveSure.
Link MauveYou might have to open an issue to your client(s) bugtracker if you want this though.
վարյաhas left
վարյաhas joined
ZashPretty sure I've seen a setting to disable advertising of software used (XEP-0091?)✎
ZashPretty sure I've seen a setting to disable advertising of software used (XEP-0092) ✏
Link MauveI’d like https://github.com/dino/dino/pull/1180 to be merged someday. :<
cryptBut it's the general idea I'm trying to make. I like disappearing messages on other chat apps. If two clients support it, then those people should use it if it's available.
Link MauveI always have to ask my contacts “how did you install Dino? On which Ubuntu version?” while I could just do a /version and get the answer otherwise…
moparisthebestpep.: my concrete objections to the spec as is are:
1. Needs to say what to do when ephemeral no longer is sent (like another client that doesn't support)
2. Needs to suggest a minimum TTL, like 1s probably would never be reasonable right? 0s wouldn't make sense at all (unless used for 3)
3. Needs to have a way to opt out defined, might be #1, might be TTL 0, might be something else
If those 3 were addressed I'd pass it.
Additionally I'd prefer stronger language suggestions for clients to tell users that this is really simply a suggestion and nothing more, but won't block on this
gooyahas joined
archas left
archas joined
cryptBut we won't know it's available on the users' XMPP client unless they talk through feature discovery. The dev for the client would display an icon if the feature is available between you two.
Wojtekhas joined
cryptThis would be the most user friendly approach to have disappearing messages or anything that comes next.
restive_monkhas joined
Samhas left
Link Mauvecrypt, the main issue with that is what to do with contacts who use more than one client, or whose client is offline atm.
Link MauveIt’s not specific to ephemeral messages though.
crypt> Link Mauve:
> 2022-04-27 12:31 (CDT)
> crypt, the main issue with that is what to do with contacts who use more than one client, or whose client is offline atm.
> It’s not specific to ephemeral messages though.
I agree. We have to think bigger picture.
lovetoxa month later i install on another machine, it downloads MAM, and all messages are again in my client
Zash(from https://what-if.xkcd.com/140/ )
lovetoxaltough i could delete it instantly because of TTL run out hm
lovetoxbut this should be mentioned probably in the spec
restive_monkhas left
moparisthebestlovetox, I thought TTL was supposed to run from receipt
tykaynhas joined
cryptThere will always be a case where one client supports one feature another doesn't. What is an elegant way to solve this? Once, you have that you can dive into specific scenarios.✎
lovetoxyeah but i have the receipe date in the mam message
lovetoxsay i receive a mam message from a year ago with a catchup, and TTL is 1 hour
cryptThere will always be a case where one client supports one feature another doesn't. What is an elegant way to solve this? Once you have that, you can dive into specific scenarios. ✏
lovetoxthen i know it has run out
moparisthebestbut if that's your only client then you miss messages
moparisthebestthe XEP needs to spell out all the edge cases so no one is left guessing what should be done
cryptPeople shouldn't have to ask each other which client, which version are you using.
moparisthebestcrypt, I think that was just for troubleshooting issues
crypt> moparisthebest:
> 2022-04-27 12:39 (CDT)
> crypt, I think that was just for troubleshooting issues
I already do this now with friends a bit in just normal usage.
cryptThey ask: _How do I delete messages after X days?_
cryptI have to tell them their client may not support it.
gooyahas left
cryptDisappearing messages actually would take care of that if both users agree to 1 week retention.
վարյաhas left
վարյաhas joined
lovetoxhas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
lovetoxhas joined
cryptFYI - those friends I'm referring to are ones I'm trying to switch over to XMPP that are familiar with these advanced chat features✎
cryptFYI - those friends I'm referring to are ones I'm trying to switch over to XMPP that are familiar with these advanced chat features on clients like WhatsApp, Telegram, etc. ✏
cryptFYI - those friends I'm referring to are ones I'm trying to switch over to XMPP that are familiar with these advanced chat features on mobile apps like WhatsApp, Telegram, etc. ✏
moparisthebesthave you explained to them that these "advanced chat features" don't actually exist on these other platforms and that they've simply been lied to ?
moparisthebestthat's the correct thing to do
վարյաhas left
վարյաhas joined
marc0shas left
marc0shas joined
crypt> moparisthebest:
> 2022-04-27 12:53 (CDT)
> have you explained to them that these "advanced chat features" don't actually exist on these other platforms and that they've simply been lied to ?
> that's the correct thing to do
I tell we only have basic chat, call, and video functionality. Archive settings depend on the client you're using.✎
Samhas joined
crypt> moparisthebest:
> 2022-04-27 12:53 (CDT)
> have you explained to them that these "advanced chat features" don't actually exist on these other platforms and that they've simply been lied to ?
> that's the correct thing to do
I tell them we only have basic chat, call, and video functionality. Archive settings depend on the client you're using. ✏
cryptI tell them exactly what to expect.
moparisthebestcrypt, right but whatsapp/telegram/signal/etc "disappearing messages" are just a lie on their platforms too right?
moparisthebestso you shouldn't tell them "xmpp is limited here" you should tell them "xmpp is the only one telling you the truth"
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
BASSGODhas joined
cryptI just inform them what the can and cannot do. Works best.✎
cryptI just inform them what they can and cannot do. Works best. ✏
moparisthebestso you leave them ignorant about their previous chat platforms and with the impression XMPP lags behind in features? seems bad
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
mjk"Didappearimg messages" is security though PITA. Because it'a PITA to screenshot or photograph and then OCR the messages that are about to be deleted :D
BASSGODhas left
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
moparisthebestyou mean trivial right?
marc0shas left
marc0shas joined
mjkNo, really, most people won't bother. But there's always a sufficiently motivated adversary with a scanner & tesseract combo ready to go :D
moparisthebestNo one is going to bother with OCR for sure
debaclehas left
moparisthebestBut anyone can screenshot easily
marc0shas left
papatutuwawahas joined
marc0shas joined
mjkNot if the app & os collude against that. The only way would be patching the proprietary binary, or something like that
վարյաhas left
mjkOr modify the os
վարյաhas joined
pep.Then one just need to take a photo of the screen✎
mjkSo, a pain in the ass for a normie
mathieuimjk: other messengers have desktop or web versions
pep.Then one just needs to take a photo of the screen ✏
mathieuiSignal can't prevent me from taking a screenshot of my desktop
moparisthebestmjk, why would that be a pain in the ass for anyone ever ?
crypt> moparisthebest:
> 2022-04-27 12:57 (CDT)
> so you leave them ignorant about their previous chat platforms and with the impression XMPP lags behind in features? seems bad
I sell them on the benefits of using XMPP.
moparisthebestyou need any camera or a mirror ?
վարյաhas left
վարյաhas joined
moparisthebestand to press 1 button
mjkmathieui: hmm. Right, yeah, that would make it trivial, if they have a desktop, that is
BASSGODhas joined
restive_monkhas joined
mjkmoparisthebest: perhaps im judging based on myself :D
pep.> lovetox> altough i could delete it instantly because of TTL run out hm
> but this should be mentioned probably in the spec
It's mentioned in the spec already.
pep."TTL" in the spec is a delay not a timestamp
pep.And it's explained why
msavoritiasWhy are we trying to find scenarios to discredit this spec though? To my knowledge there wasnt this much animosity agaist other specs.
Like http upload or OMEMO
pep.Oh there was :p
ZashYou weren't around then I take it?
pep.But yeah this one particularly
mjkHTTP is evil, down with http!
crypt> msavoritias:
> 2022-04-27 01:06 (CDT)
> Why are we trying to find scenarios to discredit this spec though? To my knowledge there wasnt this much animosity agaist other specs.
> Like http upload or OMEMO
I sense this, too.
pep.mjk: ^5
cryptIt's a feature, not an ethical dilemma.
msavoritiasOh crap so there was?
Please dont tell me the discussions were this ridiculous with the stickers xep too.
msavoritiasYep. We cant guarantee anything with xmpp anyway.
msavoritiasIf we go that route. Everything is best effort
MattJmsavoritias, the difference is that those can be actually implemented
Link Mauvemsavoritias, no discussion happened with stickers AFAIK.
Link MauveI’d like to fix it to be usable eventually.
MattJEphemeral messages cross into a weird territory
mjkmsavoritias: Like how stickers on xmpp won't ever be profitable because you can pirate them in a open ecosystem?
ZashGhost messages!?!
msavoritiasLink Mauve: i half way expected it :P
xeckshas left
xeckshas joined
msavoritiasmjk: no more like who wants this useless thing and its something only for clients.
Sometimes i am surprised with the backlash i see
cryptThink of it as both parties agreeing to a message retention setting. Nothing more. The technicals of how to make work on different clients is the real issue.
Link Mauvemsavoritias, probably more because no one implemented it so far.
վարյաhas left
restive_monkhas left
վարյաhas joined
Andrzejhas left
Andrzejhas joined
L29Ahhas joined
Tobiashas left
Tobiashas joined
MattJMatthew, uhoreg: out of curiosity, what's the story on ephemeral messages in Matrix? Not implemented, right? I think similar challenges would apply, and I suspect any solutions would also probably look similar in both protocols (at a high level).
Ingolfhas joined
mjk> more like who wants this useless thing and its something only for clients.
Well, I'm not really seeing any of that in this case :)
msavoritiasLink Mauve: makes sense. I would like to get involved with it at some time. I am one of the few who would like it
msavoritiasmjk: i know :) was referring to the stickers part
mjkRight
ti_gj06has left
Link Mauvehttps://linkmauve.fr/file_share/DlBQ25o9e3YzgA41ZM9qKM23/UI_EmotionIcon59.png
Link MauveMe too. ^^
Link Mauvemsavoritias, I implemented a sticker selector in poezio, see our release notes: https://bouah.net/2022/04/updates-from-the-poezio-ecosystem/
Link MauveI eventually want to use XEP-0449 instead, but there are things to fix before it is ready.
msavoritiasLink Mauve: ah that looks nice :)
I will install poezio to test it out one of these days
uhoregMattJ: there is some support for setting message retention limits in a room-wide basis, but there's poor client support, so I don't know how much it's actually used. There's also some attempt at making individual ephemeral (regardless of the room settings), driven by location sharing, but I don't really know where it's at. I don't think a satisfactory solution has been found yet.
MattJI think with an open ecosystem it's always going to fall apart at "poor client support", since the default behaviour for any client that doesn't implement the spec is to undermine the whole thing (i.e. just display and store the message forever). Unless you don't send to such clients, which requires servers to jump through hoops and also provides a poor experience to the end user.
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
uhoregIIRC, the message retention limit feature was mostly intended as a way for servers to avoid having to store *everything*, rather than as a privacy feature. (Though I wasn't involved in the development of that feature, so I could be wrong.)
msavoritiasAgreed. But as with MIX or OMEMO or even the group calls client support is always gonna be a problem.
We should aim at clients supporting this not at how hight bar it is
serge90has joined
Samhas left
Samhas joined
archas left
Andrzejhas left
Andrzejhas joined
mjkLink Mauve: why it is only now that I learn of existence of Xmpp-chan (or whatever is her name)?!
> https://bouah.net/2022/04/poezio-sticker-vp8.webm
Link MauveMiho!
mjkAh, thanks. Low-res display ^^'
Link MauveOw, this VP8 encoding is awful!
Link MauveIntel, come on…
mjkI'll take a look at the vp9 one on a proper 'puter later
xnamedhas left
վարյաhas left
վարյաhas joined
Link MauveThere is also an AV1 version, which is obviously the best of the three. :)
Samhas left
mjkOoh
phoeboshas joined
gooyahas joined
վարյաhas left
վարյաhas joined
MattJmsavoritias, the consequences of clients not supporting group calls is "oh well, group calls don't work". The consequences of ephemeral messages not being implemented (or not being implemented correctly due to accident or malice) is "the sensitive ephemeral messages get stored, potentially forever". That's why it's different.
mjk> Miho!
Some obscure encoding of 5222, or am I seeing too deeply into it? :)
Link Mauvemjk, ask edhelas, I think he was the one who met her first.
mjkAh, ty
Tobiashas left
msavoritiasMattJ: sure. But the cliend as stated can give a sufficient message.
At some point you have to treat the user as not an idiot and able to make their own decisions. I would hate for xmpp to become like signal where user is not asked for anything because they are treated as stupid.
Tobiashas joined
sbachhas left
sbachhas joined
sbachhas left
sbachhas joined
Andrzejhas left
Andrzejhas joined
moparisthebestmsavoritias, I fully agree, which is why it's probably best to teach users that once you send something you lose all control, and only send to people you trust to delete after X if that's what they want
moparisthebestrather than treat the users like idiots and tell them we'll try to delete after X when we absolutely know it won't happen
mjkstrongly suggests pep. to sneak a(n improved) version of this proto-xep under the name _Log retention duration coordination specification_
moparisthebestmjk, literally that would be better
mjkI know :))
moparisthebestthe name is misleading and therefore harmful as-is
pep.If that's all it takes..
Samhas joined
moparisthebestpep., did you see my 3 concrete protocol objections above though?
moparisthebestI can send to standards@ too but email grrr
pep.I'm not on the laptop right now
pep.Will have a look later
marc0shas left
marc0shas joined
moparisthebest+1 (XMPP is great lol)
msavoritiasmoparisthebest: i agree.
tykaynhas left
tykaynhas joined
xnamedhas joined
Tobiashas left
harry837374884has left
Tobiashas joined
Andrzejhas left
Andrzejhas joined
Tobiashas left
վարյաhas left
Tobiashas joined
վարյաhas joined
Tobiashas left
Tobiashas joined
sbachhas left
sbachhas joined
Ingolfhas left
sbachhas left
sbachhas joined
Andrzejhas left
ti_gj06has joined
COM8has joined
COM8has left
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
marc0shas left
marc0shas joined
adiaholichas left
վարյաhas left
վարյաhas joined
crypt> msavoritias:
> 2022-04-27 01:30 (CDT)
> Agreed. But as with MIX or OMEMO or even the group calls client support is always gonna be a problem.
> We should aim at clients supporting this not at how hight bar it is
I'm already seeing _Group Video Chat_ requests for Conversations in GitHub. How are clients going to deal with this new "advanced feature" in the future? How will users know their chatting with someone whose client also supports it?
ti_gj06has left
adiaholichas joined
վարյաhas left
վարյաhas joined
cryptThis is my point about clients being able to announce and discover which features are supported with the people they're connected to.
pep.Seriously though if renaming the thing is going to get it more accepted among developers.. I'm happy to do it. It's still exactly the same to me in the UI though :x
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
phoeboshas left
վարյաhas left
harry837374884has joined
վարյաhas joined
adiaholichas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
cryptClient feature parity is impossible. Feature discoverablity between clients is doable.
ZashTime-shifted feature discovery is HARD.
inkyhas left
վարյաhas left
վարյաhas joined
cryptmoparisthebest was on to something when he said you would have to have different keys for each client that did or didn't support something.
ZashAs in, I accidentally my phone and buy a new one and end up with an app with different features. You try sending something while I'm out shopping. Then what?
cryptThat feature would be limited to that key/client.
marc0shas left
վարյաhas left
վարյաhas joined
marc0shas joined
ZashThen I complain that I'm losing messages and XMPP sucks and can never become popular!!!!!1
cryptDesktop client can only do this for the JID, the mobile client for the JID can do this + X.
adiaholichas joined
debaclehas joined
cryptI'll let smarter people than me figure the rest out.
adiaholichas left
marc0shas left
marc0shas joined
emushas left
վարյաhas left
moparisthebestcrypt, there's this knob between security and usability though, the "features per omemo key" is on the secure but un-usable side, normal users will find their messages missing
moparisthebestif you're curious what the extreme end of that spectrum looks like it's https://github.com/maqp/tfc "just carry around 3 different computers and a custom made octocoupler and have your contacts do the same"
adiaholichas joined
inkyhas joined
mjkhas left
marc0shas left
marc0shas joined
mjkhas joined
cryptHas anyone proposed ideas for how clients will support group chats besides asking the other person if their client support it?
I'm curious how this conversation is going.✎
adiaholichas left
cryptHas anyone proposed ideas for how clients will support group chats besides asking the other person if their client also supports it?
I'm curious how this conversation is going. ✏
lovetox? why would i care if a other client supports group chat
lovetoxor are you talking about some adhoc groupchat with2 friends?
Yagizahas left
cryptI mispoke. Group video chats. A feature currently requested.
adiaholichas joined
tykaynhas left
cryptHard enough to coordinate on a meeting time. Checking that everyone's client supports it will be a nightmare.
Link Mauvecrypt, depends how it is negociated, Jitsi Meet uses XEP-0298, Dino uses XEP-272.
Link MauveBoth are incompatible.
Link MauveIn its disco#info, Dino advertises urn:xmpp:jingle:muji:0.
Link MauveJitsi Meet goes through a less common way, embedding a bunch of extensions in its presence.
adiaholichas left
ZashIf you're all online at the same time then there's no problem, that already works and has worked for 20 years
ZashHarder to know what features will be available in the future since you can't easily transmit information backwards in time.
cryptMy query is in relation to how clients on different platforms will support group video chat and how the users will know the people they invite can also join.
Link Mauvecrypt, if your contacts are online, you get that in their disco#info caps (or in Jitsi Meet’s case in their presence).
phoeboshas joined
cryptIt's related to disappearing messages and any other new client features yet to be implemented.
Link MauveThe different platforms don’t matter on XMPP, the protocol is here to unify that.
Link Mauvecrypt, how is it?
Link MauveMuji has been around since 2009, COIN since 2011, both have been implemented by various clients over the years.
Toxihas left
adiaholichas joined
mjkhas left
mjkhas joined
adiaholichas left
Wojtekhas left
andrewhas left
pep.Is there any document on a deterministic way to generate a MUC JID for n accounts? So that whoever creates it it's always the same
emushas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
marc0shas left
marc0shas joined
Mikaelahas left
pep.https://www.numerama.com/tech/939175-detranges-coupures-de-fibre-optique-en-france-la-coincidence-interroge.html la gauche frappe à nouveau ?
pep.oops! Wrong channel :D
pep.I was wondering why the bot wasn't showing the title.
Toxihas joined
ti_gj06has joined
adiaholichas joined
tykaynhas joined
mjk> Is there any document on a deterministic way to generate a MUC JID for n accounts? So that whoever creates it it's always the same
Since Conversations seem to judt generate a uuid, probably not, so invent one! echo $jids | sort | uniq | sha256sum?✎
mjk> Is there any document on a deterministic way to generate a MUC JID for n accounts? So that whoever creates it it's always the same
Since Conversations seem to just generate a uuid, probably not, so invent one! echo $jids | sort | uniq | sha256sum? ✏
pep.it's not a uuid no it's a random pronouceable word, it's a lot better to handle :p
mjkAh, some separators are needed, maybe look for those in the U+0001-U+001F range
msavoritiashas left
pep.(It's not visible in Conversations but it is in many other clients)
BASSGODhas left
mjkOh, right, I'm confusing with something
mjkGajim recently reimplemented the algo
pep.poezio reuses the part generating the names, I found it nice :)
mjkYea
adiaholichas left
pep.How does Matrix do it?
BASSGODhas joined
վարյաhas joined
Kevhas left
atomicwatchhas left
andrewhas joined
tykaynhas left
Calvinhas left
Menelhas left
chipmnkhas joined
Tobiashas left
Toxihas left
Toxihas joined
andrewhas left
ti_gj06has left
andrewhas joined
cryptI just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of Telegram's secret chat. You can have a normal chat and secret chat with the same contact.
That way you're not trying to add/change an existing conversation thread. And if the person's other client doesn't support it, they won't see the more restrictive conversation.✎
wurstsalathas left
wgreenhousehas left
Sevehas left
mhhas left
cryptI just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of Telegram's secret chat. You can have a normal chat and secret chat with the same contact.
That way you're not trying to add/change an existing conversation thread. And if the person's other client doesn't support it, they won't see or have access to the more restrictive conversation. ✏
Toxihas left
Toxihas joined
BASSGODhas left
mhhas joined
cryptI just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of like Telegram's secret chat. You can have a normal chat and secret chat with the same contact.
That way you're not trying to add/change an existing conversation thread. And if the person's other client doesn't support it, they won't see or have access to the more restrictive conversation. ✏
cryptI just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of like Telegram's secret chat. You can have a normal chat and secret chat with the same contact.
That way you're not trying to change an existing conversation thread's settings. And if the person's other client doesn't support it, they won't see or have access to the more restrictive conversation. ✏
marchas left
beanhas left
cryptI just had a wild idea, for disappearing messages at least... why not create a new conversation with that person that follows those rules? Sort of like Telegram's secret chat. You can have a normal chat and secret chat with the same contact.
That way you're not trying to change an existing conversation thread's settings. And if the person's other client (yes, on mobile... no, on desktop) doesn't support it, they won't see or have access to the more restrictive conversation. ✏
debaclehas left
BASSGODhas joined
wgreenhousehas joined
pep.hmm I'm thinking having a deterministic way to generate a room address may be an issue because not everybody is allowed to create a room on a MUC.
pep.Why can't we have nice things
MattJpep. [22:02]:
> How does Matrix do it?
I'm far from expert, but I think you want to be looking in the direction of https://github.com/matrix-org/matrix-spec-proposals/pull/2199
pep.MattJ, thanks, otherwise I also got some advice on mastodon! https://post.lurk.org/@pep/108206073908492448
pep.Maybe there could be a MUC extension saying "if a user sends an affiliation list to the JID they're trying to join, they can create it and become owner, and the MUC sends mediated invites" But it feels slightly too easy to use to bypass regular MUC ACLs
pep.That is, the JID would need to match the JID generated from the given affiliation list
pep.Giving a read at the matrix thing
pep.Wait it hasn't been merged? That means canonical DMs aren,t a thing yet?
pep.Well as I understand it, 1:1 messaging happens in a room, but one needs to figure out the room address still
pep.So what, one generates it and invites the other?
marc0shas left
marc0shas joined
BASSGODhas left
ZashThey closed it, opened another... different room...
վարյաhas left
վարյաhas joined
ZashThen invited someone else into a DM
pep.I guess that's what happens
crypt> Link Mauve:
> 2022-04-27 03:06 (CDT)
> crypt, if your contacts are online, you get that in their disco#info caps (or in Jitsi Meet’s case in their presence).
I believe you're referring to this. I'll read up on it. Thanks!
https://xmpp.org/extensions/xep-0115.xml
pep.But the permission issue is annoying. Not sure how to get over it
ZashWhat if someone pre-calculates your address and joins there before you?
Steve Killehas joined
pep.That's an issue only if they are allowed to, but yeah
Steve Killehas left
Steve Killehas joined
ZashWhat we do now seems simple, random localpart at the creators local MUC
ZashInvite others.
pasdesushihas left
pasdesushihas joined
pep."yeah but", as you said above, you close it, open another etc. you end up with many rooms
pep.Though.. there might be cases where one does not want to use a particular MUC server.. how to deal with this. (Because of technical issues, or CoC or..)
papatutuwawahas left
BASSGODhas joined
lovetoxhas left
goffihas left
lovetoxhas joined
cryptXEP-0115: Entites Capabilities is awesome ❤️
It's exactly what I was describing and it's already here!
> It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
> Showing a different set of icons depending on the capabilities of other entities.✎
cryptXEP-0115: Entites Capabilities is awesome ❤️
It's exactly what I was describing and it's already here!
> It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
>
> Showing a different set of icons depending on the capabilities of other entities. ✏
վարյաhas left
BASSGODhas left
cryptXEP-0115: Entites Capabilities is awesome ❤️
It's exactly what I was describing and it's already here!
> It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
>
>
- Showing a different set of icons depending on the capabilities of other entities.
- Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones.
- Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3].
- Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4].
- Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests. ✏
cryptXEP-0115: Entites Capabilities is awesome ❤️
It's exactly what I was describing and it's already here!
> It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
>
> - Showing a different set of icons depending on the capabilities of other entities.
> - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones.
> - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3].
> - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4].
> - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests. ✏
cryptXEP-0115: Entites Capabilities is awesome ❤️
It's exactly what I was describing and it's already here!
> It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
>
> - **Showing a different set of icons depending on the capabilities of other entities.**
> - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones.
> - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3].
> - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4].
> - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests. ✏
pasdesushihas left
L29Ahhas left
վարյաhas joined
cryptXEP-0115: Entites Capabilities is awesome ❤️
It's exactly what I was describing with announce and discovery and it's already here!
> It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
>
> - **Showing a different set of icons depending on the capabilities of other entities.**
> - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones.
> - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3].
> - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4].
> - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests. ✏
cryptXEP-0115: Entites Capabilities is awesome ❤️
It's exactly what I was describing with client announce and discovery and it's already here!
> It is often desirable for an XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:
>
> - **Showing a different set of icons depending on the capabilities of other entities.**
> - Not sending XHTML-IM (XEP-0071) [1] or other rich content to plaintext clients such as cell phones.
> - Allowing the initiation of a Voice over IP (VoIP) session only to clients that support Jingle (XEP-0166) [2] and Jingle RTP Sessions (XEP-0167) [3].
> - Not showing a "Send a File" button if another user's client does not support SI File Transfer (XEP-0096) [4].
> - Filtering Publish-Subscribe (XEP-0060) [5] notifications based on advertised subscriber interests. ✏
L29Ahhas joined
marc0shas left
marc0shas joined
Calvinhas joined
Steve Killehas left
BASSGODhas joined
Kevhas joined
Kevhas left
Kevhas joined
Kevhas left
cryptHow can we tell if our client supports XEP-0115? Is it already widely used?
pep.Most if not all do
pep.Check the project doap file in the repo otherwise
chipmnkhas left
xnamedhas left
lovetoxhas left
xnamedhas joined
karoshihas left
adiaholichas joined
BASSGODhas left
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
adiaholichas left
BASSGODhas joined
crypt> pep.:
> 2022-04-27 05:30 (CDT)
> Check the project doap file in the repo otherwise
Thank you! Found support for XEP-0115 in Conversations: https://github.com/iNPUTmice/Conversations/blob/master/conversations.doap
djorzhas left
moparisthebesthas left
cryptAlso found it Monal IM, which my friends use (but not as good as Conversations).✎
moparisthebesthas joined
cryptAlso found it on Monal IM, which my friends use (but not as good as Conversations). ✏
xnamedhas left
BASSGODhas left
cryptWhat's the difference between status "complete" and "supported"? Both Dino and Gajim list XEP-0115 with status "complete".✎
cryptWhat's the difference between status "complete" and "supported"? Both Dino and Gajim list XEP-0115 with status "complete". Conversations and Monal IM have status "supported". ✏
pep.“Can be 'complete', 'partial', 'planned', 'deprecated', 'removed' or 'wontfix'.”
inkyhas left
inkyhas joined
cryptpep.: hahaha - you're right!
BASSGODhas joined
adiaholichas left
djorzhas joined
xeckshas joined
adiaholichas joined
cryptIt seems if clients don't fully support XEP-0115 future "advanced features" could never be discoverable between friends. You'll only hear about X new feature through the app developer in a point upgrade. I guess that's normal.
Matthew> <@_xmpp_MattJ=2fxsf=40muc.xmpp.org:matrix.org> Matthew, uhoreg: out of curiosity, what's the story on ephemeral messages in Matrix? Not implemented, right? I think similar challenges would apply, and I suspect any solutions would also probably look similar in both protocols (at a high level).
https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc2228/proposals/2228-self-destructing-events.md is the exploding msgs spec for Matrix, which we should implement this year
harry837374884has left
harry837374884has joined
Matthew(we’re not using it for ephemeral data like location sharing in the end)
adiaholichas left
krauqhas left
krauqhas joined
stphas left
emushas left
Sergi TsZhas joined
andrey.ghas joined
Sergi TsZHi i need help
Sergi TsZdoes XMPP store E2E keys online like Matrix?