jdev - 2023-10-29

  1. lovetox

    if someone knows C++ and wants to do some good in the XMPP eco system, check https://codeberg.org/poezio/biboumi/issues/3468

  2. Link Mauve

    lovetox, could you write some text about that in the disco#info identities registry?

  3. lovetox

    maybe we need some kind of list of little fixes to various clients and servers that can be done by non-experts with the codebase

  4. Link Mauve

    I’d feel much better about that if it was actually vetted by the standards.

  5. Link Mauve

    The second change though sounds perfectly sensible, I’m surprised it isn’t done yet.

  6. pep.

    Is it possible to have more than one identity btw? How is it defined to mix identities together? Is it the sum of both, or is it that expectations for one of the two identities are changed? (one would be "complementary" to the first)

  7. lovetox

    you can be more than one thing pep. simply as that

  8. lovetox

    and yes its definitly allowed and used

  9. pep.

    Is it possible to have more than one identity btw? How is it defined to mix identities together? Is it the sum of both, or is it that expectations for one of the two identities are changed? (one would be a modifier for the first)

  10. Link Mauve

    pep., yes, you can have as many identities as you want.

  11. pep.

    That doesn't answer my other question

  12. pep.

    So they're all to be taken separately?

  13. lovetox


  14. lovetox

    you are the sum of your disco info

  15. lovetox

    i see it like adding more detail

  16. pep.

    What I meant by sum is: You are identity1, so it's possible to issue operations that identity1 would/should support, and you are also identity2, so it's possible to issue operations that identity2 would support, and the two don't mix

  17. pep.

    And you're saying yes to both here :P

  18. pep.

    Which to me are somewhat exclusive

  19. lovetox

    yes i think you can say that, every identity stands for its own and for caps that you have

  20. lovetox

    but you get still value out of interpreting the sum of it

  21. Zash

    What are identites even? Doesn't features advertise what operations you support?

  22. lovetox

    features are only for additional things

  23. pep.

    In practice I agree that identities may be used to display pretty images

  24. lovetox

    not for one the base standard defines

  25. pep.

    And features to the rest

  26. lovetox

    hm no forget what i said, i think thats incorrect

  27. lovetox

    for biboumi example its a good example to have multiple identities

  28. pep.

    And features do the rest

  29. lovetox

    its a MUC service, so spec says to have a identity of "conference"

  30. lovetox

    but its also a gateway, so it needs that identity as well

  31. pep.

    I think with my question I wanted to make it clear wether this was gonna be a thing just for biboumi or a more generic thing for other IRC gateways (that may not have the same interface at all mind)

  32. pep.

    lovetox, in biboumi though it's not possible to create channels on irc.gateway.org though right? (unless fixed_server is set, but let's put this aside for a moment)

  33. pep.

    So having it being declared a MUC wouldn't help?

  34. pep.

    ircserver@irc.gateway.org is the MUC component

  35. lovetox

    hm i have no opinion on that, but it cannot be both

  36. lovetox

    we have to decide

  37. lovetox

    either the domain is the component, or the server jid

  38. pep.

    Sorry what cannot be both?

  39. lovetox

    and currently its both

  40. pep.

    Ah, sure maybe

  41. lovetox

    last time people in the MUC came to the conclusion, that the domain should be the MUC service

  42. pep.

    Well when fixed_server is set, ircserver@gateway doesn't exist anymore

  43. lovetox

    yeah, so makes sense that the domain is the service, because it always exists or?

  44. pep.

    Well if you use the muc identity to decide whether you can create channels and all, I find it weird to put it on irc.gateway.org when you actually can't (fixed_server not set)

  45. pep.

    Just like you'd ask for "account.org" to have a MUC identity because "muc.account.org" is a MUC service

  46. pep.

    They're different jids

  47. lovetox

    yeah but both domains

  48. pep.

    Does it matter

  49. lovetox

    and thats fine, account.org points in its disco items to muc.account.org

  50. pep.

    A component could host various components for all we know

  51. pep.

    Just on a single jid

  52. lovetox

    the real problem which needs to be solved is that ircserver@gateway.org needs to make it clear that it is not a joinable MUC

  53. lovetox

    thats what we try to solve

  54. pep.

    Yes indeed

  55. pep.

    To me that's where the muc identity should be. "I'm a component"

  56. lovetox

    thats not possible

  57. pep.

    Why not?

  58. lovetox

    if you define this JID as the MUC service, then the MUC spec says you MUST add the muc identity

  59. lovetox

    meaning its impossible to know anymore its not a MUC

  60. lovetox

    exactly where we are right now

  61. pep.

    Maybe that's an issue with 0045 then?

  62. lovetox

    so the idea is, to say its *not* the MUC service

  63. lovetox

    pep., of course its a initial issue with the MUC spec, but nobody else puts muc services on a JID with localpart

  64. lovetox

    *only* biboumi does that

  65. pep.

    Until the next gateway

  66. lovetox

    so instead of changing the whole world, how about we change just biboumi

  67. lovetox

    yeah sure you can wait another decade, maybe a second gateway shows up

  68. pep.

    And then I come back to my first question, are disco identities supposed to influence on each other or are they just two separate identities

  69. lovetox

    it does not matter for the biboumi fix, because the main fix is not putting gateway on the domain

  70. lovetox

    its about the ircserver@domain.org jid

  71. lovetox

    and there we dont need multiple identities

  72. lovetox

    i propose a completely new identity for that one

  73. pep.

    So basically you're "fixing" MUC here, by having a "component" identity which doesn't exist

  74. lovetox

    no, as said above im not of the opinion that the server jid is the component

  75. lovetox

    the component for me is clearly gateway.org

  76. pep.

    Well I'm reading the issue and you suggest using <identity type='irc-server' name="ircserver" category='component'/> on the ircserver right?

  77. lovetox

    right, but thats not fixing MUC, thats adding a identity which respects the IRC world

  78. pep.

    I disagree that it is IRC specific here

  79. pep.

    I mean it shouldn't be

  80. pep.

    It's just that the MUC service is on ircserver@

  81. lovetox

    but i guess you cant name another gateway where this is the case

  82. lovetox

    > It's just that the MUC service is on ircserver@ you are saying that like its a fact

  83. pep.

    Well it is?

  84. lovetox

    i dont know, i guess if you are so sure about it, you can name the definition of a MUC service and tell why its not gateway.org

  85. pep.

    Whatever, do your changes as you like, it seems as usual this is going nowhere

  86. lovetox

    ? i asked for your reasoning, as you seem sure about it

  87. lovetox

    im sure many are interested, as for all other people i talked to it, its not a clear cut case

  88. lovetox

    i personally dont care much about the solution, i just want to know that ircserver@gateway.org is *not* a MUC

  89. pep.

    > When multiple identity elements are provided, the name attributes for each identity element SHOULD have the same value. Is seems that's the only thing I could find regarding multiple entities in 0030 fwiw.. §3.1

  90. pep.

    It doesn't say what should be expected from them, if/how both should interact

  91. lovetox

    does it describe how multiple features interact with each other?

  92. pep.

    > This information helps requesting entities to determine the group or "bucket" of services into which the entity is most appropriately placed ^ I guess though judging by how an identity is defined, I'd argue the multiple identities probably shouldn't be related to each other. It's weird though because obviously if multiple identities are defined on an entity there is certainly some kind of relation. Unless.. economy of JIDs? :/

  93. pep.

    lovetox, reading

  94. pep.

    I guess features are defined in the specs they come from, and if they need to interact with each other I would also expect that to be defined there and not in 0030

  95. lovetox

    and who defines that a identity of conference needs to be added to a muc service?

  96. pep.

    I guess for this issue I don't really mind how it's done. The only thing I'd be annoyed about is if in the end we had a pseudo-generic stuff that only applies to biboumi. We might as well have an <identity type='biboumi' category='biboumi' /> :x

  97. pep.

    lovetox, for muc I guess it's 0045. for type='irc'/category='conference', I don't know

  98. lovetox

    the problem is biboumi violates the first requirement the XEP tries to solve

  99. lovetox

    > Each room is identified as a "room JID" <room@service> (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.

  100. lovetox

    this alone would prompt me to remove the conference identity from the server jid

  101. pep.

    Yeah I still think this requirement is unfortunate (to use kind owrds)

  102. pep.

    Yeah I still think this requirement is unfortunate (to use kind words)

  103. lovetox

    why? because in some decades there is a single gateway that has in theory (not practically) a problem with that?

  104. lovetox

    or are you aware of any gateways that were not realized because of this requirement?

  105. pep.

    Because I think this is an arbitrary constraint and that we could do without

  106. Link Mauve

    How does it work with other gateways for protocols which also have a username/domain split?

  107. Link Mauve

    I’m thinking of ActivityPub, Matrix, email, stuff like that.

  108. pep.

    lovetox, there could be a feature instead of this constraint, or an identity :)

  109. Link Mauve

    Does it make sense to standardise type='irc-server', rather than type='legacy-service-server' for instance?

  110. pep.

    "Hey I'm a MUC service" "Hey you can create rooms here" "I'm a room, you can join me"

  111. pep.

    Atm all MUC rooms/services contain both the identity and the muc feature..

  112. lovetox

    its not necessary pep. even without these features, its by the standard clear whats a room and what not

  113. pep.

    That's a great way to differenciate them (not)

  114. lovetox

    its room@service by the standard

  115. lovetox

    no need for identity

  116. pep.

    Yeah and I'm saying this restriction is dumb. I'd rather see an identity or a feature instead so there is no arbitrary jid restriction

  117. lovetox

    i very muc like that its clear that after the @ is the service

  118. pep.

    As Link Mauve says it may work in the XMPP world but it certainly fails as soon as we bridge to other networks

  119. Link Mauve

    Even for XMPP, if you have a j2j gateway you end up with the same issues.

  120. Link Mauve

    Possibly even worse since you can chain those.

  121. pep.


  122. pep.

    Say I don't have control over my dns (sad, but still), and I'm given a single domain, how do I even have components spawning a whole subdomain

  123. moparisthebest

    Your server doesn't use DNS for components, you can name them whatever you want (obviously only works for local users)

  124. pep.

    Yeah only locally

  125. singpolyma

    I don't know that any new identities are needed or whatever. The main issue is just that biboumi advertises that the server JIDs are joinable MUCs, which obviously they are not, so that just needs to be removed

  126. pep.

    singpolyma, no they can't just be removed because that's also a way to advertize that you're a muc service

  127. pep.

    Well if you're a muc service in 0045 you're also technically "just" a domain jid. But this rules out chat@dino.im and possibly many gateway'd addresses as mentioned earlier

  128. lovetox

    pep., dont know what you mean chat@dino.im is perfectly fine with the XEP0045 spec

  129. pep.

    it's not, because dino.im is an account domain and not a muc service

  130. lovetox

    thats an entirley different topic, and there is no spec that says a domain cannot be both

  131. pep.

    chat@dino.im is actually the muc service

  132. lovetox

    ? thats the support chat of dino

  133. lovetox

    certainly not the mucservice

  134. pep.

    lovetox, I remember you vehemently arguing that a domain should not be both :P

  135. pep.

    lovetox, it's both. Prosody's muc component allows the muc service jid to be joined as other rooms

  136. pep.

    lovetox, it's both. Prosody's muc component allows the muc service jid to be joined like other rooms

  137. Zash

    pep., that's not exactly what happens there tho

  138. lovetox

    i think you confuse a few things now

  139. pep.

    Zash, isn't it?

  140. lovetox

    before the topic was ircservice@mucservice.org vs mucservice.org

  141. pep.

    lovetox, no I meant, a while back

  142. Zash

    it's a component that handles a single bare JID, but it's still a bare jid

  143. lovetox

    no, it was always about that, the conversation started with me posting the biboumi issue, and thats exactly whats described there

  144. Zash

    the barely legal thing that should be a secret is a different case

  145. singpolyma

    > singpolyma, no they can't just be removed because that's also a way to advertize that you're a muc service They are not (cannot be) a MUC service so it is impossible for them to advertise that

  146. Zash

    Isn't one of the problems here that there's no distinct identity/feature for "I am a chat room" vs "I have a list of chat rooms"

  147. lovetox

    singpolyma, pep. is of the opinion that it is the mucservice

  148. singpolyma

    Yeah, prosody allows joining bare domain, but this is a spec violation technically

  149. pep.

    Zash, this yes

  150. singpolyma

    lovetox: well, it's not :)

  151. Zash

    singpolyma, it shouldn't be, but it's not really relevant here :)

  152. singpolyma

    Zash: I would ok with it not being a violation but we'd need to edit the xep for that and it barely seems worth it for such an edge case

  153. pep.

    And yes, irc.gateway.org isn't the MUC service, it's solvely an interface to the gateway

  154. pep.

    And yes, irc.gateway.org isn't the MUC service, it's solely an interface to the gateway

  155. Zash

    The only practical requirement for a MUC room or MUC service should be lack of resoure part.

  156. pep.

    singpolyma, "such an edge case" comes up a bit too often in the discussions imo

  157. singpolyma

    I don't remeber if having no MUC service is allowed, I don't think it technically is

  158. pep.

    Zash, I'm of the opinion that the only requirement should be a disco feature :P

  159. pep.

    To prepare for when we finally get rid of resources in MUC

  160. Zash

    pep., that's called MIX

  161. pep.


  162. pep.

    MIX is a different set of problems

  163. singpolyma

    You can maybe say that IRC.example.com isn't a MUC service. But you *can't* say that blah@irc.example.com *is*.

  164. Zash

    I don't see MUC without resources, I see MUC without nicknames encoded in resources

  165. pep.

    Zash, hmm, maybe. I'd hear you out :)

  166. pep.

    singpolyma, only because of this weird requirement of 0045?

  167. Zash

    pep., whereby we just swap places of occupant-id and nickname

  168. pep.

    That's really the only thing that's missing

  169. singpolyma

    Because of the definition of a MUC service, which is found in 0045 yes

  170. pep.

    Ok then I think this argument is dumbfunded and that we just need to change MUC

  171. wgreenhouse

    singpolyma: irc.example.com is a muc service--it just has some entities as well that aren't MUCs :P

  172. pep.

    Because really ircserver@gateway is the component..

  173. singpolyma

    Maybe we can change MUC, but until we do its simply the truth

  174. pep.

    Because really ircserver@gateway is the service..

  175. Zash

    Still praying for Someone™ to write that "how to discover a thing in XMPP" XEP

  176. singpolyma

    wgreenhouse: that's fine. I don't much care either way if it is or isn't

  177. Zash

    singpolyma, you underestimate the power of implementers

  178. singpolyma

    > Because really ircserver@gateway is the service.. It is factually not

  179. pep.

    wgreenhouse, hey, that's not untree

  180. pep.

    wgreenhouse, hey, that's not untrue

  181. wgreenhouse

    singpolyma: also it sounds like single-instance biboumis remove the ambiguity? if I'm understanding the ambiguity?

  182. singpolyma

    I'd be fine to do away with the idea of "MUC service" entirely.

  183. pep.

    Ok I realize it can be seen this way too. A client doesn't need to know the relation between ircserver@ and #channel%ircserver@

  184. wgreenhouse

    (ones that are locked to one target irc network for the entire component)

  185. Zash

    multi-component-connection biboumi when? :)

  186. singpolyma

    wgreenhouse: they remove the bug in biboumi yes

  187. lovetox

    > Ok I realize it can be seen this way too. A client doesn't need to know the relation between ircserver@ and #channel%ircserver@

  188. lovetox

    halleluja :)

  189. pep.

    lovetox, that doesn't solve your issue

  190. lovetox

    of course it does

  191. pep.

    Still I think what is being discussed here is really biboumi-specific and I still don't like it

  192. wgreenhouse

    Zash: similar to what slidge does?

  193. lovetox

    biboumi shoud remove the identity and its fine

  194. singpolyma

    > biboumi shoud remove the identity and its fine Yes

  195. Zash

    wgreenhouse, I don't know what slidge does

  196. wgreenhouse

    Zash: I think it publishes a separate component address for each foreign network the admin has chosen to allow, e.g. signal.example.org etc.

  197. lovetox

    thats what is weird about the discussion, you propose to change the SPEC and the whole ecosystem when the only problem is that one irc service provider out there adds a illegal identity

  198. pep.

    Actually, I may still hold onto ircserver@gateway is the component, because otherwise you can't have a client create rooms from the domain jid

  199. Zash

    wgreenhouse, but does a single process handle all of them?

  200. pep.

    Because it lacks the info on what IRC server the room is to be created

  201. wgreenhouse

    Zash: not sure

  202. pep.


  203. Zash

    and could it do that over a single connection? (no protocol for this I think)

  204. lovetox

    pep., thats a solved problem, read XEP-0100

  205. lovetox

    the gateway service can communicate the way an adress is build

  206. singpolyma

    Zash: component new xep. But no one implemented that yet

  207. lovetox

    and thus the client can offer a user interface to the user

  208. lovetox

    the client does not need to know what a IRC server is

  209. lovetox

    or how the IRC network is build

  210. pep.

    lovetox, do you have an example somewhere for this?

  211. Zash

    singpolyma, 225? yeah nobody asked for it and there are no implementations afaik

  212. pep.

    Zash, I've been asking for it multiple times already :x

  213. pep.

    But 1 person probably isn't enough.

  214. pep.

    But 1 person probably isn't enough to care

  215. singpolyma

    Zash: I keep meaning to, it would be very nice, but keep having other stuff to do heh

  216. pep.

    lovetox, isn't 100 for user login rather?

  217. pep.

    I see "user login" and "contact handling"

  218. Zash

    pep., must have been so long ago I don't remember it then.

  219. Zash

    It's been mentioned twice in my current logs.

  220. lovetox


  221. pep.

    I want 225 for tls but also for the multiple domain delegation

  222. singpolyma

    pep.: the jabber:iq:gateway section

  223. lovetox

    would be even better if this would allow a dataform, but a description field that tells the user to input #channel@irc.server.org

  224. lovetox

    is fine enough

  225. pep.

    That's not defined for IRC? (gateway/irc)

  226. pep.

    The gateway can send an arbitrary form there then?

  227. lovetox

    no, you the client offer the user a filed, and display the "desc" content

  228. lovetox

    after the user puts in his legacy address

  229. pep.

    Ok so that's not enough for biboumi right?

  230. pep.

    You need to know the channel and the irc server

  231. Zash

    > would be even better if this would allow a dataform, but a description field that tells the user to input #channel@irc.server.org ↑

  232. lovetox

    the legacy adress yes

  233. pep.

    Or the user, even

  234. pep.

    lovetox, alright

  235. pep.

    Biboumi implements this?

  236. Zash


  237. pep.


  238. lovetox

    no idea, i just show you this, to tell you that a xmpp client does not need to know about legacy network infrastructure

  239. lovetox

    it provides a legacy address to the gateway, and the gateway sends me the legacy jid

  240. lovetox

    maybe i should elaborate on the main problem with the identity

  241. pep.

    So what's the part about adding a @category='component' in the issue

  242. lovetox

    the problem is not that user try to join the irc server

  243. Zash

    > would be even better if this would allow a dataform, but a description field that tells the user to input #channel@irc.server.org You _could_ take some inspiration from XEP-0077 and shove a dataform in there, or even invent a new XEP that's actually standards track instead of Informational :)

  244. lovetox

    biboumi offers a adhoc command interface on ircserver@gateway.org

  245. lovetox

    users need to access this

  246. lovetox

    but everytime they do in gajim, gajim tells them, this is a muc to join

  247. lovetox

    the whole topic is a very very small annoyance in the grand scheme of things

  248. lovetox

    nothing, absolutly nothing would break if biboumi simply removes the identity

  249. pep.

    Isn't "informational" our own way to say "the implementation was there already"? and standards track "this is designed by committee"

  250. pep.

    What's the tiping point between the two states even. When does one decide the implementation has been there long enough so that it's now informational :P

  251. pep.

    And not ready for standards track

  252. MattJ

    pep. [14:08]: > Isn't "informational" our own way to say "the implementation was there already"? and standards track "this is designed by committee" That's 'historical'. 'Informational' is meant for specs that don't describe a protocol, but perhaps best practices, etc.

  253. MattJ

    Historical was mainly used to document things that were implemented before the XEP process

  254. pep.

    MattJ, what's the difference between a protocol and best practices really, when it's as detailed as 0100

  255. Beherit

    *XMPP Vision & Strategic Workshop* Join the upcoming XMPP #Vision & Strategic #Workshop to discuss and understand our #community better, but also ask for your input on different topics around our federated network and #technology. Date: Tue, 14th November 2023 Time: 6:00 - 9:00 pm UTC Online & in English Everyone welcome - spread the word! https://fosstodon.org/@xmpp/111319439579383047

  256. pep.

    It would make sense for a MUC not to reflect a self-ping to the device pinging right?

  257. pep.

    Be it for 410 or not

  258. Zash

    define 'reflect' ?

  259. pep.

    1. resource1 pings participant1, 2. muc forwards ping to participant1's devices, 3. resource1 replies to ping, 4. muc replies to ping.

  260. pep.

    That's the usual flow right?

  261. pep.

    In 2., muc can certainly skip resource1

  262. pep.

    And if that's the only device joined, reply directly

  263. pep.

    (assuming resource1 is joined as participant1, obviously)

  264. Zash

    the sensible thing today would be to do 410 and respond to the ping immediately

  265. pep.

    hah, also I read in 410 that the "2." I wrote isn't correct, the iq is forwarded to "any one" of participant1's device.. I had forgotten this "detail"

  266. Zash

    _one_ yes

  267. Zash

    no plural

  268. Zash

    tho it'd be some kind of interesting to send out multiple pings and merge the responses...

  269. Zash

    in the "hey we have promise.all(), wouldn't it be fun if" kind of way

  270. pep.

    Ok so all of this is moot in the context of 410. I had forgotten about it