jdev - 2021-08-06

  1. amit

    hello @all . Can i use XMPP protocol in django with asgi ?

  2. jonas’

    django is python, python is turing complete, yes you can.

  3. amit

    Need any library like aioxmpp or only xmpp protocol like ws?

  4. Sam

    If you're asking for some kind of pre-built integration I don't think there is any, you'd have to build it yourself (probably using a library like aioxmpp)

  5. Sam

    Are you just wanting to display a client on a webpage though? That doesn't have much to do with django specifically and will be more or less the same for anything

  6. amit

    Actually i am looking an alternative of websocket. In websocket a server can accept max 65535 connection simultaneously and its very expensive. My requirement is to implement instant chat app.

  7. flow

    amit, huh websockets can only accept 2^16 connections? I somehow doubt this

  8. amit

    for each connection it occupy one port number

  9. Sam

    That's not how websockets work, maybe you're mixing up websockets with regular sockets?

  10. Sam

    I'm not really sure what you're asking for though, maybe you could explain a bit more about the project and what your needs are and it would help us help you better? This doesn't sound like a django or even XMPP specific question anymore to me, but it's hard to tell.

  11. jonas’

    that's also not how regular sockets work by the way

  12. jonas’

    a TCP connection is defined by (src-addr, src-port, dst-addr, dst-port). in a server, dst-port and dst-addr are typically constant (e.g. or

  13. jonas’

    so you only need a single address+port for a server socket and the clients are identified by their address + port

  14. jonas’

    likewise, for a client, you can reuse the same source port as long as you are connecting to different destination ports + addresses

  15. jonas’

    so that "at most 65535 connections because of ports" limit is bogus

  16. jonas’

    for UDP, things are a bit different because it is inherently connectionless, there you might have more constraints depending on the protocol running on top of it. Stuff like QUIC has a connection ID though by which it multiplexes, so there it matters even less.

  17. Sam

    I always forget that MUC needs PEP for bookmarks and PEP needs disco if you want to receive updates. Guess I have my work cut out for me :(

  18. Sam really hasn't figured out a good way to do disco in particular

  19. MattJ

    What are you struggling with?

  20. Sam

    A mix of motivation to read several giant XEPs that are all needed in some part to make this work, and with disco in particular I just haven't found a nice API that doesn't make it hard to use (eg. I shouldn't have to register a handler with the client *and* a disco feature, I should just be able to have the handler know what features exist and be able to also respond to disco… this isn't hard, I just haven't found a good way to do it in my own codebase)

  21. Sam

    The disco stuff is all super project specific, unfortunately

  22. MattJ

    I've been fairly happy with the disco API in Verse, not that I've used it much recently

  23. MattJ

    Main thing that tripped me up was the concept of "nodes", which I have to confess I'm still not sure I understand :)

  24. MattJ

    There are two aspects to a disco API, the discovery side and the advertisement side

  25. Sam

    Indeed; I think I've got all that working fine from the perspective of someone querying for disco info, nodes work, you can walk the tree, etc. (https://pkg.go.dev/mellium.im/xmpp/disco@main), but the advertisement side I've been stuck on for ages for some reason

  26. Sam

    I haven't seen Verse before I don't think, I'll look up what you do there; thanks

  27. MattJ

    That's mostly just a local registry, right?

  28. MattJ

    per node

  29. Sam

    Yah, so you end up with a tree-like structure of nodes.

  30. MattJ

    "of nodes" - sure? Disco info/items doesn't actually allow you to discover nodes, right?

  31. MattJ

    You have to know what node you want to query

  32. Kev

    Disco is not a hierachy of nodes, FWIW.

  33. Sam

    Right, so you start from the root node (empty node name) and then you can query over all those, etc. to walk the tree

  34. MattJ

    Tree of JIDs, not nodes

  35. Kev

    It’s a flat pool of nodes. You can construct the node names as you wish so they encode structure within them, but don’t have to, and the structure is by appearance only.

  36. Sam

    I guess, but since you can't discover all nodes except by querying root, then querying those nodes, it's effectively a tree

  37. Sam

    At least, it has to be walked like a tree if you want to find all nodes

  38. Kev

    You can’t query the root to find all nodes for disco.

  39. Sam

    Right, you can only find the nodes directly under the root node

  40. MattJ

    Ah, there is a 'node' attribute for items

  41. Kev

    You can’t even do that.

  42. MattJ

    Shown in https://xmpp.org/extensions/xep-0030.html#example-17

  43. Sam

    I guess after all this time I still don't understand disco then

  44. Sam

    Or am I thinking of Items and you're thinking of Info? I guess I need to go re-read this for the milionth time

  45. Kev

    You can have results that include lists of other jids and nodes, so you *can* build a tree, and if you want to build a tree, what you describe is right.

  46. Kev

    But you don’t have to build a tree, you don’t have to list different nodes under the root, etc.

  47. Sam

    Oh sure, I mean, I know that you can address any node directly without querying for the top level ones or knowing their name first or whatever

  48. Kev

    My client (kev@server/res ) could have a ‘kevstuff’ node if it wanted, and that needn’t be listed anywhere.

  49. Kev

    So the only way you’d know it existed was if you queried it and did or didn’t get a result.

  50. Sam

    oooh, that's fair too and I hadn't thought of it.

  51. Kev

    So if your disco responder model relies on tree representation that’s fine and up to you, but it doesn’t cover all the disco uses.

  52. Sam

    That's a great API consideration that I hadn't worked out, thank you

  53. Sam

    (still, I find it helpful from the querying entities perspective to provide functionality to walk the nodes like a tree; makes it easy to design browsers like Gajim has, for example, but it's a good point that I shouldn't rely on it)

  54. Kev

    Personally, I would just register a disco items or info callback or callbacks that gets passed the JID and Node, and then returns a set of results that are concatenated to form a result for the response.

  55. Kev

    And I wouldn’t in the XMPP Library API do any sort of imposition of structure. Let the application sort it out, only the application knows what it wants.

  56. Kev

    Yes, having a tree walker in the library for queries is a sometimes useful thing.

  57. Kev

    We do that for Swift for finding MUCs.

  58. Kev

    I note that’s walking the JID tree rather than a node tree, mind.

  59. Sam

    Just having a way to let the application sort it out is fine I guess, but if they've already created a handler for MUC (for example) and passed that into the router that handles XML and pushes it to the right place, it seems like they should be able to say "just use the disco for all the handlers we have registered" and not have to go back and figure them all out

  60. Sam

    To prevent eg. registering the handler for MUC but then forgetting to register the disco node

  61. Sam

    err, yes, JID tree for items I guess

  62. Kev

    Within M-Link we do that, yes. When we register handlers (delegates in our terms), those delegates will be called for append disco results when the router’s queried.

  63. Kev

    Which is basically > Personally, I would just register a disco items or info callback or callbacks that gets passed the JID and Node, and then returns a set of results that are concatenated to form a result for the response. with the registering being automatic.

  64. Sam

    yah, it's the automatic part I need to figure out a clean way to do

  65. Sam

    Really it's an issue with my previous design decisions (I think, kind of making this up as I think outloud). I have a router that you register handlers against to handle certain XML elements. I would expect disco responses to be one of those handlersr. However, the handlers don't have access to the router they're registered on, so how does it know what else has been registered?

  66. Kev

    Disco has to be a special case.

  67. Sam

    I think it might, yes. Built into the router or something.

  68. Sam

    I really hate to do that though; I feel like there's got to be a nice way to make it work without it.

  69. Sam

    Generally speaking I feel like it it has to be a special case either the underlying spec (nothing I can do) or my API (hopefully I can fix it) has a rather fundamental structural problem. Figuring out which and what to do about it is time consuming and hard though.

  70. Kev

    I’ve not had a significant problem working disco into any of the codebases I’ve done so, so I don’t *think* the spec is fundamentally broken.

  71. Sam

    Oh yah, it's almost certainly not

  72. Sam

    Oh hey, apparently I came up with an elegant (if I do say so myself) way to handle disco, made a branch, and then forgot about it. Glad I looked before starting over on the thing I was talking about earlier.

  73. moparisthebest

    protip: always check git stash

  74. moparisthebest

    maybe un-needed if you have a better memory...

  75. Sam

    Not I…

  76. Link Mauve

    “14:59:22 Sam> I always forget that MUC needs PEP for bookmarks […]”, for this part, it might be useful to read this, about the current mess that is bookmarks: https://docs.modernxmpp.org/client/groupchat/#bookmarks

  77. Sam

    :( good docs, thanks. I'll probably just implement the PEP ones. If we detect another client that doesn't advertise support and the server doesn't do the compat thing maybe I'll log a message telling them to change clients or ask their server admin for #compat.

  78. Link Mauve

    Given the vast majority of clients do Private XML, and the Prosody modules can’t support both PEP versions (and I wouldn’t expect complete synchronisation to be easy to implement in other servers’ PEP modules either, but I’d love to be proven wrong), I don’t recommend implementing old PEP at all any more.

  79. Link Mauve

    Private XML is the better fallback.

  80. Sam

    Sorry, I meant just the new PEP one, singular