jdev - 2022-12-17


  1. pep.

    Old question: is there any concrete reason why a MUC component shouldn't host a room on a bare domain jid? Apart from historical reasons / "it's more or less like this in the spec" etc.? Maybe there are resources on this? it's definitely not the first time this is asked

  2. pep.

    https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat maybe this should be in here somewhere.

  3. pep.

    Also are new-ish MUC extensions/improvements referenced somewhere?

  4. lovetox

    whats a bare domain jid

  5. lovetox

    mucservice.com?

  6. pep.

    yeah

  7. lovetox

    so the whole component can only host a single room?

  8. pep.

    no, it would still be possible to create room@muc.service

  9. lovetox

    ? why are you not continuing my example

  10. lovetox

    and use something totally different now

  11. pep.

    Is it really important?

  12. lovetox

    you mean room@mucservice.com?

  13. pep.

    Yes

  14. lovetox

    so a disco on mucservice.com returns all kind of things

  15. Zash

    not xmpp:muc.example?join ?

  16. lovetox

    its a muc component, but also a room

  17. lovetox

    but also hosts accounts

  18. pep.

    lovetox, why accounts

  19. pep.

    Basically I'm asking if the concept of "MUC component" is necessary

  20. lovetox

    How do you create a room if you dont know the jid of the muc component?

  21. pep.

    Well you know because you are given the adresse of one, either disco#items from the server, or some other user

  22. lovetox

    no disco items would not return anything anymore

  23. pep.

    Why not

  24. lovetox

    you just said "do we need the concept of a muc component"

  25. lovetox

    so you are questioning if this should exist

  26. lovetox

    if something does not exist anymore it cant be in disco info

  27. pep.

    Well clients still need something they know they can create rooms out of, so yeah I'm still doing to give them a JID to do so

  28. pep.

    Well clients still need something they know they can create rooms out of, so yeah I'm still doing to give them a JID to do so from

  29. lovetox

    sie and that jid is called "component"

  30. lovetox

    so yes we need that

  31. pep.

    But that's the only thing one needs right?

  32. pep.

    If this jid is actually a room doesn't matter, does it

  33. pep.

    Because the client is likely to try to create foo@muc.service instead of just joining muc.service

  34. Zash

    pep., so are you talking about having rooms without nodepart or not?

  35. lovetox

    depends, last time we discussed this there is no way to differentiate between a room and a muc component

  36. pep.

    Zash, yeah

  37. Zash

    I find it very unclear what this is about

  38. pep.

    I'm wondering if I should make a different in my component project at all between the jid without nodepart and others.. It does look like a pointless distinction from the component PoV

  39. Zash

    There ought to be a disco#info thing that means "I am a room" and a different disco#info thing that means "I allow creating rooms"

  40. pep.

    lovetox, ok then I guess that's settles it?

  41. pep.

    Zash, hmm

  42. lovetox

    as i said there is no way to detect a component

  43. lovetox

    no client would join mucservice.com

  44. lovetox

    because you returned it in disco items as a component

  45. lovetox

    i cant join a component

  46. lovetox

    its not a room

  47. pep.

    lovetox, well that's just because they haven't been implemented to do so, doesn't mean it's not possible

  48. pep.

    (And actually poezio does)

  49. lovetox

    yeah you can do anything, the question is, is there a reason beyond "hey im a special snowflake and i want to create rooms that half of the clients cant join"

  50. lovetox

    there is nothing wrong with room@group.service.com

  51. lovetox

    its clear for everyone, it separates concerns

  52. Zash

    what if you wanted to build a thing where you have user@host and #group@host ?

  53. Zash

    (like, say, irc transports)

  54. pep.

    Zash, please don't do that (differenciating by JID :p)

  55. Zash

    Biboumi already does, no?

  56. pep.

    No

  57. pep.

    Well, yes..

  58. pep.

    Yes

  59. pep.

    :(

  60. pep.

    But it's mapping IRc..

  61. pep.

    But it's mapping IRC..

  62. Link Mauve

    “15:41:14 lovetox> ? why are you not continuing my example”, perhaps because this is a porn website. :D

  63. Zash

    Doesn't have to encode into JID, could have the server keep track of whether a thing is a user or room. Maybe even both? But best not.

  64. Zash

    "I only have this dyndns hostname and can't have subdomains" is something that comes up every now and then

  65. pep.

    So.. in summary, a client still needs a place that tells it "You can create rooms here"?

  66. pep.

    And that's about it?

  67. pep.

    It can also be a room though

  68. pep.

    It would have both roles

  69. Zash

    Maybe we get rid of that entirely and move to an iq stanza directed at something advertising the corresponding feature, with the room JID returned in the result

  70. lovetox

    yes, if your question is technical nature, yes its possible

  71. pep.

    Zash, I thought about that also yeah

  72. Zash

    Then we can get rid of the weirdo locking flow

  73. Zash

    (but we keep the regular flow ;))

  74. pep.

    (Yeah we like flow)

  75. pep.

    0045 doesn't have this thing that says "you can create rooms here" right? It's generally assumed that one can do so on a bare domain JID

  76. pep.

    Because

  77. Zash

    http://jabber.org/protocol/muc + conference/text or somesuch?

  78. pep.

    Well yeah but a room would also have that right?

  79. Zash

    eh, rooms have that too

  80. pep.

    Ah and /list is also done on the component generally

  81. pep.

    Does disco#items on a room do anything?

  82. pep.

    It doesn't look like it

  83. pep.

    lovetox, Zash, https://wiki.xmpp.org/web/index.php?title=XEP-Remarks%2FXEP-0045%3A_Multi-User_Chat&type=revision&diff=14249&oldid=13072 does this look correct? Any comment?

  84. MattJ

    pep. [15:28]: > Does disco#items on a room do anything? It is supposed to list occupants, but most servers/rooms disabled it for privacy

  85. pep.

    hmm

  86. pep.

    So this one feature would conflict?

  87. Zash

    Why would it?

  88. Zash

    Or, why would it not conflict as much as XMPP does with itself already?

  89. Zash

    You pretty much have to disco#info each item anyway to find out what it is

  90. Zash

    It could be commands, it could be rooms, it could be pubsub nodes, who knows‽

  91. lovetox

    but disco items on the component, lists rooms usually

  92. pep.

    What lovetox says. If a JID is both a room and a component, that is.. it's a room and it allows room creation

  93. lovetox

    pep., in general we should avoid any situation where a thing is 2 things at once in my opinion

  94. lovetox

    it only leads to trouble

  95. pep.

    lovetox, I agree. And it's sad that this one thing conflicts :/

  96. lovetox

    xmpp has often the problem that without disco info you cant know what a thing is, adding now on top that even if you disco, it is multiple things at once is a new kind of bad

  97. pep.

    Are there any others things that would conflict?

  98. lovetox

    basically everything that you direct at the jid, needs then special handling by the server

  99. lovetox

    you would need fuse responses with results from both entities

  100. lovetox

    like adhoc commands for example, probably one of the easier things

  101. lovetox

    i cant imagine that any server can support this by default or?

  102. pep.

    can support what?

  103. lovetox

    room and component as the same jid

  104. pep.

    Prosody supports room creation on the bare domain jid

  105. lovetox

    i didnt say nobody supports it

  106. lovetox

    i said its not supported by default, you probably need to add special handling at many places to make it possible

  107. pep.

    In prosody, I don't think so no

  108. nicoco_

    Speaking of a thing being two things at once, now that I do MUCs in slidge, gajim lists them under ‘rooms’ and not ‘gateways’ anymore. Is it just a UI thing, or is there anything wrong with a component having both a gateway and a muc service identity?

  109. lovetox

    how would you know? did you design the prosody architecture :D

  110. pep.

    lovetox, I haven't enabled anything in particular to be able to create the room.

  111. pep.

    nicoco_, probably one of the identities is used and not the other. Maybe the MUC identity is served first

  112. pep.

    A client would have to be able to deal with this combination of identities

  113. nicoco_

    Biboumi is also in Rooms - which makes more sense because it’s mostly rooms and also it does not require any ‘subscription to the component’ AFAIK

  114. pep.

    Wait so it's possible to get a list of occupants with disco#items? Without running the 4 iqs? :P

  115. pep.

    Ah, presence not affiliations

  116. nicoco_

    Anyway it does not alter the functionality at, probably separating ‘MUC services’ from ‘gateways’ is ambiguous in the first place.

  117. pep.

    I guess I'm personally willing to dismiss this one feature (getting an occupant list via disco#items, especially if most servers don't do it) as it's possible to get this list by joining.

  118. pep.

    And I'd rather have people join to get this kind of information

  119. pep.

    https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Why_do_I_need_to_host_my_MUC_component_on_subdomain.example.org%3F ok then, I updated it. It's weird mix of two different but related things I feel, but I think most info is there.

  120. flow

    personally I believe that MUC JIDs should always consists of a localpart and a domainpart and no resourcepart. and that a MUC service domainpart should not also be a domainpart that hosts ordinary users

  121. flow

    the motivation for the first constrain is that it makes it easy for clients to validate that the entered string is in fact probably a valid MUC address, leading to better UX

  122. flow

    and I had a technical reason, not just a philosopical one like "separation of concerns" for the second constraint. Yes I know that it is technical possible to do that, but it IIRC caused me some other technical trouble

  123. flow

    if you don't write everything down, then you are doomed to forget it…

  124. lovetox

    im not sure the wiki should list whats technical possible, and rather list good practice

  125. lovetox

    Its good UX that users can see with one look, if a adress is a groupchat or not

  126. lovetox

    i dont see why anyone would actively take steps to prevent that

  127. pep.

    "Its good UX that users can see with one look, if a adress is a groupchat or not" you can't do that "in one look". You need to disco it anyway, it could be a user account otherwise

  128. pep.

    And I would very much like not to restrict what a jid should look like either. I'd rather have clients disco

  129. lovetox

    of course you can

  130. lovetox

    gajim@conference.gajim.org

  131. pep.

    That could be a user

  132. lovetox

    see, one look you did it :)

  133. pep.

    And that could be a room

  134. lovetox

    pep., you gould be a GPT3 chatbot

  135. lovetox

    im still talking to you though

  136. pep.

    Be serious one second

  137. lovetox

    think about what argument you want to make

  138. pep.

    What are you trying to make me say

  139. lovetox

    mine is, everyone should choose descriptive subdomains so users can easily discover what things are

  140. pep.

    Yeah I disagree that things should be separated as "subdomains", I disagree that this should even be exposed to users anyway

  141. pep.

    Some know, (you, me), and that's fine

  142. pep.

    I think sticking to subdomains is slightly shortsighted

  143. lovetox

    how so?

  144. lovetox

    how was it shortsighted of the gajim server, to choose conference as its subdomains for MUCs for the last decade?

  145. pep.

    Joinjabber doesn't have a user host, and will certainly never have one, it's standalone

  146. Link Mauve

    lovetox, to most users, this is an email address.

  147. Link Mauve

    A weird one, since it doesn’t end with @gmail.com though.

  148. lovetox

    it is not, because if you go out of context, you need to attach schemes

  149. lovetox

    and because of great forsight, someone added xmpp:

  150. Link Mauve

    To most users, mailto: is a weird prefix they don’t understand at all.

  151. pep.

    Well then if you trust the source you got the address from, xmpp:?join tells you it's a room. What more do you need

  152. Link Mauve

    Don’t assume just because a JID has conference. in its domain, that users will understand it’s a MUC.

  153. pep.

    And you're proably going to disco it anyway because you need to

  154. pep.

    (for other reasons)

  155. Link Mauve

    pep., ?join is a good indicator, but not every URL producer manages to add it correctly.

  156. lovetox

    it does not matter if a client disco or not

  157. pep.

    Link Mauve, sure. I'm arguing for discoing really :)

  158. lovetox

    this is not about clients

  159. Link Mauve

    disco#info on the user-provided JID is the best you can do really.

  160. lovetox

    its about how you choose your domain

  161. lovetox

    and maybe we should not chose gajim.org

  162. pep.

    Who cares about the domains. Why would it matter to users

  163. lovetox

    because maybe behind gajim.org is in fact something different

  164. pep.

    (it's fun because I could see you make the exact same argument saying domains don't matter)

  165. lovetox

    yeah why not use IPs

  166. Link Mauve

    Ok, I’m out of this discussion.

  167. pep.

    No I meant, "since domains don't matter, why not to restrict them anyway". Is what I had in mind for you

  168. pep.

    But yeah I guess I'm also out

  169. lovetox

    ok haha im looking forward to your next domain

  170. pep.

    Really is it just UX that you're trying to improve with this?

  171. pep.

    If so I honestly don't understand

  172. lovetox

    with what? choosing a fitting domain name

  173. lovetox

    sorry are you for real?

  174. pep.

    hmm?

  175. lovetox

    are you arguing people should not choose fitting domain names anymore

  176. lovetox

    because we cant trust that befor we click on it, it really is what it says it is

  177. pep.

    We're not talking about the same thing are we

  178. lovetox

    yes, we are, half of the day you try asking why and how its technical possible to NOT name your component domain after what it is

  179. lovetox

    a muc service

  180. lovetox

    and then you tried to argue, we cant trust the name, so why name it

  181. lovetox

    as i was asking, im not sure where you want to go with that

  182. lovetox

    every sane person will name its muc service, group.domain.org

  183. lovetox

    conference.domain.org

  184. pep.

    Every sane person will know you disco a JID

  185. lovetox

    and it not a argument, that there exists a person out there, that doesnt know what a conference is

  186. lovetox

    pep., we are talking about UX for users

  187. lovetox

    not about clients and what they do

  188. lovetox

    a client is a computer program

  189. lovetox

    a domain name means NOTHING to a computer programm

  190. lovetox

    its a series of bytes

  191. pep.

    You're trying to much. I doubt your users ever care about this

  192. pep.

    I certainly wouldn't

  193. pep.

    I mean, I like it when it looks pretty

  194. pep.

    It doesn't have to look like a MUC jid because there is no such thing as a MUC jid

  195. lovetox

    i guess goole should not have used groups.google.com

  196. lovetox

    im sure people hate it that groups.google.com leads to google groups

  197. pep.

    Right, too bad it's a mailing list and not a MUC component

  198. pep.

    (Snikket named their MUC component groups.)

  199. lovetox

    oh no !

  200. lovetox

    its simple, if i have the chance to give something a name, i will, and thats the whole story

  201. lovetox

    you seem to have the opinion, no i want to hide that it even exists

  202. pep.

    Whether I want to or not, to know if a thing is a thing I need to disco it anyway

  203. pep.

    So there's that

  204. lovetox

    no pep. users dont disco anything

  205. pep.

    Users don't need to know what it is, they give it to their client

  206. pep.

    They can't use it without a client anyway

  207. lovetox

    ok, so i guess have fun with having your 10 components on the same domain

  208. pep.

    Did you not me see trying to list conflicting features earlier.

  209. lovetox

    tell me how it goes

  210. pep.

    To try and avoid it

  211. lovetox

    ok, so you can give something a name, but rather then just giving it the name what it is, you say, wait i dont want to name it, i rather think a few hours how not nameing it can lead to problems

  212. pep.

    I say there's no need to restrict it arbitrarily if identities don't conflict, yeah

  213. lovetox

    nobody restricts anything, everyone is just pratical, we can give it a name, it has only benefits if something is named after what it is, just name it and everything is good

  214. pep.

    Of course it's an arbitrary restriction. Why a sudomain, why not two. Why not only "muc." why not the "muc" tld

  215. lovetox

    i think we established that there is no restriction

  216. pep.

    No, you did on your own

  217. lovetox

    nobody restricts you to jump of a bridge, but i guess you will not do it because its not very practial for your future plans

  218. lovetox

    this discussion feels like it

  219. pep.

    ><

  220. pep.

    Seriously I should have stopped this chat 1h ago

  221. pep.

    It feels pointless

  222. lovetox

    ok then lets stop, i will watch TV now :)

  223. lovetox

    have a good night