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.
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.
Sam Whited
The "correct" behavior and API is eluding me.
jonas’
the XMPP protocol doesn’t really allow you to do starttls depending on the account or not✎
jonas’
the XMPP protocol doesn’t really allow you to do starttls depending on the account ✏
jonas’
only if you do auth first
Zash
> XMPP library that handles the server side
I'm aware of xmpp.js
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
jonas’
then the application can either decide to offer starttls (or whatever) always, or decide to not offer it until auth has passed
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.
jonas’
Sam Whited, can’t you re-invoke the callbacks on each stream reset?
Sam Whited
Zash: thanks, I'll look that one up
jonas’
with the information available there? thanksfully, stream resets happen after TLS and auth.
stpeterhas joined
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).
suohuahas joined
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"
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.
debaclehas left
Zash
https://github.com/xmppjs/xmpp.js ? thought they had xmpp server support
Sam Whited
Zash: yah, that's what I'm looking at. I don't see any
Zash
and it's not tests? oh well
Sam Whited
Zash: What do you mean by "not tests?" what's not tests?
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
Zash
IIRC there was a javascript library that used prosody in their tests
Sam Whited
oh yah, I think that's what this is doing
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 :)
Zash
https://www.npmjs.com/package/node-xmpp-server well, that just links back to xmpp.js
Zash
🤷️
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.
stpeterhas left
marmistrzhas left
Neustradamushas left
alacerhas left
alacerhas joined
Neustradamushas joined
suohuahas left
marmistrzhas joined
paulhas left
larmahas joined
oibaloshas left
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.