XSF Discussion - 2022-04-27

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

> Alice's client sends […] It may not even be online (and most likely isn't if it's an iOS device).

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

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

> 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!"

Would it be interesting to expose the account creation date ?

For spam purpose it could be interesting

But also for clients to know when the user joined the network

edhelas, so the server is injecting it then ?

Of course the servers can lie about it

Lies, on the Internet? UNPOSSIBLE

edhelas, I'd rather not encourage that :/

edhelas, some servers don’t have this information.

Regarding the ephemeral messages ... What will happend with CC, if like exposed msavoritias, we have a mix of client supporting or not that feature? ✏

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.

👌

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

Voting with your wallet or labor isn't the same as democratic.

I dunno why all free software should be democratic or not though, there are lots of different governance models.

Forcing a maintainer to implement or maintain something they don't want certainly isn't democratic

It's free software, that's the entire point, you do what you want with it

Of course not, who said it was?

moparisthebest: no they're not democratic for most, you vote with your skills

Skills anyone is free to aquire

That'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?

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

Who said anything about school

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

Everyone doesn't have equal access to education indeed, nor has the time for it because $job

Relevant: https://postmeritocracy.org/

pep.: So those people should force others to do their whim or?

It's an exchange

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

> As a developer I also benefit from people using my software. In what way?

MattJ: I hadn't (I think) seen that, thanks.

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.

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

Only if the changes benefit you though, no developer would make changes that helped others but hurt them

It depends

What do you value most. Your own (software) comfort or do you value more collective goals

I still think everyone that uses software can and should know how to program

Just like everyone who drives a car should be able to change the oil and change the tire etc

If you are too lazy and/or busy fine but you are the one that will suffer, your choice

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

Mumble mumble everyone that has kids should know how to raise them grumble

Honestly 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

From MattJ 's link: > We have an ethical responsibility to refuse to work on software that will negatively impact the well-being of other people.

The 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?

I actually think it's not about unsaying something on The Internet but about unsaying something on your own phone.

No responsibility without compensation!

You can always delete from your own device

Conversations even implements this, no XEP required

Conversations defaults to "Never delete"

Every single client out there defaults to that, I think

Yes. But an auto delete automates this and does this on a per chat and a per message basis

We already have message retractions. Don't we have some time-delay thing, AMP or whatsitcalled?

Daniel: an autodelete?

pep.: where's your PRs to change the default? And/or forks

> 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

Or just think of it as time-delayed message retraction, with exactly the same blbubrbl somethig words

moparisthebest: from a quick ask around, they're all gonna be refused

moparisthebest, you think of the use case that you want to delete something because you want nobody to see it out of shame or whatever

but in my work for example i often just delete messages, to not confuse people because i said something wrong

pep.: Then fork, and ask your contacts to switch

and dont want to write 3 messages to take it back

moparisthebest: lol

lovetox: we already have that right?

Not sure if serious

"Fork all clients and make your users switch"

and pep. spec say that?

i doubt it highly :)

That spec doesn't mislead users into thinking that no one will ever see the original ✏

and thats already again the wrong argument

no user reads XEPs

XEPs are standards for implementing features by developers

not Users reading what the client does or not does

Right, 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?

we dont have a ethical obligation to hurt users

what are you talking about

XSF needs to provide standards for clear use cases

To avoid hurting users

no ..

to give devs a way to implement something

and not everyone needs to invent something themself

If we have an ethical obligation to avoid doing things to hurt users, why do we have specs for military usage

Why did we deprecate xhtml-im and _xmppconnect etc? Because they hurt users right?

> 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

I wasn't the one to say it :p

pep.: military helps users that's why :)

Hah

moparisthebest, _xmppconnect, because its not secure, no client who implements the spec can do it in a secure way, so its not sound

pep.: Ukraine shouldn't have military? How would that work out?

lovetox: so same with ephemeral messages then?

every client can implement message deletion and educate its users in a honest way

so no not at all the same

With server side mam and multiple clients they can't

and thats the point

at the one side you have something that cannot be done technically

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

on the other side *you* think that people going to do bad things

and you think you need to save users

The only honest thing a client can do is say "I can delete my own messages locally and that's it"

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

moparisthebest, you can say "we will ask the other client to delete the message"

and thats all people want :)

lovetox: as devs we know that's all they can have, I think they actually want something else

crypt, this is already how it works, mostly.

but thats not the problem of the xsf, its the problem of client devs

there can well be a messenger that is a walled garden and enforces what the user wants

and they then need a protocol for it

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.

