jdev - 2023-05-01

"lovetox> of course members-only would need to be disabled" yeah that's an issue. So I'd rather not use `;password`. "lovetox> otherwise it would probably be easy to add a <token> element to some join presence, and the server could then do its stuff" This sounds better yeah, and a new URI parameter to go with it probably

I wonder if there's a way to combine this to account creation process, but that may be a bit much to ask..

In principle there's no reason that password won't work for that.

I can have a password-protected room + member-only?

Actually it's not what I want.. I just want it member-only

But I guess the password parameter can be reused indeed..

If a token has been issued, the room should be aware

Ah sorry you were talking about account creation

Ah no.

(Still waking up..)

Which kind of backwards compatibility mess do you want? :)

the room is aware of the password, in reality you want exactly what password provides

its just that the server could offer a option to add users as members automatically when they join ✏

and maybe that members dont need to provide a password

Prosody (only?) already adds users as members when they're invited, and these users don't need a password/token ✏

your use case is, when you cannot invite because you dont know the jid

I can have a mix of both

These use-cases don't conflict

(or shouldn't)

they do when you use a password

That's why I'm not sure I want to use a password

because i think members still need to provide the password, in current muc impl

Yes I think so too

but it makes not much sense

why would i add someone to a room as member, and then

One could send the password/token in the invite. Dunno how it's done atm

But it's weird to require both membership and password then

dont allow to join

password should be only for non-members

Yeah so using a password for those is weird

I think we agree

I've used tokens in the password slot before (closed system though), it works fine

Even if the client then bookmarks including the password, I think a server can cope fine with that by just ignoring the already-consumed token because the user is a member.

Do you have a draft spec somewhere for generation? Should I reuse 0050 more or less like it's used in 401 etc.?

Kev, yeah

Combining with signup is something we may want, but I think it would require encoding the while muc jid in a param which is pretty verbose

And possibly two tokens (one for signup one for the MUC)...

"Encoding the while muc jid"? target?

Well you need the jid of the server to register with as well as the jid of the MUC both to be present somehow. Unless the MUC advertises a server to register with I guess

It's just me not understanding the english used here ✏

I guess s/while/whole/

Yes