XSF Discussion - 2018-06-18


  1. labdsf

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

  2. labdsf

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

  3. labdsf

    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

  4. mimi89999

    Hello

  5. mimi89999

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

  6. mimi89999

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

  7. mimi89999

    It is in the previous example.

  8. flow

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

  9. flow

    I haven't read the text though

  10. mimi89999

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

  11. flow

    mimi89999, hmm, maybe anonymous MUC?

  12. mimi89999

    No

  13. mimi89999

    Hmm... Maybe.

  14. mimi89999

    But I didn't see it in the desc.

  15. karp

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

  16. daniel

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

  17. jonasw

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

  18. daniel

    jonasw: well that will remain that way

  19. daniel

    For backward compat reasons

  20. daniel

    Otherwise I would have just tried to change the servers

  21. daniel

    To make identity name == room name

  22. Ge0rG

    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.

  23. Ge0rG

    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.

  24. Ge0rG

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

  25. Ge0rG

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

  26. Ge0rG

    Adding yet another field is counterproductive IMVHO

  27. jonasw

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

  28. daniel

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

  29. Ge0rG

    daniel: what?

  30. jonasw

    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

  31. daniel

    You can already enter the room name.

  32. daniel

    You can't read it

  33. jonasw

    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

  34. Ge0rG

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

  35. jonasw

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

  36. daniel

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

  37. Zash

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

  38. Ge0rG

    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

  39. daniel

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

  40. daniel

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

  41. Ge0rG

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

  42. Ge0rG

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

  43. Zash

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

  44. daniel

    meaning what?

  45. daniel

    you can’t unset it?

  46. Zash

    setting it to the localpart or "" unsets it

  47. Zash

    and it returns the localpart if it's unset

  48. daniel

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

  49. mimi89999

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

  50. daniel

    it is i guess

  51. mimi89999

    It is. I see now.

  52. Ge0rG

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

  53. daniel

    As long as that's standardized I'm fine

  54. Ge0rG

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

  55. daniel

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

  56. daniel

    but sure…

  57. Ge0rG

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

  58. Ge0rG

    I'm full of awesome protocol ideas.