-
qy
Mother of christ, legitimately the first time i'm seeing https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe
-
qy
So yeah i guess thats it, my hacky pubsub shims are coming back to bite me
-
MattJ
qy: for PEP you do *not* need to subscribe to the node manually (some servers may not even support it)
-
MattJ
PEP has automatic subscriptions when someone authorizes you as a contact
-
qy
MattJ: oh, okay
-
qy
Thankful, it wasn't working very well anyway
-
Sam
Is there any spec (or individual client or server) that uses in-band bytestreams somehow without eg. wrapping it in a larger protocol that would need to be implemented? I don't know why anything would accept an arbitrary bytestream without some other form of negotiation, but I just realized I have absolutely no way to integration test this unless I also implement Jingle or something.
-
MattJ
Sam, did you say https://modules.prosody.im/mod_tcpproxy ? :)
-
Sam
Oh thanks, that looks almost perfect
-
MattJ
It hasn't been touched for a long while, but I'd be surprised if it doesn't still work. If it doesn't, give me a shout, any issues are probably simple fixes.
-
MattJ
I did use it for stuff, back when I wrote it
-
Sam
Will do; thanks. I'm mostly concerned with the use of namespace prefixes (this XML library doesn't support prefixes in general, and their use here means that even if it did I'd also have to add specific support to the IBB library, which doesn't feel right, but I'm sure I'll figure something out)
-
jonas’
it doesn't implement Namespaces for XML 1.0?
-
Sam
It implements namespaces using xmlns and has read-only support for prefixes.
-
jonas’
that's ok
-
jonas’
the code supports you using a non-`tcp` prefix
-
jonas’
if your library doesn't even support that… I'd say you used the wrong XML library to write an XMPP library ;)
-
Sam
Oh cool, I *think* if I set an attribute with a namespace it's happy to make up a prefix (ie. it will just do xmlns:_ns1 or something on the current attribute), so that may be fine
-
Sam
We'll see. I think it's fine given that XMPP doesn't use prefixes in general.
-
Sam
Either way though, figuring out how to add extra attributes to IBB without building in support for this specific non-standard protocol to the IBB library will be weird. Adding arbitrary attributes isn't an extension point I normally support
-
jonas’
I'd also have expected a child element to be honest.
-
Sam
I don't generally support stuff like that either for things like IBB that are well defined and don't say "and also this can take an arbitrary payload too" if I'm honest, but yah, if I'm just thinking about data modeling with XML I guess I'd expect a child
-
jonas’
hm, but that's how XMPP works, kind of
-
jonas’
putting things in a different namespace into other things
-
jonas’
to extend them
-
Sam
Sure, but I've never really had a problem with it. I just support specific specs. ibb.Open(to, blocksize) or whatever is way easier than returning some custom thing that you can also modify and call add child on and do a builder and then eventually send.
-
jonas’
myeah, kind of a pain when you'd want to do some rapid prototyping
-
Sam
I guess; hasn't been a problem in practice. Specs mostly indicate whether they expect to be extended or not.
-
jonas’
nobody expects the ~spanish inquisition~ extension elements!
-
pep.
“I'd also have expected a child element to be honest.” < I guess that's because of the fact that we don't do much ns'd attributes, unfortunately, so we're going in circles :(
-
Sam
Just glancing at aioxmpp it seems to work in a similar way, though maybe I'm misunderstanding something. I can't imagine most libraries let you fully customize every single possible spec and stanza
-
jonas’
pep., ah, no, here primarily because a child element would allow extension itself.
-
pep.
I'm not sure I understand the difference really. Why wouldn't the attribute allow it
-
jonas’
Sam, due to the separation of business logic and stanza construction as well as inheritance it's rather easy to patch things though
-
pep.
As long as there's wire protocol to say you use an extension (be it an ns'd attribute or tag)
-
jonas’
pep., example: extend the protocol up there to do direct TLS over TCP and include a list of root CAs .✎ -
jonas’
pep., example: extend the protocol up there to do direct TLS over TCP and include a list of root CAs. ✏
-
Sam
jonas’: I think what he's saying is that you could always do customtcp2:tls="whatever" as well in the same element. It doesn't matter if it's a child of the original data somehow.
-
pep.
I think it's just an arbitrary choice whether we use attributes or tags. A lib could make it as easy to do one or the other it's just that we're used to tags
-
jonas’
Sam, but representing *lists* (e.g. of root CAs) in attributes is a PITA :)
-
Sam
Sure, but that wasn't the original point of contention. The original question was "should host/port be an attribute or an extension" and neither of those are lists that are difficult to represent.
-
jonas’
Sam, having them as an element makes the "do TCP" extension more extensible though
-
jonas’
that was my point for favouring an element
-
qy
TCP over XMPP? Does that mean you could REST over XMPP? Cause that means Homeserver over XMPP is possible
-
Sam
Why? You could leave the protocol exactly as is (eg. "tcp:host" attributes) and also add a <tcp2:rootca> element. Or you could add a <tcp><rootca> element, it doesn't matter if it's nested or not.
-
Sam
qy: see also https://xmpp.org/extensions/xep-0332.html
-
jonas’
right
-
Link Mauve
“20:06:30 qy> Tldr it means the server always disco requests me, aiui”, you might receive a request, but the server might verify the hash of your response and throw it away if it doesn’t match.
-
qy
That's a thing? Bugger me sideways
-
pep.
Sam, yeah exactly, I also think it doesn't matter, it's just an arbitrary choice
-
qy
Sam: Beautiful
-
pep.
Might look prettier or easier to understand. And these aren't at all subjective obviously /s :)
-
Link Mauve
MattJ, “and a block-size, if given, is (currently) ignored.”, that’s illegal as per XEP-0047, this attribute is a MUST.
-
jonas’
patches welcome?!
-
pep.
It could be specified that 'http://prosody.im/protocol/tcpproxy' ignores the MUST :)
-
jonas’
I think you have +w on that repository ;)
-
pep.
And be done with it
-
Link Mauve
I do.
-
Link Mauve
Hmm, XEP-0332 doesn’t mention anything about encodings, we know XMPP is UTF-8 but what if a HTTP server advertises text/plain;charset=utf-8 but returns non-UTF-8 as the content?
-
jonas’
you'd have to inject Transfer-Encoding: base64 I guess
-
Zash
Oh it has https://xmpp.org/extensions/xep-0332.html#sect-idm45815412462064
-
xnamed
I have a question about https://xmpp.org/extensions/xep-0045.html#disco-occupant What if a non-occupant - who has owner affiliation - queries room configuration or its affiliation lists? If this should be allowed, why not include something like <feature var='http://jabber.org/protocol/muc#owner'/> in the room disco info result when it's available for use?
-
qy
> Link Mauve wrote: > ...but the server might verify the hash of your response and throw it away if it doesn’t match alright, sorted now. I have to say, kind of a shitty behaviour to just discard the response with no indication if that is whats happening though
-
qy
Luckily didnt have to modify much overall
-
qy
Manual sorting :D