XSF Discussion - 2024-06-11

5222.de turns private members-only MUCs to semianon public MUCs without sending the appropriate MUC status codes that clients use to inform participants of config changes? Is this a bug or malevolence?

robertooo: > They have also been contacted by one high profile XMPP developer. Maybe you could ask them to share their experience here.

Also, jabber.de had issues since the operator changed, so maybe those issues have been caused by technical issues (no idea if some technical issue could cause those symptoms).

> >> i asked in the spritely project yeah. since it seems something that would be right up their alley > > spritely has nothing to this. so it seems i am on my own :) > They haven't done any pet names application yet? It's surely on their road map ... they have. https://gitlab.com/spritely/brux and gnunet has good support for generating sub keys/identities of a main key. and managing all of them with GNS and selectively exposing information about them. but they dont yet have a social graph thing. where you can make relations between your contacts. or between your contacts and a person making you a request

gnunet had a f2f mode which is a broken version of what i am trying to do but not anymore. the closest thing i have seen now that i think about it is manyverse with the scuttlebut protocol. it allowed you to choose what content you want to seed by the relations of your contacts

i will look into their docs although they are creating a new protocol now because scuttlebutt ended up not good

> I don't think this is about zero-knowledge-proof; also, "asking around" every time someone tries to contact you may have you wait for their responses, by which time the caller has already hung up. It sounds more like you want to collect hashes for the "edge" addresses from all of your contacts, I think i mean keeping the connection sounds impractical yeah. because you want this to be asynchronous. so the "request" would probably be just an envelope that gets forwarded to you so you can act on it whenever you want or you get more information

and a long term observer of the network would know who knows who anyway. i dont think that is in scope as something to protect against personally

i doubt you could anyways

> Either way can end up leaking the social graph. It's not always a given that if A &lt;-&gt; B, that both of them want this to be discoverable by other friends of A or B I don't think there is a way past that. Trivially, if you only have 1 friend, inquiring whether caller X is of distance < N in your graph will reveil that they are/aren't a friend of your friend... ↺

yep. by design :) *but* i do want to have a permission so that it is opt-in to expose your graph like

> A related problem is "private set intersection" thank you for this. seems like another way to go about finding where somebody is in the graph

robertooo: I'm reasonably sure that Conversations would remember that you've send omemo encrypted messages to a room before and not fall back

You will have to have send a message though. You can't join after it has been converted from private to public

I remember writing and testing this feature and I just checked that the code is still there. I have not tested this though in a whole

Obviously the actual functionality will start to break down if you don't see jids anymore. But the omemo enabled button won't silently disappear