lovetox: XSF doesn't make XEPs we know are impossible to implement though

but its not impossible, you fighting a strawman, the xep does not say "This standard guarantees that all messages are deleted forever"

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

if it would say this, of course i would be with you

I specifically did not want to say this

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

Sure.

You might have to open an issue to your client(s) bugtracker if you want this though.

Pretty sure I've seen a setting to disable advertising of software used (XEP-0092) ✏

I’d like https://github.com/dino/dino/pull/1180 to be merged someday. :<

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

I 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…

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

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

This would be the most user friendly approach to have disappearing messages or anything that comes next.

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.

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

something that is also a problem is MAM

say i delete a message from my client

Problems!

https://cerdale.zash.se/s/a7R6KUAQVxO4u6v809h4nf7q/6a7dd1ad-dd16-4c32-8a2b-242dc325e2e3.png

a month later i install on another machine, it downloads MAM, and all messages are again in my client

(from https://what-if.xkcd.com/140/ )

altough i could delete it instantly because of TTL run out hm

but this should be mentioned probably in the spec

lovetox, I thought TTL was supposed to run from receipt

yeah but i have the receipe date in the mam message

say i receive a mam message from a year ago with a catchup, and TTL is 1 hour

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

then i know it has run out

but if that's your only client then you miss messages

the XEP needs to spell out all the edge cases so no one is left guessing what should be done

People shouldn't have to ask each other which client, which version are you using.

crypt, I think that was just for troubleshooting issues

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

They ask: _How do I delete messages after X days?_

I have to tell them their client may not support it.

Disappearing messages actually would take care of that if both users agree to 1 week retention.

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

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

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

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

I tell them exactly what to expect.

crypt, right but whatsapp/telegram/signal/etc "disappearing messages" are just a lie on their platforms too right?

so you shouldn't tell them "xmpp is limited here" you should tell them "xmpp is the only one telling you the truth"

I just inform them what they can and cannot do. Works best. ✏

so you leave them ignorant about their previous chat platforms and with the impression XMPP lags behind in features? seems bad

"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

you mean trivial right?

No, really, most people won't bother. But there's always a sufficiently motivated adversary with a scanner & tesseract combo ready to go :D

No one is going to bother with OCR for sure

But anyone can screenshot easily

Not if the app & os collude against that. The only way would be patching the proprietary binary, or something like that

Or modify the os

So, a pain in the ass for a normie

mjk: other messengers have desktop or web versions

Then one just needs to take a photo of the screen ✏

Signal can't prevent me from taking a screenshot of my desktop

mjk, why would that be a pain in the ass for anyone ever ?

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

you need any camera or a mirror ?

and to press 1 button

mathieui: hmm. Right, yeah, that would make it trivial, if they have a desktop, that is

moparisthebest: perhaps im judging based on myself :D

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

"TTL" in the spec is a delay not a timestamp

And it's explained why

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

Oh there was :p

You weren't around then I take it?

But yeah this one particularly

HTTP is evil, down with http!

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

mjk: ^5

It's a feature, not an ethical dilemma.

Oh crap so there was? Please dont tell me the discussions were this ridiculous with the stickers xep too.

Yep. We cant guarantee anything with xmpp anyway.

If we go that route. Everything is best effort

msavoritias, the difference is that those can be actually implemented

msavoritias, no discussion happened with stickers AFAIK.

I’d like to fix it to be usable eventually.

Ephemeral messages cross into a weird territory

msavoritias: Like how stickers on xmpp won't ever be profitable because you can pirate them in a open ecosystem?

Ghost messages!?!

Link Mauve: i half way expected it :P

mjk: no more like who wants this useless thing and its something only for clients. Sometimes i am surprised with the backlash i see

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

msavoritias, probably more because no one implemented it so far.

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

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

Link Mauve: makes sense. I would like to get involved with it at some time. I am one of the few who would like it

mjk: i know :) was referring to the stickers part

Right

https://linkmauve.fr/file_share/DlBQ25o9e3YzgA41ZM9qKM23/UI_EmotionIcon59.png

Me too. ^^

msavoritias, I implemented a sticker selector in poezio, see our release notes: https://bouah.net/2022/04/updates-from-the-poezio-ecosystem/

I eventually want to use XEP-0449 instead, but there are things to fix before it is ready.

Link Mauve: ah that looks nice :) I will install poezio to test it out one of these days

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

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

IIRC, 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.)

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

Link 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

Miho!

Ah, thanks. Low-res display ^^'

Ow, this VP8 encoding is awful!

Intel, come on…

