XSF Discussion - 2023-01-05

ugh i remember that too now, i don't think i've even solved that entirely correctly yet

qy, there shouldn't be anything for a client to solve these days

It is weird how they end up in MAM but won't be Carbon'd though

But everything about MUC PMs is weird

it's the differentiation between muc and pm, which i don't think i've done robustly, i thought of an edge case this morning but i can't remember it now

Ideally in my opinion it shiuld work like this in semi anon rooms: 1. Person wants to message another person privately in a semi annon room. They click a button or type pm and then the nickname if the person. 2. In the background the client creates a new ephemeral xmpp id and creates a room for tne two people linked to the previous room optionally. 3. Both people are dropped in the room with their temporary xmpp ids. When they leave the room the xmpp ids are automatically discarded and the room destroyed.

Ideally of course. This requires burner jids to be implemented too

Which should be the default for semi anon rooms anyway imo

that seems more clunky than even normal MUC-PMs on first sight (especially in the multi-client scenario), what's the advantage?

While we're on MUC PMs. While I agree MUC PMs are weird and I'd rather use direct messages, I'm always hesitant to say "Don't use them, just use direct chat messages". First because semi-anon rooms are still a thing so in practice it doesn't work, not everybody knows everybody else's JIDs. And then, why should they? (know everybody else's JIDs). There's still some unresolved things I find about having separate identities on XMPP. Creating yet another account isn't also very practical (even though it may currently be the best way to have separate entities) :/ ✏

Burner JIDs are cumbersome, though I would like to see them used one day

Hmm. I was thinking that this way there is a room and actual jid/xmpp ids involved. Instead of inline things in tne chat going to nicknames

having to restart a new session for each JID is a pain from a client perspective, frankly

So the seperation is clearer

especially if you want to go the 1 JID = 1 MUC route

mathieui, all that handled transparently for the user yeah :P

> mathieui: > having to restart a new session for each JID is a pain from a client perspective, frankly I wonder if that would be solved with xmpp over quic

I don't think the transport changes anything here

MSavoritias (fae,ve), but I would cut out a room in that case, if it's just 1:1

you still need to do SASL everytime

let the participants use burner JIDs on both ends and have a 1:1 communication, without a MUC inbetween.

that works much better with multi-client setups (even though I have no clue how burner JID + multi-client could work)

Ah yeah. Sorry i meant room in the matrix way 😅

I see

I would rather have something like wrapped payloads inside the main session

Yeah for sure. 1:1 chat i agree

That would reveal your domain

i still don't see what the benefit of burner jids is here

then you just have to figure out how to do multi-client burner JID in a way that admins are not incentivised to block those from s2s communications (as you are with SASL ANON)

they're useful, but not for MUC PMs

and we're good to go

singpolyma, burner jids still are on the same domain anyway right? It's a given that your domain is revealed

> qy: > i still don't see what the benefit of burner jids is here Because to drop two users in a 1:1 room you need to show some jid

To my knowledge

pep., semi-anon MUC PMs as of today do not reveal your domain.

^

pep.: right. So doesn't work for the semi Anon MUC pm case

pep., you could provide burner JIDs as a third-party service

(I guess)

mathieui, who would do that?

mathieui, yeah you could just like you could provide sasl anon but barely anybody does that

buuut you end up with the same issue as anon auth services

Why cant the jid be completely randomized.

which nobody does unrestricted because of abuse

I wouldn't expect SASL ANON to ever be allowed to federate.

MSavoritias (fae,ve), because it needs to be routed

> buuut you end up with the same issue as anon auth services Not if you auth to the burner service from your real jid. Same as MUC PM at that point

jonas’, I do, in controlled environments. anon.jabberfr.org is allowed on some other services

exactly

Give real jid to service X, they send traffic onwards

but then I don’t see the point of having burner JIDs if you could have MUC PMs instead

Then we need to seperate the generation of jid and routing to what we show

mathieui; exactly ✏

why solve hard problems when you have an easy one at hand

MSavoritias (fae,ve), unlikely to ever happen within XMPP

Maybe the xmpf server the user is using can act as a proxy

Yeah probably

mathieui: I think some people want jid->bare jid translation to always work? ✏

Do be honest though even if it leaks only the domain its still better than exposing the actual jid

as in, to be stable and not depend on nickname?

MSavoritias (fae,ve): those are the same in my case

If, "if", we every manage to make it like MUC PMs are not a pain anymore, I'd see JIDs in MUC replaced by something like occupant-id fwiw. Even for moderators

And for many people

qy, singpolyma, that's what MIX gives, fwiw

(full-anon again!)

lol, MIX

proper addressing of participants

one of the key issues with MUC which cannot be solved within MUC

Would mixake it easier to do pms?

MSavoritias (fae,ve), verily

jonas’, "proper"? With the 4-in-3 thing?

pep., well, better in any case

done right, the 4-in-3 isn't as bad

"cannot" seems strong

qy, you'd have to redo the entire addressing scheme of MUC

don't we already have several ideas for stable ids?

you can also do MIX then. ✏

stable IDs are nice and all, but not if they're not JIDs

and addressable as JIDs

but they can be

there's no concept I know of for *addressable* stable occupant IDs in MUC

They're not addressable as JIDs outside of the MUC. They could be

Stable IDs sort of defeats the point of an anon room, no?