> The public server 5222.de is consistently undermining E2E encryption on their server and ignoring all inquiries about it. This is going on for over half a year and is fully conscious on part of the admins. They have also been contacted by one high profile XMPP developer. They periodically turn private group chats into public channels, this of course creates enormous usability issues for users, chats have to be recreated. But onto the security issue. Once the chat turns public E2EE is silently turned off(!) If I enter this chat and try sending a message like before (OMEMO turned on all along) a) Dino will error out "Unable to send message", typical user will then disable encryption b) Gajim will silently disable encryption and send unencrypted message (there's not even an unlocked lock icon or anything like that, completely silent and UI speak "everything is fine"), it will also give "This message was encrypted with OMEMO, but not for your device." for every received encrypted message which will prompt user to tell friends to disable encryption a few things you said i could not reproduce in Gajim and are misleading 1. Gajim shows you on every message the encryption state of that particular message, right there beside the message (if its encrypted there is a shield, if its not encrypted, no shield) 2. Gajim also shows you what the encryption will be *before* you send the message, right bottom corner, shows a lock symbol at all times. 3. It is true that Gajim disables the encryption when the config changes, i opened a issue for that and we will fix that in the next version. The attack vector you describe is a very risky gamble for the attacker, he can gamble on a moment to do this and if he is lucky someone sends a message with value, but after that message the attack is discovered, and hopefully you will change server. The chance is also hight that the attack is discovered bevor any message is sent, because clients normally inform their users if this config change happens, at least Gajim does. ↺

robertooo, how do you know it's a server problem, and not a buggy client which changes the MUC's config without the user's consent?

jonas’: it could be theoretically, I never heard of a client that reconfigures existing MUC to public automatically. I fail to see what the use case for that be.

lovetox, I've seen bugs like that.

> lovetox, I've seen bugs like that. 👀 ↺

(not *exactly* like that, but close enough that I believe that it can happen)

and Hanlon's Razor ("Never attribute to malice that which is adequately explained by stupidity.")

It could also just be server misconfiguration

If you tried to failover prosody to another host but hadn't copied all files first this kind of thing could happen

Holger well for a start I would remove the duplicating behaviour of MUC (and I assume make the server handle all messages consistently by forking them all to the user's clients). the anonymity thing is a separate story; but indeed if we were to go down that route *everything* about the MUC would change, as it can no longer act as a proxy "user" with a single JID

Like I said I don't find that idea all that bad. It has a nice simplicity to it that a MUC is "just another user" - it just happens to imply anonymity.

(The context is MUC PMs being forked to each joined resource by the MUC service.)

That could obviously break traditional use-cases/expectations, but if you'd redesign from scratch then yes.

Apart from the exceptional rule that the server musn't fork MUC messages becoming obsolete, what traditional use cases would that break?

You joining with 3 of your 5 clients and expecting to receive PMs just with those clients that joined.

Ah, I did not think of that scenario to begin with! Thank you!

(But that expectation can already be broken if the PMs are stored to your MAM archive and the other 2 clients receive them from there.)

So if we consider only some of the user's clients being joined to the MUC, the analogous non-proxy situation would be if a user is in a 1:1 chat with someone on only a subset of their clients; is that possible?

When you are engaged in proper 1:1 chat the expectations change

A traditional setup (without extensions for carbon copies/MAM) would allow for 'locking' conversations to a single client. Actually that was kinda the default behavior. But that 'n of m clients are joined' thing is MUC-only.

You would just expect the message to arrive on all 5 devices

Was there any particular motivation to give MUC, and only MUC, that specific features of "a subset of clients can be joined"?

Because that looks a bit like "where the inconsistency started" to me now ✏

The question would be other way round, what was the motivation to allow for multiple clients to join (very early implementations had problems with that).

It seems obvious to me that the notion of a user's clients stops behind that user's server. Other's have no notion of it and therefore a user is or is not joined to a MUC - regardless of any devices. The JID/resource is just auxiliary information which is relevant for things like E2EE

Well that's not how XMPP worked traditionally.

> Was there any particular motivation to give MUC, and only MUC, that specific features of "a subset of clients can be joined"? I wouldn't overthink that too much. This was 20 years ago. User expectations were vastly different

Addressing individual devices was the common case.

Oh okay, I see. I do not grasp the concept then; I actually can't think of the use case where this would make sense.

Join busy muc only on desktop but not on mobile still makes some sense today

Even if it's niche

Daniel oh yes I fully agree; but there is no need to mangle this into the higher specification of a MUC. If we want a remote-server-side filter of a user being joined into a chat (MUC or 1:1 alike by that analogy) we could design it orthogonally.

(and thus to work with both 1:1 and MUC alike)

Sure. But I guess that can help you understand why that feature was build

Well yes, and thank you. But even though it is in retrospect I think back then keeping the analogy MUC<->1:1 clean and free of (needless, because orthogonally designable) "special MUC semantics" would have been better.

I don't understand the point you are trying to make. Would we design it differently in 2024 then in 1999? Yes. Obviously

The point I wish I could make is that straightening this out should be possible now and fairly contained (although, obviously, not backwards compatible).

Clean up the MUC<->1:1 analogy, remove special behaviour from MUC, simplify the code -> break traditional usecases & add the subset-of-clients-joined semantics in a new XEP

MIX is a clean slate approach with no or questionable backwards compatibility

ManDay: Designing 1:1 and MUC to be the same thing is what Matrix did, and then you run into the issue that actually they're not the same thing.

All right, fair enough. If MIX is more than a pipedream, the messiah, sure, wait it out :)

(as a user :p)

Whereas here I run into the issue that not all my clients upper-case the first char of my nick.

> ManDay: Designing 1:1 and MUC to be the same thing is what Matrix did, and then you run into the issue that actually they're not the same thing. I know only of some superficial issues concerning classification and UX; are you thinking of something more profound? Anyway, this is not at all what I have in mind here: The MUC is still distinct in that it is a "proxy user"; just like it is designed now. It's got nothing to do with 1:1 being a special case of MUC! ↺

Well I think MUC is perfect except for UX issues as well :D

I'm not proposing something vastly different. Just remove the inconsistency with the message duplication: A MUC is handled (almost) like a single (proxy) user.

Holger PMs being broken -- that inconsistency as a whole -- did not sound like an UX issue only!

(One Matrix issue is that users expect just a single conversation per contact, whereas designing 1:1 as a group allows for multiple.)

Yes, that's the classification problem I meant.

But at the core, technical level, handling things *simply* (either like Matrix: "All chats are n:m"; or like XMPP: "All chats are 1:1") has a great merit.

And MUC does that, like 95% and is only inconsistent for the remaining 5%, which has the observed ramifications like PMs are broken.

I'm not convinced. Everything is a group sounds like simple design. If that design forces you to go "if (this_isnt_really_a_group) then assert_unique() and disable_admin_featured() and whatnot()" then the end result isn't obviously simpler vs. designing them as distinct cases.

1% which would require special handling is to interpret the resource of a MUC PM as not subject to fusion like the resource of a normal 1:1 chat, though

I'm not saying it's obviously worse. Just that designing a chat protocol isn't simple even if you take today's expectations as given, and assuming them not to change in the future.

Holger refering to matrix with "everything is a group"? Because in XMPP I propose the opposite.

Yes.

But that's enough philosophy for me for today.

The PM issues are known and everyone will agree that it should be fixed one way or another.

Ok, well in the case of Matrix I think the *differences* between 1:1 and n:m are actually additional, orthogonal semantics; therefore it's best to work on a unified basis. For example, the expectation that for 1:1 chats you only have 1 room per user is perfectly orthogonal, on top of n:m chats.

All right.

the PM issues and xmpp not having burner jids are linked imo

because the whole reason you have MUC PMs is because you want to talk without knowing the JID

but what if you could create or use a burner/anon jid on the fly and drop them in a 1:1 chat that has a time limit to destroy itself after a bit

Yes. But for some reason many people love the idea of having anon _groupchat_ specifically.

well we could just use burner jids for MUCs too ;) burner jids all the way down

MSavoritias fae.ve well the MUC does have a Degree-Of-Freedom left to encode PMs (setting type=chat, I understand), so we can aswell use it.

It's not wrong, imo. The MUC spec essentially defines new DOFs/modes for the MUC "proxy user": Everything which is useful in a group conversation. "Whispering" is one that sounds natural to have.

Burner IDs seems like a concept which can be isolated to the client<->server part of the protocol and never touches server<->server, but MUC semantics (i.e. the modes like whispering) are happining between server<->server, too ✏

> well we could just use burner jids for MUCs too ;) burner jids all the way down yes, we just need to do some implementing :)