Xmpp makes heavy use of namespaces, but are they in reality all that significant? I mean, are there actually any elements defined by existing standards that have different namespaces but same names?
machas left
Yagizаhas left
defanorhas joined
Alacer_dsrthas joined
machas joined
emushas joined
jonas’
Жокир, <query/>, in about every standard using IQs
jonas’
there's also <body xmlns="jabber:client"/> vs. <body xmlns="http://www.w3.org/1999/xhtml"/>
COM8has joined
atomicwatchhas joined
COM8has left
COM8has joined
COM8has left
nephelehas joined
Yagizаhas joined
glickyonghas joined
atomicwatchhas left
Yagizаhas left
atomicwatchhas joined
paulhas joined
atomicwatchhas left
atomicwatchhas joined
wurstsalathas joined
marmistrzhas joined
Neustradamushas left
Neustradamushas joined
Martinhas left
Martinhas joined
FireFlyhas joined
huhnhas left
emushas left
emushas joined
Alexhas joined
atomicwatchhas left
atomicwatchhas joined
debaclehas joined
sonnyhas joined
moparisthebesthas left
marmistrzhas left
flow
Жокир, not only XMPP does use namespaces, but XML parser do too
flow
and name clashes are a thing, even though they are usually mostly encountered in large projects, while namespaces are an easy way to solve it
msavoritiashas joined
Жокир
I know they are a thing in theory, I was asking about xmpp practice. But I've already been told they indeed are a thing there.
Damn those thing add a level a complexity, as if streaming xml wasn't complicated enough
Жокир
And lots of bandwidth
moparisthebesthas joined
machas left
dogehas left
dogehas joined
MattJ
News to me that some short text strings are "lots of bandwidth" 🙂
Yagizаhas joined
MattJ
XMPP implementations would be a horrible mess without namespaces
machas joined
Жокир
Well, compared to the contents itself they certailnly are.
Like in
<a xmlns='urn:xmpp:sm:3' h='1'/>
meaningful characetrs here are basically "a" and "1". That's two characters. Thanks to xml, and thanks even more to the brilliant idea to send the namespace with every ack, the proportion of meaningful data to xml details is 2:29. Which is about 7%
Жокир
And that's a namespace that at least doesn't include "https://..." like some others do
selurvedu
> meaningful characetrs here are basically "a" and "1"
um... I am not even going to try to explain why there's much more to it than you say.
jgarthas left
Жокир
With s exps this could be smth like
(a 1)
Even with xml this could at least boild down to <a h='1'/>, three times shorter
selurvedu
Also, see how WhatsApp having similar concerns managed to compress XML in their proprietary FunXMPP protocol https://sci-hub.se/10.1016/j.diin.2015.09.002
contrapunctus
Жокир: s-expressions FTW 🙂
pulkomandy
there is stream compression defined in XMPP or apparently you can use compression at the TLS level (according to https://xmpp.org/extensions/xep-0138.html), I would say that the very repetitive parts of XML will compress very well with that
jgarthas joined
Жокир
Of course you can *manage* to compress it. But no popular client does.
You can *manage* any kind of bloat.
Жокир
if you have enough time and resources
pulkomandy
or you can remove the X in XMPP and make it a non-extensible protocol. Then you can remove a lot of things form it :)
Жокир
Extensiblity doesn't mean bloat
Жокир
if it weren't for the readily existing code, <a h='1'/> could work just as well
contrapunctus
.o(It's probably not too difficult to define an s-expression encoding for XML (since this can vary between XML libraries), and have XMPP-over-sexp. Probably be easy to use it too - server can decide what to use based on what the client sends.)
selurvedu
Жокир, do you have some specific need for saving traffic? I find XMPP using just tiny bits of traffic compared to many modern messengers and other apps. Of course, enterprise usage and server owners will use more traffic...
selurvedu
Жокир, you don't have to include namespaces with every single element. It's not that problematic as you describe it. https://xmpp.org/rfcs/rfc6120.html#streams-ns
Also some other people actually don't like namespaces as well, it's been discussed (see here https://wiki.xmpp.org/web/XMPP_Office_Hours/2021-04-13-Notes )
Жокир
>compared to modern messengers and other apps
That's not saying much is it 🙂
Saying "lighter than modern apps" is like saying "cleaner than sewage"
No, I don't have any specific requirements for saving traffic. Instead I'm evaluating xmpp among other protocols and wondering maybe there's a rationalization to ascpects I find irrational.
>you don't have to include namespaces with every single element. It's not that problematic as you describe it. https://xmpp.org/rfcs/rfc6120.html#streams-ns
Heard about that, also heard that lots of software doesn't support it 🙂
Another example of how one *can* in principle manage bloat, but that doesn't mean you will
defanor
contrapunctus, IME encoding XML in s-expressions (as in SXML and/or Emacs's xml.el) becomes perhaps more awkward than just using XML when you try to handle namespace prefixes and attribute namespaces.
contrapunctus
defanor: do tell...what happens?
defanor
contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML.
defanor
Not like the s-expressions you'd normally compose, if you've designed a protocol or an API for those in mind at once.
defanor
"With those in mind", even.
selurvedu
> Heard about that, also heard that lots of software doesn't support it 🙂
Dunno, works for me 🙃️
glickyonghas left
Жокирhas left
alhas joined
flow
Жокир I think if you have a text based protocol, than written out names make the protocol more accessible, even though it consumes more bytes on the wire. That's a similar argument when programming, in favor of self-explaining variable names, compared to single letter variables names. I doubt that those extra bytes on the wire kill your battery or will have you run into your traffic quota. That said, I did not measure it myself, but, as far as I can tell, most people complaining about the verbositiy of XMPP do so only based on their gut feeling. It would be really nice if we had some hard facts.
flow
Жокир, you may be happy to hear that "<a xmlns='urn:xmpp:sm:3' h='1'/>" could probably be easily shorted into "<a:sm h='1'>" if this particular feature of XML namespaces has been negotiated with the remote party
contrapunctus
defanor: pattern matching? 🤷
Zash
flow: just gotta xep that negotiation
flow
Zash, wanna give me a little christmas present? :)
contrapunctus
defanor:
> contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML.
Oh wait, there are libraries to query the s-expressions!✎
contrapunctus
defanor:
> contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML.
Oh wait, there are libraries to query the s-expression representations of XML! ✏
alhas left
defanor
contrapunctus, pattern matching is awkward for XML, since order normally matters there (at least in generic ones for s-exps, like pcase), but not in XML, and IIRC parsers tend to preserve the order. Libraries for querying those structures would probably indeed be convenient, but that sounds similar to working with just some XML objects, not benefiting as much from those being encoded in s-expressions.
defanor
I mean the order of attributes and such, not child elements. Though the order of those matters in XML, but not always in XMPP.
Zash
flow: I don't christmas, sorry.
defanor
Hrm, though maybe even the order of attributes may matter in XML in general, but still not always in XMPP.
defanor
https://www.w3.org/TR/2008/REC-xml-20081126/#sec-starttags -- nope, the order of attributes indeed shouldn't be significant in general.
me9has joined
flow
yep, attribute order can not matter, since there can only be at most one attribute with a given name on an element
flow
element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)
marc0shas left
marc0shas joined
Wojtekhas joined
machas left
machas joined
contrapunctus
defanor: I'd probably prefer it because easier on the eyes, compatible with standard list functions, less bytes to transfer, simpler for people to understand and for programs to parse...
debaclehas left
doge
flow:
> Жокир I think if you have a text based protocol, than written out names make the protocol more accessible, even though it consumes more bytes on the wire. That's a similar argument when programming, in favor of self-explaining variable names, compared to single letter variables names. I doubt that those extra bytes on the wire kill your battery or will have you run into your traffic quota. That said, I did not measure it myself, but, as far as I can tell, most people complaining about the verbositiy of XMPP do so only based on their gut feeling. It would be really nice if we had some hard facts.
I don't remember the quote exactly but
Xml combines the readability of binary formats with the efficiency of plain text ones
Xmpp streams are not human readable imho, at least not without heavy formatting.
And frankly even in terms of efficiency even most plaintext formats easily beat xml. Take json, or even homebrewn formats like what freenet uses (fcp)
And verbosity does not always mean readability. Sometimes it even precludes it.
I'd consider the succinct python much more readable than the verbose java.
And in the particular example of
<a h='1'/>, specifying the xmlns='blahblah' does not improve readability one bit. It impairs it even beyond what xml has already done
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
contrapunctus
So...are there any working implementations of group voice chat? 🤔
Zash
contrapunctus: yes
Zash
Or, working on at least
Zash
Dino and JSXC afaik
contrapunctus
Huh
wurstsalat
looks like dino group voice chats just landed in master
contrapunctus
Wow, I must try that.
pasdesushihas left
Wojtekhas left
emus
yes, but it is still deactivated I think
PapaTutuWawahas joined
pasdesushihas joined
defanor
contrapunctus, it can be fewer bytes, but as composed by Emacs's (xml-parse-region nil nil nil nil t) in Emacs, your message as an s-expression is actually larger: https://paste.uberspace.net/emacs-xml-sexp.txt
Жокирhas joined
machas left
machas joined
kikuchiyohas joined
defanor
Not that s-expressions are unsuitable for XML manipulation though, it's just that even though I like them too, by simply piling XML's data model on top of the s-expressions one, you end up dealing with both at once, which I didn't quite like even locally.
inkyhas joined
Zash
Turns out XML is already a decent encoding of the XML data model. Who knew?
Жокир
not that the xml data model is a particularly decent one tho
lovetox
i love xml, its great, namespaces are perfect for extensibility
Zash
It's fine, not really a problem, not something I would qant to spend time arguing about. Especially not today.
jgarthas left
jgarthas joined
me9has left
flow
doge, I think that is true if you stare at raw XMPP XML, but pretty-printed XMPP XML is very readable IMHO. I can't tell you how much positive feedback I got from Smack users after Smack started pretty printing the XML in its debugger. I think that was for some people an eye opener
defanor
XML's verbosity and relative complexity used to bother me in the past, but then I've found myself agreeing with the common sentiment that it doesn't really matter: plenty of other things to worry/care about in a network protocol, often more important ones.
machas left
machas joined
Zash
I'd rather figure out how to send less stuff than smaller stuff
flow
furthermore, the subset of XML that XMPP uses is pretty sane, and, for what it provides, not that complex
flow
I sometimes wish that it would be possible to write </> but then again, if this is my main critique of XML, then i'd say it's pretty good designed
debaclehas joined
Zash
Make it an editor macro
flow
well, my idea was that it would be on the wire too :)
flow
in fact, I think it is already an editor macro…
Sam
The subset thing is part of the problem. If you have to jump through hoops to make it sane, lots of people won't jump through those hoops and things will break. I'm not entirely sure my library handles this correctly, for example, and I know there have been issues with others that don't.
Link Mauve
“11:47:07 flow> element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)”, in XHTML-IM it is very much important to keep the order of children.
flow
thanks Link, that's actually a good example
flow
Sam, not sure about that. from the top of my head, the subset is mostly what most modern XML parsers accept per default, plus, no XML comments
Alastair Hoggehas left
flow
at least that is my impression
doge
> “11:47:07 flow> element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)”
It doesn't mean the order is discarded does it
Also yeah, xml carries more data than is actually used by xmpp. Such as element tails, element order
Link Mauve
When I wrote my first XMPP client, in high school, I did it by reverse engineering the XML logs of Gajim instead of reading the specification, these were Englicrypted and would have been of no use to me.
flow
"Englicrypted", like that :)
Link Mauve
Gajim only added newlines between tags, and that was enough for me to successfully write my first XMPP client for the Nintendo DS. ^^
flow
Link Mauve, it appears you broke the cipher by now ;)
doge
And then there is the usual xml stunt of
<key>value</key>
<key v="value/>
Or in clinical cases
<entry key="key" value="value"/>
Link Mauve
Turns out, daily exposure for 15 years was enough for that. :D
Link Mauve
doge, what is the issue here?
doge
> Gajim only added newlines between tags, and that was enough for me to successfully write my first XMPP client for the Nintendo DS. ^^
What language did one write Nintendo DS programs in?
Link Mauve
I used C.
Link Mauve
I didn’t know C very well at the time, I was still afraid of pointers back then.
flow
doge, that's a matter of good XML (and, by extension, XMPP protocol) design. I think I spot bad design by now, but I fear I don't have compiled a list of guidelines (there are some guidelines on XML design on the web though)
flow
but then again, it is sometimes personal preference what the right thing to do is
Link Mauve
https://linkmauve.fr/dev/jabber8.3.5.tar.xz is the last version I worked on.
Link Mauve
It was the end of the winter break and I had to start school again, and the code was horrid so during the following holidays I couldn’t really get back to it.
doge
> And then there is the usual xml stunt of
> <key>value</key>
> <key v="value/>
> Or in clinical cases
> <entry key="key" value="value"/>
Compared to
Json: {'key': 'value'}
Or tcl: {key value}
It's more verbose and less readable.
Link Mauve
As a corollary of the earlier issue, this client’s source is Frencrypted. :p
defanor
I was about to say that those clinical cases aren't unique to XML: I saw JSON being used that way too. Sometimes even "key1"/"value1", "key2"/"value2", etc.
flow
doge, point taken, but that is due XML not having explicit support for dictionaries
flow
usually, but depending on the value, a good format is: <entry key='foo'>value</entry>
flow
I dont' think that this is a strong argument against XML, but maybe I am just to used to it
doge
> Compared to
> Json: {'key': 'value'}
> Or tcl: {key value}
> It's more verbose and less readable.
And carries superfluous info like the fact that the elements tag is empty, or well that it is one of the myriad of ways to write the same thing. Not just write differently, it'll be represented in the data model differently. While providing no advantages. That's a complexity for the sake of complexity
Link Mauve
This is all good, until you need multiple values, or i18n, or…
machas left
Link Mauve
See XEP-0004 for a more forward-looking way of encoding a dict.
doge
> usually, but depending on the value, a good format is: <entry key='foo'>value</entry>
Super verbose and not readable, wasting space and traffic. Just like all xml
<entry key='foo'>value</entry> is harder to read than {key value}
And MUCH longer to write
Link Mauve
doge, feel free to use XEP-0335.
Zash
Mmmmmmmmod_rest?
Link Mauve
Or that.
doge
Link Mauve: that unfortunately won't fix the fact that writing an xmpp client has to start with writing short of an xml parser
rafasaurushas left
Link Mauve
Right, unless like Zash said you use mod_rest. :)
jgarthas left
Жокирhas left
machas joined
pep.
I guess the only XML parser that you'd need to write only needs to go up until <features/>, then you can do whatever serialization format you want :)
flow
or unless you simply use an parser from one of the various existing xml libraries✎
flow
or unless you simply use a parser from one of the various existing xml libraries ✏
flow
but yeah, you probably have to or want to pre-process the XMPP stream before handing it over to your XML parser
rafasaurushas joined
pep.
Is there a case where a pubsub node name is mandated, that isn't on PEP?
sonnyhas left
sonnyhas joined
PapaTutuWawahas left
Alastair Hoggehas joined
Alexhas left
Alexhas joined
inkyhas left
inkyhas joined
marmistrzhas joined
glickyonghas joined
moparisthebesthas left
pep.
Not that many useful errors in PubSub :/
marmistrzhas left
pep.
"Node Configuration Not Supported", "Insufficient Privileges", "NodeID Required", "No Configuration Options", "Node Does Not Exist"
pep.
(For nodes)
inkyhas left
debaclehas left
moparisthebesthas joined
goffihas left
Alastair Hoggehas left
atomicwatchhas left
me9has joined
atomicwatchhas joined
glickyonghas left
Alastair Hoggehas joined
machas left
machas joined
glickyonghas joined
emushas left
Alexhas left
Alexhas joined
glickyonghas left
me9has left
me9has joined
pulkomandyhas left
pulkomandyhas joined
nephelehas left
goffihas joined
stuart.j.mackintosh
If XMPP were to become very popular in a short time, what implemented mechanisms (client or server as appropriate) exist now to manage spam and uninvited / unwelcome direct connection attempts?
marc0shas left
marc0shas joined
machas left
machas joined
glickyonghas joined
me9has left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
Martin
https://github.com/JabberSPAM
Martin
There's a blacklist and in resources you found plenty modules for xmpp servers.✎
lovetoxhas left
stuart.j.mackintosh
Thanks Martin
lovetoxhas joined
inkyhas joined
rafasaurushas left
glickyonghas left
larmahas joined
rafasaurushas joined
Alacerhas joined
Alacer_dsrthas left
Alacer_dsrthas joined
Alacer_dsrthas left
Alacer_dsrthas joined
sonnyhas left
Martin
There's a blacklist and in resources you'll find plenty modules for xmpp servers. ✏
larmahas left
nephelehas joined
inkyhas left
Alacer_dsrthas left
marc0shas left
marc0shas joined
Alacerhas left
glickyonghas joined
alacerhas joined
rafasaurushas left
alacerhas left
lovetoxhas left
jgarthas joined
rafasaurushas joined
antranigvhas left
lovetoxhas joined
sonnyhas joined
machas left
machas joined
Neustradamushas left
machas left
machas joined
inkyhas joined
moparisthebesthas left
pulkomandyhas left
pulkomandyhas joined
Ingolfhas left
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
Ingolfhas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
nephelehas left
glickyonghas left
alhas joined
emushas joined
antranigvhas joined
machas left
machas joined
Yagizаhas left
marc0shas left
marc0shas joined
PapaTutuWawahas joined
debaclehas joined
machas left
machas joined
alhas left
inkyhas left
dezanthas joined
machas left
Yagizаhas joined
emushas left
bunghas joined
debaclehas left
bunghas left
inkyhas joined
bunghas joined
bunghas left
Yagizаhas left
machas joined
inkyhas left
msavoritiashas left
moparisthebesthas joined
inkyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
inkyhas left
marc0shas left
marc0shas joined
antranigvhas left
marc0shas left
marc0shas joined
atomicwatchhas left
pep.
Is there a way to know the room just got created when I join it?