I'll take a look at the vp9 one on a proper 'puter later

There is also an AV1 version, which is obviously the best of the three. :)

Ooh

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

> Miho! Some obscure encoding of 5222, or am I seeing too deeply into it? :)

mjk, ask edhelas, I think he was the one who met her first.

Ah, ty

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

msavoritias, 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

rather than treat the users like idiots and tell them we'll try to delete after X when we absolutely know it won't happen

mjk, literally that would be better

I know :))

the name is misleading and therefore harmful as-is

If that's all it takes..

pep., did you see my 3 concrete protocol objections above though?

I can send to standards@ too but email grrr

I'm not on the laptop right now

Will have a look later

+1 (XMPP is great lol)

moparisthebest: i agree.

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

This is my point about clients being able to announce and discover which features are supported with the people they're connected to.

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

Client feature parity is impossible. Feature discoverablity between clients is doable.

Time-shifted feature discovery is HARD.

moparisthebest was on to something when he said you would have to have different keys for each client that did or didn't support something.

As 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?

That feature would be limited to that key/client.

Then I complain that I'm losing messages and XMPP sucks and can never become popular!!!!!1

Desktop client can only do this for the JID, the mobile client for the JID can do this + X.

I'll let smarter people than me figure the rest out.

crypt, 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

if 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"

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

? why would i care if a other client supports group chat

or are you talking about some adhoc groupchat with2 friends?

I mispoke. Group video chats. A feature currently requested.

Hard enough to coordinate on a meeting time. Checking that everyone's client supports it will be a nightmare.

crypt, depends how it is negociated, Jitsi Meet uses XEP-0298, Dino uses XEP-272.

Both are incompatible.

In its disco#info, Dino advertises urn:xmpp:jingle:muji:0.

Jitsi Meet goes through a less common way, embedding a bunch of extensions in its presence.

If you're all online at the same time then there's no problem, that already works and has worked for 20 years

Harder to know what features will be available in the future since you can't easily transmit information backwards in time.

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

crypt, if your contacts are online, you get that in their disco#info caps (or in Jitsi Meet’s case in their presence).

It's related to disappearing messages and any other new client features yet to be implemented.

The different platforms don’t matter on XMPP, the protocol is here to unify that.

crypt, how is it?

Muji has been around since 2009, COIN since 2011, both have been implemented by various clients over the years.

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

https://www.numerama.com/tech/939175-detranges-coupures-de-fibre-optique-en-france-la-coincidence-interroge.html la gauche frappe à nouveau ?

oops! Wrong channel :D

I was wondering why the bot wasn't showing the title.

> 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? ✏

it's not a uuid no it's a random pronouceable word, it's a lot better to handle :p

Ah, some separators are needed, maybe look for those in the U+0001-U+001F range

(It's not visible in Conversations but it is in many other clients)

Oh, right, I'm confusing with something

Gajim recently reimplemented the algo

poezio reuses the part generating the names, I found it nice :)

Yea

How does Matrix do it?

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

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

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

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

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.

Why can't we have nice things

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

MattJ, thanks, otherwise I also got some advice on mastodon! https://post.lurk.org/@pep/108206073908492448

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

That is, the JID would need to match the JID generated from the given affiliation list

Giving a read at the matrix thing

Wait it hasn't been merged? That means canonical DMs aren,t a thing yet?

heh, indeed it's not a thing, the PR says

It that because there's no 1:1 messaging? ✏

Well as I understand it, 1:1 messaging happens in a room, but one needs to figure out the room address still

So what, one generates it and invites the other?

They closed it, opened another... different room...

Then invited someone else into a DM

I guess that's what happens

> 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

But the permission issue is annoying. Not sure how to get over it

What if someone pre-calculates your address and joins there before you?

That's an issue only if they are allowed to, but yeah

What we do now seems simple, random localpart at the creators local MUC

Invite others.

"yeah but", as you said above, you close it, open another etc. you end up with many rooms

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

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

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

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

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

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

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

How can we tell if our client supports XEP-0115? Is it already widely used?

Most if not all do

Check the project doap file in the repo otherwise

> 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

Also found it on Monal IM, which my friends use (but not as good as Conversations). ✏

What'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". ✏

"supported" isn't valid. https://linkmauve.fr/ns/xmpp-doap#

“Can be 'complete', 'partial', 'planned', 'deprecated', 'removed' or 'wontfix'.”

pep.: hahaha - you're right!

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

> <@_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

(we’re not using it for ephemeral data like location sharing in the end)

Hi i need help

does XMPP store E2E keys online like Matrix?