not even within the MUC

So either we make MUC into MIX or adopt MIX

singpolyma, depends on your use case

there are use cases where you want stable, but anonymous ID, and use cases where every visit should have a different ID

Yeah. And stable but "annon" ids also have their place

no need to differentiate, as long as they remain routable, they can be changed as often as liked

Registered nicks then ;)

e.g. in programming@, I'd be content with a stable identifier which cannot be mapped back by the general public to my real JID

qy, good, make a concept for that :-). and also how resources fit into that.

and make sure to read the corresponding MIX specs, because they have that already

i've moved to the camp that prefers to update MUC rather than adopt MIX, for guessable reasons

qy, especially then you should also look at the prior art in MIX

i'm just suggesting ideas. I have no stake in this

If it changes that much i dont see the point of trying to redo half of how the muc works. But 🤷

Realistically, MUC PM has been working fine for decades and any change will have an inertial problem

Not that change is always bad, but yeah

singpolyma, "fine" :P

Much bigger problem, if it's a problem but it seems more like one, is MUC nick iq. I realize the possible solutions are similar

Maybe there should be a document that defines clearly what's wrong with MUC PMs

(if there isn't already)

Yeah if we change muc that much that it needs a migration path (identifiers and pms) then its a problem anyway

As a first step

But of course a full solution to that will probably result in many bugs that essentially leak the jid, so bah. I mean, my jid is public but as a matter of culture many expect theirs not to be

singpolyma, "MUC nick iq"?

jonas’: sending an iq from one muc participant to another

singpolyma, my public JID is public, my other non-public JIDs aren't :x

singpolyma, ah yes, that's doomed

MIX fixes that :-X

pep.: do you use your public jid for joining public rooms?

jonas’, does it? There's still an issue with leaking info right?

pep., leaking info?

well if you reply to IQs, you need to be careful what you reply with to whom ✏

jonas’: does mix fix the problem where even in a non anon room the room could be lying to me about what people's JIDs are? ;)

that's irrespective of the transport used for that

singpolyma, no, and thinking about that hurts my head

Yeah that's a non-issue to me

For this matter

jonas’: yes but usually with an iq you can assume the other side knows your jid

it becomes a significant issue when you think about MUC-OMEMO

Except with MUC

Needs more e2ea

Or at least s2ea

I think we can dissociate anonymity to the MUC and to MUC participants

And maybe solve these in different ways (dunno)

so other than MUC IQs being a thing, i don't personally have an issue with MUC PMs as they stand, but some people would like routable stable addresses in some form; i guess that's the sum of things "wrong" at the moment?

A MUC could pretend to be non-anon and give out burner JIDs at a companion service

singpolyma, indeed

kind of what biboumi does

singpolyma, yeah I was thinking about that

that's actually pretty smart

but!

the companion service would have to translate your JID somehow

and to do that correctly, it needs context

which can be encoded in the JID, but uh

sounds like a fun project

Isn't that context encoding basically what MUC PMs already do?

It would need to know your jid, but could store in a lookup table, or salted hash it, or whatever makes sense for the use case

Probably gonna need a lookup either way

singpolyma, put the JID of both occupants encrypted into the localpart of the burner JID, that should do the trick

plus maybe a random part or hmac of the room JID

Kev, kinda? I have to admit it's not very clear to me what's the difference yet

then you got unique IDs and routing based on the room

jonas’: JIDs have almost no length limit riiiiiiight ;)

1023 bytes should be enough for that

well, they're not

so yeah, you need some lookup

But that's fine the muc already needs lookup anyway

Ok I'll have to reread this and write it down in a way that's understandable :P

Maybe I can implement it in my MUC component

Yeah it's similar to what MUC currently does because it still has to go through MUC, as opposed to burner JIDs. I don't know if it improves things compared to what MUC currently does though.

pep., it does if we can make it so that bare JID === identity

which is not the case in MUC currently and that causes a lot of headaches

hmm

Really someday I want to stop relying on resources for nicknames, and either use item@nick (but that's not used by other participants right? Just for nickname changes?) or 0172

the funny thing is, i kinda want things to go the opposite direction

How?

(and why?)

namely in biboumi, i'd ever so slightly like it to more mirror MUC PMs as things stand, but then also for the sake of consistency i'm ok with how it is

Well IRC doesn't have this concept

pep., what is "item@nick"?

yeah ofc, but my point is i'd rather solidify the state-of-affairs than create some other system

<{muc#user}x><item nick="foo"/></x>

ah, that

Hi all, the XSF Board meeting is starting now: https://wiki.xmpp.org/web/Board-Meeting-2023-01-05

✨✨

Firefox on Android kept joining and then "error! Trying to reconnect!" But the jitsi app from f-droid worked fine

I tried twice on firefox at the beginning and gave up as it was chocking as soon as I connected :(

Just found this via a twitter bot: https://www.gsocorganizations.dev/organization/xmpp-standards-foundation/

moparisthebest: I totally forgot to offer you to speak on the Editor automation topic. Do you want to follow-up here?

emus: I don't really have anything, jonas’ wants a language update I can get to soon and then hopefully it'll be ready to merge

I put thoughts on the other issue in there but haven't tried to write a POC or anything

Other issue being getting rid of the attic as it currently exists

moparisthebest: Okay alright, thanks!