XSF Discussion - 2023-03-24


  1. flow

    why does xep70 define also a message-based variant? that appears unnecessary, as at the time you know that the client supports xep70, and then the IQ transport is far better

  2. MattJ

    Who knows it supports XEP-0070?

  3. flow

    the server who sends the stanza to the user

  4. pep.

    Who says the entity doing ad-hoc is a server

  5. pep.

    As much as I agree that an iq-based transport is better

  6. MattJ

    PSA: multiple XSF/jabber.org services are currently unreachable due to an outage - including mailing lists, xmpp.net, jabber.org and conference.jabber.org

  7. Seve

    Thank you

  8. flow

    pep., my point is that as soon as someone sends you a xep70 challenge, then you previously requested that challenge. and you wouldn't request the challenge if you can't handle it

  9. MattJ

    flow, the challenge is not requested by the client, but by the user

  10. flow

    MattJ, maybe I messed up the terminology. but as soon as a client reacts on xep70 § 4.2 and does § 4.3, the server knows that the client will support § 4.4 (otherwise the client would have done § 4.3)

  11. flow

    MattJ, maybe I messed up the terminology. but as soon as a client reacts on xep70 § 4.2 and does § 4.3, the server knows that the client will support § 4.4 (otherwise the client would not have done § 4.3)

  12. MattJ

    4.2 and 4.3 are a HTTP client, e.g. a web browser

  13. flow

    hmm?

  14. flow

    yes 4.1 - 4.3 are HTTP

  15. MattJ

    So your web browser, and the web server, have no idea if your XMPP client supports XEP-0070

  16. flow

    the http client needs to be *at least* aware of the JID of the user to perform 4.3

  17. flow

    so there needs to be some interaction between the HTTP logic and the XMPP logic

  18. MattJ

    Yes, e.g. by offering an "Enter your JID to sign in" input box

  19. flow

    right, I think one flaw of xep70 is that it does <body/> and <confirm/> in the same message. at some point in the HTTP exchange you know that your client either supports xep70, then you do not need <body/> or that it does not support xep70, then you do not need <confirm/>

  20. MattJ

    I don't think such a step exists

  21. flow

    it's not a step, it's more signalling

  22. MattJ

    Where/what is this signalling? There is none other than "the user entered their JID into a web app"

  23. flow

    I assumed realm=xmpp is the signalling that xep70 should be used

  24. MattJ

    That's from the web server

  25. flow

    and once the client continues in 4.3 after receiving realm=xmpp in 4.2, he sginals xep70 support

  26. MattJ

    At that point it has no idea who you are, or whether you have clients that support XEP-0070

  27. MattJ

    The client in 4.3 is a web browser, it too has no idea whether your XMPP clients support XEP-0070

  28. flow

    fwiw, I don't believe that everything that does HTTP is a web browser :)

  29. flow

    could be a XMPP client doing a http upload fetch

  30. MattJ

    I don't believe so either

  31. MattJ

    But I'm attempting to simplify things because of the potential for confusion over the word "client"

  32. flow

    i am not sure if this simplification is beneficial here

  33. MattJ

    You seem to be assuming that the HTTP client and the XMPP client are the same entity?

  34. MattJ

    If so, everything you say makes sense

  35. flow

    if xep70 <confirm/> is used, then at least a coupling between the HTTP and XMPP layer is to be expected, no?

  36. MattJ

    But that is one specific case that is not very common

  37. MattJ

    This is explicitly stated in the XEP: > Note well that an XMPP Client can simultaneously be an HTTP Client (or vice-versa), and that an XMPP Server can simultaneously be an HTTP Server (or vice-versa). However, for the purposes of this discussion, we assume that these entities are logically if not physically separate and distinct.

  38. flow

    ok, the other case is where your HTTP GET results in a "please enter your jid for verification" box

  39. flow

    and to be, it is not clear how the HTTP server should decide to return such a verification box or a 401 with realm=xmpp

  40. flow

    and to me, it is not clear how the HTTP server should decide to return such a verification box or a 401 with realm=xmpp

  41. flow

    i would somehow naively expect that 4.1 should contain some http header that signals to the server the the requesting entity supports the xep70 <confirm/> method

  42. MattJ

    It's just one possible login option, it may be one of many (in which case using www-authenticate is not wise)

  43. MattJ

    That would require support in every web browser

  44. flow

    well you could define the absence of the header as "does not support <confirm/>"

  45. flow

    bbl, time for coffee

  46. MattJ

    I think you're still mixing up the HTTP client and the XMPP client

  47. MattJ

    They are totally separate

  48. MattJ

    Your HTTP client (web browser) has no information about your XMPP client

  49. MattJ

    You should take a look at https://blog.agayon.be/xmpp_auth_django.html if you want to see a practical demonstration of XEP-0070

  50. flow

    MattJ, does https://blog.agayon.be/xmpp_auth_django.html use <confirm/> somewhere?

  51. flow

    ahh ok, it appears it does

  52. MattJ

    Yes: https://git.kingpenguin.tk/chteufleur/HTTPAuthentificationOverXMPP/src/branch/master/xmpp/confirmation.go

  53. flow

    I think I see know that we approach this from different angles

  54. flow

    my line of thought is, since it is the client, who wants to access the HTTP resource, which specifies the transaction ID, there is no need for an confirmation UI dialog, as you know at the time the <confirm/> arrives via xmpp, that you requested it. of course, this requires a coupling between http and xmpp

  55. MattJ

    When you say "the client" - which one? :)

  56. MattJ

    The HTTP client or the XMPP client?

  57. flow

    hmm, but it is unlear for me how an xep70 unware http client would create a xep70 transaction id

  58. flow

    MattJ, in my case, it's the same entity (which may not be true, I know, but that's what I was thinking about)

  59. MattJ

    The reality is that nobody uses the www-authenticate parts of this XEP

  60. flow

    then where does the 'id' in the Gajim example originate from?

  61. MattJ

    The XEP clearly states that the two entities are usually separate, but yes, I agree they may be the same entity and then it solves the discovery problem

  62. MattJ

    In the "enter your JID" web app case, it's the web app that generates the id and communicates with you over XMPP

  63. flow

    MattJ, ok, so xep70 § 4.2 and 4.3 isn't use at all here?

  64. flow

    MattJ, ok, so xep70 § 4.2 and 4.3 isn't used at all in this case?

  65. MattJ

    No

  66. MattJ

    Just the XMPP parts

  67. flow

    that leaves so little remaining from the xep that I wonder if it wouldn't be sensible to simply send a message with a body

  68. MattJ

    Yep

  69. MattJ

    And since so few clients currently implement it, that's the UI most people would see right now (that or "here is your authentication code")

  70. MattJ

    Just the way some sites use email or SMS to sign you in

  71. MattJ

    XEP-0070 just allows clients to put a nicer UI on top

  72. MattJ

    However I think it's inadequate even for that

  73. flow

    MattJ, that was nice chat, btw. it is always interesting how the same xep can be interpreted in different ways, depending on your prior experience. I read the xep primarly as an approach for a single entity performing http requests and authenticating via xmpp

  74. MattJ

    Although it can be used that way, that was definitely not the intention of the authors (per the paragraph I quoted earlier)

  75. MattJ

    But a lot of optimism was involved in that, I think

  76. MattJ

    In practice, www-authenticate isn't often used these days even for HTTP-only auth

  77. flow

    MattJ, not sure about that, the process flow in § 4. makes it appear that § 4.2 and § 4.3 are somehow expected to happen

  78. MattJ

    Yes, the idea would be that browsers implement support for XEP-0070 to make this work

  79. MattJ

    The same way SCRAM is also defined for HTTP, but browsers don't implement that either

  80. MattJ

    Everything happens via HTML/JS now instead

  81. Daniel

    If occupant ids allow me to track users across nick name changes and sessions. Do I show the current Nick next to a message or the Nick at time of sending? 🤔

  82. Ge0rG

    at the time of sending is less confusing IMHO

  83. MattJ

    I don't see an immediate right or wrong answer. However I think maybe if you display nick changes in the chat log, show at the time of sending. If you don't show nick changes, always show the current.

  84. Daniel

    What if the have multiple current nicks

  85. MattJ

    Time of sending + invisible changes = an interesting ability to forge a conversation that to an observer looks like multiple parties were involved

  86. Daniel

    What if they have multiple current nicks

  87. jonas’

    "multiple current nicks"?

  88. jonas’

    what's that?

  89. Ge0rG

    jonas’: you can join a room from different clients with different nicknames

  90. jonas’

    then they're not the same entity

  91. MattJ

    Until they are

  92. jonas’

    *shudder*

  93. Ge0rG

    do they have the same occupant-id?

  94. Daniel

    Yes

  95. Daniel

    When I'm joined here as `Daniel` and `daniel` from Dino and Conversations I have two nicks and one occupant id

  96. jonas’

    that does not sound right

  97. MattJ

    That's the whole point of occupant-id, no?

  98. MattJ

    The XEP says: "A user in the sense of this specification is identified by its real bare JID."

  99. Daniel

    > that does not sound right In that I'm quoting the xep wrong or in that the effects of ephemeral nicks in group chats are bonkers?

  100. jonas’

    the latter I guess

  101. Guus

    User complaining that bugs never get fixed, pointing out that the problem already existed five years ago. When requesting some kind of diagnostics other than "it doesnt work", I find out that they've configured their XMPP domain name to be 'localhost'. #tgif #sigh

  102. Guus

    `</vent>`

  103. MattJ

    :)

  104. Zash

    It is Friday!

  105. flow

    which became recently one of my favorite weekdays, since its the day where new episode of picard appears

  106. Guus

    I do not dislike Picard S3

  107. flow

    well put

  108. L29Ah configured his XMPP domain name to be 'localhost' and is happy, 10/10 do recommend ;]

  109. Fishbowler

    I'm biased towards all Trek, but Picard S3 is something extra special. Every episode so far this season has been even better than the one before.

  110. Fishbowler

    All service operators: "Everything would run fine, if it weren't for these pesky users!" L29Ah: "I have a cunning plan."