jdev - 2021-01-31

  1. Sam Whited

    Might have asked this before, but does anyone know of another XMPP library (other than Mellium) that handles the server side of things? Trying to find examples of how they handle what stream features to select by user account.

  2. Sam Whited

    I'm having an issue where even if I pass in a callback that takes, eg. the origin JID and returns a list of stream features after the first stream is established, there's not always a from attribute to pass to the callback before StartTLS. But I can't list starttls until I know if I should list it for that account.

  3. Sam Whited

    The "correct" behavior and API is eluding me.

  4. jonas’

    the XMPP protocol doesn’t really allow you to do starttls depending on the account or not

  5. jonas’

    the XMPP protocol doesn’t really allow you to do starttls depending on the account

  6. jonas’

    only if you do auth first

  7. Zash

    > XMPP library that handles the server side I'm aware of xmpp.js

  8. jonas’

    so the callback should have the `from` optional, and the user of the callback should know that if `from` is nil or whatever, it is pre-auth

  9. jonas’

    then the application can either decide to offer starttls (or whatever) always, or decide to not offer it until auth has passed

  10. Sam Whited

    I suppose that's fair; then I have to come up with some new way to add stream features to the list after the first stream I suppose, which is going to be a real pain.

  11. jonas’

    Sam Whited, can’t you re-invoke the callbacks on each stream reset?

  12. Sam Whited

    Zash: thanks, I'll look that one up

  13. jonas’

    with the information available there? thanksfully, stream resets happen after TLS and auth.

  14. Sam Whited

    jonas’: I suppose so; I was originally listing every possible stream feature up front, but maybe I just need to re-invoke it every time. It just feels odd to give the user the posibility of returning widely divergent stream features lists for every stream, and they also do their own filtering based on the state (so eg. if you list "starttls, auth" it won't actually present auth until after starttls has been negotiated).

  15. Sam Whited

    Sorry, "listing" in the sense of "passing it to the code that does negotiation" not "listing" as in "sending the XML to the client"

  16. Sam Whited

    Zash: I don't see any server package in here except something that just launches prosody, sadly. No docs that I can find though and I don't really know JavaScript, so I may be missing something.

  17. Zash

    https://github.com/xmppjs/xmpp.js ? thought they had xmpp server support

  18. Sam Whited

    Zash: yah, that's what I'm looking at. I don't see any

  19. Zash

    and it's not tests? oh well

  20. Sam Whited

    Zash: What do you mean by "not tests?" what's not tests?

  21. Sam Whited

    I think the server folder is just tests or something, it appears to just launch and configure prosody like https://pkg.go.dev/mellium.im/xmpp/internal/integration/prosody does

  22. Zash

    IIRC there was a javascript library that used prosody in their tests

  23. Sam Whited

    oh yah, I think that's what this is doing

  24. Sam Whited

    Sorry, to be clear I was looking for a library that implemented XMPP server side functionality itself so I coudl steal their ideas :)

  25. Zash

    https://www.npmjs.com/package/node-xmpp-server well, that just links back to xmpp.js

  26. Zash


  27. Sam Whited

    oooh, maybe this means there's a very old version in the repo (before they forked it and changed the name) that does do the server side though. I'll trawl through the history.

  28. Sam Whited

    *sigh* looks like this is going to require major breaking changes no matter what. I guess that's what I get for not doing the server stuff at the same time as the client side though.