jdev - 2023-08-02

about occupant-id calculation

real jid + room jid + secret, should work?

and the secret does not need to be per room, it could be one secret for the whole server

lovetox, it could be, but then IDs would be the same if a room is destroyed and then recreated and occupied by different users

(or the same users, it doesn't actually matter)

hm not sure this is a problem?

you are still not able to find out from the hash the real jid, it does not matter how often you recreate the room

room destroyed, recreated by new owner, who could then verify a occupant-id→jid relation

lovetox, how do you find the jid from the hash?

I mean technically a server could do occupant-id == jid, but I doubt anyone is going to do this

pep., that would be very bad and a violation of the xep

> Additionally, a MUC service SHOULD generate the identifier such that the occupant identifier of a user in one room of the service does not match the occupant identifier of the same user in another room of the same service.

Ok but that wasn't my question

I was trying to understand your message

the goal of the xep is to have a anonym identifier, recreating the room, makes the identifier not less anonym

so why would it need to change?

Zash, your argument i would counter with, a new owner sees the real jid anyway, he does not need to unmask occupant-id

Yet another thing that should be removed :(

I don't understand why room owners/moderators need to see real jids

> real jid + room jid + secret, should work? Why not just generate it randomly though ↺

per room?

> I don't understand why room owners/moderators need to see real jids To ban them across other rooms right? :) ↺

> per room? Yes ↺

yes of course this would be even better, my question was about the minimal necessary impl

moparisthebest, I only need the nick for this, and it's easy enough to see it's the same person

Not necessarily, and especially not enough to add to rtbl

I guess I'd be ok for something like a rtbl to require operator intervention

You can't prevent muc service from seeing jid unless you use anonymous JIDs of some kind

singpolyma, yeah, occupant-ids :)

> yes of course this would be even better, my question was about the minimal necessary impl 1. Generate a random secret per room 2. HMAC(occupant real JID, room secret) 3. ??? 4. PROFIT! ↺

(Even though I agree that's not perfect, it's not addressable etc.)

pep.: No, occupant id is just a new privacy leak for non moderators in semi-anon rooms. Does nothing for what the service itself sees

pep., imagine a flag you set when you join that swaps the occupant id and the nickname

good news, ejabberd implemented a first draft of occupant-id

Zash, not sure I understand. Actually same for singpolyma

pep.: occupant id provides more info about room participants to all other participants. It is a privacy leak vs not having it

pep., in the future, we could use do an opt-in thing that makes occupant JIDs be room@muc.host/occupant-id, via a flag you set in your join presence

The room service still must see the jid with or without occupant id

then we can slowly move to that being the default

Zash, ok yeah. That's a discussion I'd be happy to have. (I don't want these defaults but the direction is somewhere around there)

singpolyma, yes the room service still sees it, but that's server operator level, not any moderator

Zash: yes, that's a very interesting direction for sure. I'm already sending user nickname in muc presence along similar thoughts

and how is the nickname communicated ?

XEP-0172 probably

<nick/>

how does a nickname change work then?

New presence with new <nick>

you can write a new muc xep :)

you probably send a new stanza with a new nick

and then ever so slowly we turn MUC into MIX without anyone noticing!

lovetox, it doesn't really deviate from MUC fwiw, that's just an improvement on it

Like the many other MUC extensions

That every one rediscovers every so often after having praised MIX because it did it and not MUC

singpolyma, I'm not dead set on occupant-id fwiw, an id that contains less info is also good to me :)

there aremany flows in muc that depend on the nickname

Isn't random per room much easier than anything with hmac or anything else at all?

it would be a pretty huge extension, that you even need to make backwards compatible

eventually we'll have a pile of MUC extensions that effectively turn it into MIX, and then moving to MIX might be easier.

no then it becomes even less likely

the problem with nobody moving to mix, is cost/benefit

I agree with lovetox :P

make MUC more like MIX and this ratio gets worse

> I agree with lovetox :P i screenshot that

> I guess I'd be ok for something like a rtbl to require operator intervention pep.: The main contributor to rtbl is a muc hosted on a server without the server operator being involved at all :P ↺

Maybe that's an issue? Dunno

Generate a random secret per room <-- why per room and not simply for the whole server deployment?

badlop: because then a user can identify the same user across rooms

This isn't IRC where 1 user is the same across all rooms on a server

> room destroyed, recreated by new owner, who could then verify a occupant-id→jid relation ↑ ↺

aha! ok

moparisthebest, the MUC jid is generally included in there too, so it's not the same id across the service ✏

where "new owner" would be someone who was previously not allowed to see the real jid

How does a client detect it's a "new room" with a new owner?

they're suddenly the owner of it

They don't have the same occupant-id? :x

They've received a <destroy/> payload before for this room

Clients could also just regenerate occupant-id every so often, and on every nick change at least

On the other hand, one could just prevent rooms from ever being recreated, solves a bunch of problems.

> They've received a <destroy/> payload before for this room And on that ↺

Clients don't generate occupant-id?

MUC does

And their client hasn't registered it and is still rejoining the room

What's lovetox talking about generating then

Didn't someone wonder just the other day why a room they destroyed was suddenly populated by new users and new owner?

moparisthebest, i was interested for the server impl

Aaahhhh

because i wanted to support badlop in implementing this for ejabberd

MUC rooms has configuration options, which would presumably be as persistent as the room. Easy enough to stick a hidden config option with the per-room secret there.

yes Holger had the same idea, and i proposed it

this would make it very stable, and survives, restore procedures, and moving to other machines etc, as long as you backup your database