XSF Discussion - 2018-06-18

updated https://github.com/xsf/xeps/pull/666 by force-pushing

flow: can't install htmldiff, some problems with "markupbase"

I have changed the structure of the document and moved most of the sections out of "use cases", so not sure how useful it can be, probably it is better to just re-read it

Hello

In https://xmpp.org/extensions/xep-0045.html#example-128

Why do you not put the JID in the item tag?

It is in the previous example.

mimi89999, the schema says that <actor/> is optional

I haven't read the text though

flow: I meant the JID in the `<item>` tag. Not in actor.

mimi89999, hmm, maybe anonymous MUC?

No

Hmm... Maybe.

But I didn't see it in the desc.

same effect when user leave non anonymous room. But it does not matter.

for councils consideration https://github.com/xsf/xeps/pull/667

although I’ve found the identity name == localpart thing to be handy for searching in localpart only ;)

jonasw: well that will remain that way

For backward compat reasons

Otherwise I would have just tried to change the servers

To make identity name == room name

daniel: your xep change is missing an actual rationale within the XEP. Also my mobile Chrome OOMed while typing a comment and ate the 90% finished text.

daniel: please add business rules for servers to fill the new name field and for clients to gather the name from the many possible locations.

To be honest, I'm rather opposed to having yet another name field.

We can't even sort out the current MUC name vs description vs topic vs bookmark name

Adding yet another field is counterproductive IMVHO

Ge0rG, my understanding is that this is just the name which is already there

Ge0rG: you can already enter the field. You just can't read it back

daniel: what?

Ge0rG, the problem is that currently, you can’t distinguish MUCs without a name set from MUCs where the name was set to be identical to the nodepart of their JID

You can already enter the room name.

You can't read it

because the name is currently shown in the disco#info identity and that cannot be blank. so services default to the nodepart of the jid

Sorry, I'm not really able to understand complex issues today. Feel free to ignore everything I wrote and wait for my on-list

with daniels change, the name would also be in the disco#info form and you can distinguish the two cases

haven’t you been one of the loudest advocats for Conversations displaying the muc name instead of subject?

Are you saying that comparing the name field with the nodepart is hard?

What's wrong with name in disco info name only? Either the local part is good enough or the client needs to put something useful there when creating the room

Zash, no. but what if the room name is actually the local part?

Ge0rG, that you can’t figure out if a name is unset

Consider me an old fart, but I've never seen a list of the participants as the "room name" as a good thing.

Anyway, this is too complex for me today. Sorry for bothering you.

daniel: In the case of Prosody, there's no difference between not being set and being set to the localpart

meaning what?

you can’t unset it?

setting it to the localpart or "" unsets it

and it returns the localpart if it's unset

right. i think that’s what ejabberd does as well

Shouldn't allowed invites be based on role or affiliation?

it is i guess

It is. I see now.

Add an invisible whitespace, or a LTR Unicode tag to differentiate an unset name from a name that equals the localpart.

As long as that's standardized I'm fine

It's the same amount of ugly workaround logic, with one less field

I’m not sure why we need to optimize for fewer fields

but sure…

Then you could add a boolean field whether the name is the localpart... 🤔

I'm full of awesome protocol ideas.