jdev - 2022-01-07

Mother of christ, legitimately the first time i'm seeing https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe

So yeah i guess thats it, my hacky pubsub shims are coming back to bite me

qy: for PEP you do *not* need to subscribe to the node manually (some servers may not even support it)

PEP has automatic subscriptions when someone authorizes you as a contact

MattJ: oh, okay

Thankful, it wasn't working very well anyway

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.

Sam, did you say https://modules.prosody.im/mod_tcpproxy ? :)

Oh thanks, that looks almost perfect

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.

I did use it for stuff, back when I wrote it

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)

it doesn't implement Namespaces for XML 1.0?

It implements namespaces using xmlns and has read-only support for prefixes.

that's ok

the code supports you using a non-`tcp` prefix

if your library doesn't even support that… I'd say you used the wrong XML library to write an XMPP library ;)

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

We'll see. I think it's fine given that XMPP doesn't use prefixes in general.

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

I'd also have expected a child element to be honest.

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

hm, but that's how XMPP works, kind of

putting things in a different namespace into other things

to extend them

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.

myeah, kind of a pain when you'd want to do some rapid prototyping

I guess; hasn't been a problem in practice. Specs mostly indicate whether they expect to be extended or not.

nobody expects the ~spanish inquisition~ extension elements!

“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 :(

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

pep., ah, no, here primarily because a child element would allow extension itself.

I'm not sure I understand the difference really. Why wouldn't the attribute allow it

Sam, due to the separation of business logic and stanza construction as well as inheritance it's rather easy to patch things though

As long as there's wire protocol to say you use an extension (be it an ns'd attribute or tag)

pep., example: extend the protocol up there to do direct TLS over TCP and include a list of root CAs. ✏

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.

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

Sam, but representing *lists* (e.g. of root CAs) in attributes is a PITA :)

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.

Sam, having them as an element makes the "do TCP" extension more extensible though

that was my point for favouring an element

TCP over XMPP? Does that mean you could REST over XMPP? Cause that means Homeserver over XMPP is possible

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.

qy: see also https://xmpp.org/extensions/xep-0332.html

right

“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.

That's a thing? Bugger me sideways

Sam, yeah exactly, I also think it doesn't matter, it's just an arbitrary choice

Sam: Beautiful

Might look prettier or easier to understand. And these aren't at all subjective obviously /s :)

MattJ, “and a block-size, if given, is (currently) ignored.”, that’s illegal as per XEP-0047, this attribute is a MUST.

patches welcome?!

It could be specified that 'http://prosody.im/protocol/tcpproxy' ignores the MUST :)

I think you have +w on that repository ;)

And be done with it

I do.

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?

you'd have to inject Transfer-Encoding: base64 I guess

Oh it has https://xmpp.org/extensions/xep-0332.html#sect-idm45815412462064

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?

> 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

Luckily didnt have to modify much overall

Manual sorting :D