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
alhas left
wurstsalathas left
dezanthas left
dezanthas joined
debaclehas left
kikuchiyohas joined
xnamedhas left
jgarthas left
kikuchiyohas left
jgarthas joined
Petehas left
Petehas joined
dogehas left
pasdesushihas left
dogehas joined
9lakeshas joined
raghavgururajanhas joined
Kevhas left
Kevhas joined
Kevhas left
Kevhas joined
Kevhas left
machas left
machas joined
thomaslewishas left
thomaslewishas joined
thomaslewishas left
thomaslewishas joined
thomaslewishas left
thomaslewishas joined
thomaslewishas left
Yagizаhas joined
raghavgururajanhas left
atomicwatchhas joined
thomaslewishas joined
Yagizаhas left
Yagizаhas joined
thomaslewishas left
SouLhas joined
raghavgururajanhas joined
jubalhhas joined
pasdesushihas joined
emushas joined
pasdesushihas left
atomicwatchhas left
thomaslewishas joined
thomaslewishas left
msavoritiashas joined
COM8has joined
COM8has left
COM8has joined
COM8has left
wurstsalathas joined
MattJ
qy: for PEP you do *not* need to subscribe to the node manually (some servers may not even support it)
machas left
MattJ
PEP has automatic subscriptions when someone authorizes you as a contact
marmistrzhas joined
sonnyhas left
sonnyhas joined
dezanthas left
dezanthas joined
raghavgururajanhas left
Alexhas joined
debaclehas joined
FireFlyhas joined
rafasaurushas left
rafasaurushas joined
nephelehas joined
pasdesushihas joined
Yagizаhas left
dogehas left
Martinhas left
Martinhas joined
dogehas joined
rafasaurushas left
sonnyhas left
sonnyhas joined
rafasaurushas joined
sonnyhas left
sonnyhas joined
Kevhas joined
Yagizаhas joined
9lakeshas left
Vaulorhas left
Vaulorhas joined
9lakeshas joined
goffihas joined
nephelehas left
Dele Olajidehas joined
9lakeshas left
Dele Olajidehas left
9lakeshas joined
bunghas joined
nephelehas joined
9lakeshas left
9lakeshas joined
bunghas left
bunghas joined
jgarthas left
9lakeshas left
9lakeshas joined
9lakeshas left
nephelehas left
nephelehas joined
9lakeshas joined
larmahas joined
Yagizаhas left
9lakeshas left
Yagizаhas joined
9lakeshas joined
9lakeshas left
9lakeshas joined
xnamedhas joined
rafasaurushas left
rafasaurushas joined
Wojtekhas joined
COM8has joined
COM8has left
rafasaurushas left
rafasaurushas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
qy
MattJ: oh, okay
qy
Thankful, it wasn't working very well anyway
atomicwatchhas joined
dogehas left
dogehas joined
machas joined
xnamedhas left
Wojtekhas left
Wojtekhas joined
junaidhas left
xnamedhas joined
emushas left
goffihas left
emushas joined
junaidhas joined
Wojtekhas left
Wojtekhas joined
xnamedhas left
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
machas left
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
machas joined
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 :)
Wojtekhas left
Wojtekhas joined
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.
xnamedhas joined
Wojtekhas left
Wojtekhas joined
goffihas joined
homebeachhas left
Matrix Traveler (bot)has left
Matrix Traveler (bot)has joined
homebeachhas joined
spectrumhas left
spectrumhas joined
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?
rafasaurushas left
9lakeshas left
xnamedhas left
rafasaurushas joined
xnamedhas joined
marmistrzhas left
marmistrzhas joined
jonas’
you'd have to inject Transfer-Encoding: base64 I guess
xnamedhas left
dogehas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
xnamedhas joined
dogehas joined
rafasaurushas left
raghavgururajanhas joined
emushas left
rafasaurushas joined
machas left
machas joined
Zash
Oh it has https://xmpp.org/extensions/xep-0332.html#sect-idm45815412462064
dogehas left
jubalhhas left
jubalhhas joined
Kevhas left
jgarthas joined
thomaslewishas joined
thomaslewishas left
emushas joined
thomaslewishas joined
goffihas left
thomaslewishas left
marc0shas left
marc0shas joined
kikuchiyohas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marmistrzhas left
9lakeshas joined
edhelashas left
edhelashas joined
Wojtekhas left
Wojtekhas joined
sonnyhas left
jubalhhas left
machas left
Yagizаhas left
machas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Kevhas joined
Kevhas left
Wojtekhas left
Wojtekhas joined
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?
SouLhas left
SouLhas joined
Wojtekhas left
jubalhhas joined
thomaslewishas joined
thomaslewishas left
emushas left
Wojtekhas joined
emushas joined
sonnyhas joined
Wojtekhas left
Wojtekhas joined
rafasaurushas left
rafasaurushas joined
rafasaurushas left
Wojtekhas left
rafasaurushas joined
rafasaurushas left
rafasaurushas joined
rafasaurushas left
rafasaurushas joined
rafasaurushas left
sonnyhas left
sonnyhas joined
marc0shas left
marc0shas joined
dezanthas left
Petehas left
Petehas joined
rafasaurushas joined
Petehas left
Petehas joined
dezanthas joined
kikuchiyohas left
kikuchiyohas joined
rafasaurushas left
pulkomandyhas left
rafasaurushas joined
kikuchiyohas left
kikuchiyohas joined
jgarthas left
jgarthas joined
Petehas left
Petehas joined
bunghas left
marc0shas left
marc0shas joined
alhas joined
pulkomandyhas joined
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