>This is about stopping XML libraries from _emitting_ anything that's outside our subset, no? Rather than the parsing being a problem.
Yeah, those guys love doing things beyond what you want from them. I remember being shocked to find out that even though python has *four* xml libraries built in, every single one of them is vulnerable, and vulnerabilities differ between them. So Gajim for example can't use one of those. It even had to reconfigure expat somewhat IIRC. Now how often do you hear of a vulnerability in say json or bencode? Let alone those responsibilities being kept in a mainstream PL like they're part of functionality.
<morning-rant>
It's almost like xml just like java somehow inherently leads to overengineering. I recently learned that people have built several PL around xml alone, like xquery or xslt. What the actual hell? And more concretely take xmpp. Why come up with the *unique* format? They couldn't just use length prefixes even with that same xml for example, no they had to come up with a unique complicated xml-esque format you have to invent your own way of parsing. I mean I really want to believe they did have some different philosophy in mind. Maybe they intended for it to be parsed directly with SAX somehow? But that'd be no less complicated would it.
Or take starttls. Why does it exist at all? Or srv ssl records. They couldn't just pick a standard ssl port like every other protocol does, of course, that's to simple for the xml mind. Or the mess that <message> generally is. When you receive it you have to work out if you're actually supposed to display it! I wonder what info at all that tag ends up conveying really. And then they come up with "message profiles", oh gosh...
The XEP that especially shows is the "aesgcm" one. Where the guy pretty much says "screw this it's too complicated to add even a single xml tag" and he comes up with an adhoc markup format lmao.
Other XEPs indicative of problems with XML are the various message text markup ones. XML is a freaking MARKUP language itslef yet people are so appalled by it they choose not to use it even in an XML based protocol. They either come up with their adhoc format, or that especially laughable XEP with " <span start="9" end="15"><emphasis/></span>". Like what the hell guys, what a perverted way with a markup language? This CANNOT be fully justified: either xml is problematic or the authors of the xep are (personally I think the former is the case)
</morning-rant>
>No, both sides are a problem. I remember an old (non XMPP, but similar issues) project where we ran into the <!proc exec cat /etc/passwd> or whatever it was issue. Turns out librarise out of the box were happy to do that, had no way to turn off all proc instances, and you had to know to turn it off.
Exactly what I'm talking about. It's insane. Let alone it just doesn't belong in a *markup* language. Not that a markup language belongs as a data serialization language in the first place
Johnhas left
adiaholichas left
restive_monkhas left
Alexhas left
Sam
Starttls exist for good reason, though I don't think it's useful these days. Back in the day though TLS and port numbers were expensive, so it was nice to be able to negotiate TLS over the same port you used for plain. SRV SSL records solve a real problem that other protocols that just pick a single port have too: sometimes even though there's a standard it's not on that port and you need service discovery.
Sam
Although I agree that starttls should just go away today and with basically everything about how XML has made things terribly complicated. The question is whether the tradeoff is worth it; eg. would it be *more* complicated to re-invent namespaces or some way of extending things in JSON where that's not just built in, for example.
Sam
I don't know what "message profiles" are though and have never really had any trouble figuring out if a message should be displayed, so I dunno about that one.
jcbrandhas left
wurstsalathas left
adiaholichas joined
kurisumakisehas left
kurisumakisehas joined
restive_monkhas joined
kurisumakise
> Although I agree that starttls should just go away today and with basically everything about how XML has made things terribly complicated. The question is whether the tradeoff is worth it; eg. would it be *more* complicated to re-invent namespaces or some way of extending things in JSON where that's not just built in, for example.
That is implying that namespaces are a necessary thing in the first place and not a pointless complication.
Steve Killehas left
Steve Killehas joined
Sam
Yes, that is what I was implying, though I admit that I go back and forth on that. There may be better ways of extensibility.
kurisumakisehas left
վարյաhas joined
kurisuhas joined
wgreenhousehas left
jgarthas joined
stphas joined
BASSGODhas left
wgreenhousehas joined
wgreenhousehas left
adiaholichas left
serge90has left
kurisuhas left
kurisuhas joined
adiaholichas joined
serge90has joined
adiaholichas left
վարյաhas left
adiaholichas joined
neshtaxmpphas left
neshtaxmpphas joined
moparisthebest
kurisumakise: json parsing is equally full of vulnerabilities, I mean the most popular way to parse it in JavaScript is just to eval it
kurisuhas left
moparisthebest
Turns out parsing untrusted input is hard
wgreenhousehas joined
kurisuhas joined
wgreenhousehas left
chronosx88has joined
msavoritiashas joined
վարյաhas joined
kurisu
Comparing "not braindead eval'ing input" to "discarding a good number of parsers because in them the vulns cannot be fixed, picking that one parser and *configuring* it so that it's not vulnerable, also you have to build the object model on top of that yourself or come up with some hack" isn't exactly fair is it
arcxihas left
arcxihas joined
u70jfzo5eyeb468b9ohas left
u70jfzo5eyeb468b9ohas joined
BASSGODhas joined
marc0shas left
marc0shas joined
alacerhas left
alacerhas joined
alacerhas left
վարյաhas left
wgreenhousehas joined
վարյաhas joined
moparisthebest
kurisu: what about "those who don't learn from history are doomed to repeat it" https://www.moparisthebest.com/images/jsonschema.jpg
druthidhas left
druthidhas joined
wgreenhousehas left
restive_monkhas left
wgreenhousehas joined
jgarthas left
Sevehas joined
wgreenhousehas left
atomicwatchhas joined
raghavgururajanhas left
restive_monkhas joined
wgreenhousehas joined
florettahas left
florettahas joined
wgreenhousehas left
andyhas joined
adiaholichas left
adiaholichas joined
atomicwatchhas left
pasdesushihas joined
jcbrandhas joined
kurisu
How many clients/servers actually end up verify xml schemas? Are those even available for most xeps? Also I can't see how they're useful anyway. Perhaps if you're coding in a low level or extremely verbose language like java, xml schemas can be more expressive than the language itself, but otherwise all verification can easily be done in the main programming language you are using along with processing. ✎
վարյաhas left
kurisu
How many clients/servers actually end up verifying xml schemas? Are those even available for most xeps? Also I can't see how they're useful anyway. Perhaps if you're coding in a low level or extremely verbose language like java, xml schemas can be more expressive than the language itself, but otherwise all verification can easily be done in the main programming language you are using along with processing. ✏
adiaholichas left
restive_monkhas left
restive_monkhas joined
adiaholichas joined
վարյաhas joined
Tobiashas joined
harry837374884has left
harry837374884has joined
COM8has joined
COM8has left
COM8has joined
COM8has left
adiaholichas left
adiaholichas joined
adiaholichas left
emushas joined
adiaholichas joined
wgreenhousehas joined
adiaholichas left
wgreenhousehas left
վարյաhas left
վարյաhas joined
adiaholichas joined
Yagizahas joined
neshtaxmpphas left
neshtaxmpphas joined
adiaholichas left
pasdesushihas left
inkyhas left
Alexhas joined
adiaholichas joined
Alexhas left
wgreenhousehas joined
Alexhas joined
Menelhas joined
wgreenhousehas left
adiaholichas left
adiaholichas joined
Rodhickshas joined
Rodhickshas left
sonnyhas joined
florettahas left
florettahas joined
kurisuhas left
sonnyhas left
sonnyhas joined
serge90has left
serge90has joined
kurisuhas joined
restive_monkhas left
վարյաhas left
վարյաhas joined
kyemxdenhas left
kyemxdenhas joined
adiaholichas left
pasdesushihas joined
alacerhas joined
alacerhas left
alacerhas joined
me4youhas left
restive_monkhas joined
adiaholichas joined
kurisuhas left
millesimushas joined
u70jfzo5eyeb468b9ohas left
Paganinihas left
u70jfzo5eyeb468b9ohas joined
me4youhas joined
sonnyhas left
sonnyhas joined
eabhas left
eabhas joined
tykaynhas joined
adiaholichas left
jjrhhas left
jjrhhas joined
jjrhhas left
jjrhhas joined
adiaholichas joined
lskdjfhas joined
kurisuhas joined
adiaholichas left
COM8has joined
COM8has left
millesimushas left
adiaholichas joined
florettahas left
Vaulorhas left
sonnyhas left
sonnyhas joined
lorddavidiiihas left
adiaholichas left
Titihas joined
Link Mauve
kurisu, schemas are not just here for validation, they also tremendously help with understanding how the thing works. In xmpp-parsers I wrote the parsers often just from the schemas, and sometimes fixed the schemas alongside (when they didn’t match the text or the examples).
Link Mauve
And yes, schemas are available for most XEPs.
Link Mauve
I personally don’t mind XML, I don’t even see it most of the time, the parsers are doing the parsing for me, I only go down to the XML form when the parser throws an error.
Link Mauve
And usually it’s the fault of the sending entity.
mjkhas joined
mjkhas left
mjkhas joined
adiaholichas joined
millesimushas joined
adiaholichas left
moparisthebesthas left
kurisuhas left
kurisuhas joined
adiaholichas joined
wgreenhousehas joined
millesimushas left
ti_gj06has joined
millesimushas joined
kurisuhas left
wgreenhousehas left
intosihas joined
moparisthebesthas joined
Steve Killehas left
Steve Killehas joined
florettahas joined
adiaholichas left
adiaholichas joined
COM8has joined
Wojtekhas joined
COM8has left
millesimushas left
restive_monkhas left
kurisuhas joined
flow
kurisu, you got my attention, do you have a pointer to a vuln in an xml parser that can be fixed?
adiaholichas left
wgreenhousehas joined
Wojtekhas left
huhnhas joined
Nekithas left
mjkhas left
mjkhas joined
wurstsalathas joined
homebeachhas left
Matthewhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Wojtekhas joined
emushas left
wgreenhousehas left
Wojtekhas left
Steve Killehas left
Wojtekhas joined
wgreenhousehas joined
eevvoorhas left
bunghas joined
adiaholichas joined
bunghas left
kurisuhas left
wgreenhousehas left
mjk
> all verification can easily be done in the main programming language you are using along with processing
You mean _languages_? In how many languages xmpp is implemented, again? If only there was a single language to describe formats and protocols...
Nekithas joined
karoshihas joined
kurisuhas joined
alacerhas left
alacerhas joined
adiaholichas left
goffihas joined
eevvoorhas joined
mjkhas left
mjkhas joined
lorddavidiiihas joined
adiaholichas joined
emushas joined
harry837374884has left
harry837374884has joined
adiaholichas left
ti_gj06has left
florettahas left
jl4has joined
Steve Killehas joined
eevvoorhas left
adiaholichas joined
վարյաhas left
Wojtekhas left
Rixon 👁🗨has left
homebeachhas left
uhoreghas left
Matthewhas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
kurisu
Link Mauve,
>chemas are not just here for validation, they also tremendously help with understanding how the thing works. In xmpp-parsers I wrote the parsers often just from the schemas,
is that the "crate parsing common XMPP elements into Rust structures."? Thing is with a more or less sane format like json you don't need to create any structures, you can just work with json "directly", it readily maps nicely into you PL's structures if it's high level enough.
A package like that just wouldn't need to exist if xmpp used a sane format.
> sometimes fixed the schemas alongside
lmao they don't even get those right. See how needlessly compilcated this is?
>I personally don’t mind XML, I don’t even see it most of the time, the parsers are doing the parsing for me, I only go down to the XML form when the parser throws an error.
you literally just described how you had to write a parser
flow,
indulge: https://docs.python.org/3/library/xml.html#xml-vulnerabilities
Also if there are any gajim devs here please confirm or deny this: some time ago I remember digging thru nbxmpp source and seeing they actually had to change expat's option so that it wouldn't retrieve DTDs. Not a vuln but just shows you how overcomplicated xml as a goddamn serialization format is if using a standard configuration would deanonymize you - if it can retrieve dtds it means expat carries networking code, which I'm pretty certain would not magically pick up your proxy options. Also just try and imagine how much code is in that parser if it can retrieve stuff from the internet. This is called bloat, and bloat leads to vulns. Also I think Sam here even mentioned an arbitrary code exectuion vuln he stubmled upon in some code he was working with. Now I'm not even sure if the devs of that xml lib used even considered this a vuln not a feature.
mjk, what do you even mean by this poor attempt at satire? Precisely my point, in every language you have to reinvent the parser to some degree because it's xml and moreover nonstandard xml. Are you refering to schemas being a single language for validation as a convenience?
Well, no one uses that. In most clients it isn't even possible because they reinvent DOM, because xmpp is nonstandard xml. So to validate schemas most would have to reinventing an xml schema parser and validator which would take so, so much more lines of code then just validating the xml in you language. Even then if some client manage through some hacks to use a standard xml library with a validator included, how many of those do you think choose to go for xml schema validation and not native language validation? Apparently next to none at all, given that Link Mauve here had to fix the schemas
As always, the xml/java/bloat mindset makes an issue out of a non-issue (validation) and thinks it's come up with a tool to solve it, and the tool ends up orders of magnitude harder to create, and probably even harder to use, than the original approach. ✎
kurisu
Link Mauve,
>chemas are not just here for validation, they also tremendously help with understanding how the thing works. In xmpp-parsers I wrote the parsers often just from the schemas,
is that the "crate parsing common XMPP elements into Rust structures."? Thing is with a more or less sane format like json you don't need to create any structures, you can just work with json "directly", it readily maps nicely into you PL's structures if it's high level enough.
A package like that just wouldn't need to exist if xmpp used a sane format.
> sometimes fixed the schemas alongside
lmao they don't even get those right. See how needlessly compilcated this is?
>I personally don’t mind XML, I don’t even see it most of the time, the parsers are doing the parsing for me, I only go down to the XML form when the parser throws an error.
you literally just described how you had to write a parser
flow,
indulge: https://docs.python.org/3/library/xml.html#xml-vulnerabilities
Also if there are any gajim devs here please confirm or deny this: some time ago I remember digging thru nbxmpp source and seeing they actually had to change expat's option so that it wouldn't retrieve DTDs. Not a vuln but just shows you how overcomplicated xml as a goddamn serialization format is if using a standard configuration would deanonymize you - if it can retrieve dtds it means expat carries networking code, which I'm pretty certain would not magically pick up your proxy options. Also just try and imagine how much code is in that parser if it can retrieve stuff from the internet. This is called bloat, and bloat leads to vulns. Also I think Sam here even mentioned an arbitrary code exectuion vuln he stubmled upon in some code he was working with. Now I'm not even sure if the devs of that xml lib used even considered this a vuln not a feature.
mjk, what do you even mean by this poor attempt at satire? Precisely my point, in every language you have to reinvent the parser to some degree because it's xml and moreover nonstandard xml. Are you refering to schemas being a single language for validation as a convenience?
Well, no one uses that. In most clients it isn't even possible because they reinvent DOM, because xmpp is nonstandard xml. So to validate schemas most would have to reinventing an xml schema parser and validator which would take so, so much more lines of code then just validating the xml in you language. Even then if some client manage through some hacks to use a standard xml library with a validator included, how many of those do you think choose to go for xml schema validation and not native language validation? Apparently next to none at all, given that Link Mauve here had to fix the schemas
As always, the xml/java/bloat mindset makes an issue out of a non-issue (validation) and thinks it's come up with a tool to solve it, and the tool ends up orders of magnitude harder to create, and probably even harder to use, than the original approach. Not even speaking of flexibility ✏
eevvoorhas joined
florettahas joined
flow
that table seems to say that xml parsers in python are maybe vuln to attacks that are based on features that we dont' use in XMPP and only if an outdated expat version is used
MattJ
kurisu, in >20 years of XMPP you're not the first to complain about it using XML. You won't be the last. What are you hoping to achieve with this discussion, exactly?
mjk
> Are you refering to schemas being a single language for validation as a convenience?
Yes.
> Well, no one uses that. In most clients it isn't even possible because they reinvent DOM, because xmpp is nonstandard xml.
I thought your argument was against xml schemas in general, I only used xmpp as an illustration of an xml format with wide cross-language implementation
flow
and disabling those features is trivial (at least for java), see https://github.com/igniterealtime/Smack/blob/5f75d141ff6d0494f0e548d549be25c04440fe24/smack-xmlparser-stax/src/main/java/org/jivesoftware/smack/xml/stax/StaxXmlPullParserFactory.java#L36-L40
Mikaelahas joined
emushas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
Link Mauve
kurisu, no, JSON doesn’t “map nicely” to XMPP elements in any programming language, it is way too inexpressive for that.
emushas joined
kyemxdenhas left
kyemxdenhas joined
Link Mauve
kurisu, no, I used a ready-made XML parser, and parsed that in domain-specific structs.
Link Mauve
Structs which are compile- and run-time checked for consistency, and which reject invalid states.
mjkhas left
mjkhas joined
moparisthebesthas left
flow
note that I'd also like if libraries would come with a secure default, I think at least some XML lib does, but I also believe there is a reason they don't (whether or not I agree with that reason is a different topic)✎
Link Mauve
This avoids having to carry DOM around btw, the structs being specific to XMPP are much more concise in memory.
flow
note that I'd also like if libraries would come with a secure default, I think at least some XML lib do, but I also believe there is a reason they don't (whether or not I agree with that reason is a different topic) ✏
flow
yeah, smack does something similar
moparisthebesthas joined
Link Mauve
kurisu, also, you mention validators but in the wild it’s usually preferable to ignore unknown elements and extensions than to outright reject them.
Link Mauve
Unless you have specific needs.
marc0shas left
marc0shas joined
flow
right, usually validation means, validating known elements, but ignoring unknown ones. only if you have specific needs, typically in form of increasing security by avoiding information leakage, you want to reject or strip unknowns
mjk
Link Mauve: do I understand correctly that there are, effectively, xml-schema→programming-language compilers thst emit validation (and data conversion) code?✎
marc0shas left
mjk
Link Mauve: do I understand correctly that there are, effectively, xml-schema→programming-language compilers that emit validation (and data conversion) code? ✏
marc0shas joined
Link Mauve
mjk, there probably are, although I never used one.
Nekithas left
mjk
Ah
Link Mauve
I wrote xmpp-parsers to do this kind of validation, but using more domain-specific types than XML Schemas allow.
mjk
I see
Wojtekhas joined
mjk
So, you were the compiler :)
Holger
Sounds very similar to what ejabberd does.
Link Mauve
XML Schema lists what is allowed where, with some typing, but they don’t encode enough for me to generate the parsers and serialisers just from that.
flow
mjk, not sure about the data conversino part, but there are XML parsers that you can hand a schema which will cause them to report schema violations✎
Link Mauve
Yes, zinid and I had the same idea at roughly the same time. :)
marc0shas left
L29Ahhas left
marc0shas joined
L29Ahhas joined
flow
mjk, not sure about the data conversation part, but there are XML parsers that you can hand a schema which will cause them to report schema violations ✏
flow
mjk, not sure about the data conversion part, but there are XML parsers that you can hand a schema which will cause them to report schema violations ✏
adiaholichas left
kurisu
MattJ: I also notice that in 20 years xmpp hasn't had many good clients developed for it. Even the major ones still are buggy. As much as I like the idea of a federated messenger, I'm starting to think there's some flaw inherent to the protocol that prevented it from taking off.
I thought of trying to implement a client myself in my spare time. Well, it turns out the very serialization format is quite a stumbling block. So I thought maybe I'm just misunderstanding something, maybe e.g. I wasn't supposed to try and build a dom but e.g. work with sax events directly? More of curiousity at this point, as stated I'm just wondering what the original authors intended
Link Mauve,
>no, JSON doesn’t “map nicely” to XMPP elements in any programming language, it is way too inexpressive for that.
You're being dishonest. XMPP is written in xml and you can't express xml more effeciently in json, true. However, the data conveyed by xmpp doesn't map nicely into xml in the first place. Take the list of mechanisms in stream:features. Not to mention how the xml format has no notion of a list. What does your library do with stream:features/mechanisms/mechanism/text()? Create whatever a list is called in rust? Well guess what, in a sane format like json it would already be a freaking list.
Xml isn't to blame for not having a notion of a list, it's but a markup language afterall, not a data serialization one. It is however notable that even as a markup language it fails: xmpp doesn't use xml for markup like it was intended, it has to come up with an adhoc format in one xep and a laughable hack in another.
So yes, unfortunately, because of the usage of xml you can't easily create a json version of xmpp. Because xml has its own object model of tree and nodes and attrs and whatnot on top of which actual structures like "a list of strings" have to be hacked on.
This is in comparison to e.g. the torrent dht protocol: you could easily convert it to json or almost any other sane format because the initial format is sane. Because they don't use a markup language for data serialization. Because there are lists, dicts, strings ints and so on. Same goes for FCP, freenet's adhoc protocol. I've been developing something for freenet you see, and had to use said protocol, which didn't have a library for it in my language of choice. Well guess what it's been a freaking breeze to create my own parser. Funny how an adhoc,"afterthought" data serialization format is more pleasant to work with than xml
>This avoids having to carry DOM around btw, the structs being specific to XMPP are much more concise in memory.
Speaking of memory concise when speaking of xml.. ironic.
>also, you mention validators but in the wild it’s usually preferable to ignore unknown elements and extensions than to outright reject them.
and?
jonas’
kurisu, given that things like whatsapp are based on XMPP, it's certainly not a flaw inherent in the protocol preventing it to be used for something useful.
jonas’
it's just that nobody has made a business plan which supports the federated use case, so no moneys.
kurisu
jonas': whatsapp has unlimited budget and thus manpower. With enough thrust even a pig will fly.
Ge0rG
jonas’: well, that _is_ a flaw in the protocol, as viewed from the perspective of lock-in startups ;)
mjk
> there are XML parsers that you can hand a schema which will cause them to report schema violations
That much I know. :) I was thinking more in the direction of compiling a single xml schema to byte- or machine code to produce a very efficient specialized validator/parser
jonas’
Ge0rG, federation is not mandated by the protocol
Ge0rG
jonas’: but client interop is
flow
I also think that relatively young clients like Conversations and Dino demonstrate that it is possible to implement XMPP from scratch
Link Mauve
kurisu, have a look at ActivityPub, I had the misfortune of digging into it, it’s JSON-LD all the way down.
Link Mauve
I’ll take XMPP’s XML any day over that abomination.
Link Mauve
You might like it better, maybe.
Link Mauve
It does pretty much the same as XMPP, provides authentication, message passing, pubsub, etc.
That makes it a natural fit for a Prosody module!.. Wait, Lua has integers now
Johnhas joined
marc0shas left
marc0shas joined
sonnyhas left
restive_monkhas joined
sonnyhas joined
me4youhas left
me4youhas joined
mathieui
I don't know why we are having this discussion, apart from ranting it will solve nothing and enlighten exactly nobody. The points being made are laughable to me for the most part (the lack of modern clients is that the "legacy" clients were good enough, until they weren't, and mobile-first with awful OSes and lack of proper networking were a big hurdle, that has nothing to do with XML, we had a good markup solution using XML elements 20 years ago already but I won't go back to this debate). The one I will acknowledge is that it is slightly harder to bootstrap a client from nothing, and that is mostly because it requires quite a bit of RFC diving and domain knowledge. But comparing XMPP to FCP or the torrent DHT protocol is disingenuous at best, considering the specialised and narrow target of what they are set to achieve.
Vaulorhas joined
edhelas
+1
mathieui
I have never used XML outside of XMPP, except for configuring openbox or writing web stuff, but I have seen complex data types and schemas in JSON and YAML and it certainly is not an pleasant sight.
L29Ahhas left
debaclehas joined
L29Ahhas joined
mathieui
(I'm not saying I don't like rants or ranting, but maybe there are other rooms that can better accommodate it than this room where people expect productive discussion, because no, XMPP is not switching to bencode tomorrow)
flow
I am surely biased, but my impression is that the provided arguments against XMPP/XML are exaggerating the situation while additionaly describing it not precisely nor technically sound
Holger
And I don't buy the implication that there're obvious/simple alternatives. I.e. just avoid XML, reinvent everything from scratch and suddenly an extensible messaging spec becomes a simple, straightforward problem to solve, validation now is a non-issue and whatnot.
Holger
What I do buy is that JSON over HTTP does a much better job at on-boarding devs, being able to show a simple `curl` example for sending a message is a huge win.
Daniel
seemingly atomic operations are a plus too
mjk
Seemingly atomic or seemingly a plus? :)
Daniel
seemingly atomic
adiaholichas joined
Daniel
because any complex http+json protocol will have some kind of discovery / feature negotiation
wgreenhousehas joined
mjk
Yeah
xeckshas left
xeckshas joined
wgreenhousehas left
inkyhas joined
millesimushas joined
dwd
I still say that if we described XMPP has having a "JSX-like wire protocol" we'd be fine.
florettahas left
kyemxdenhas left
kyemxdenhas joined
adiaholichas left
dwd
Anyway, the reality is that XMPP's biggest problems are that it's a connection-orientated protocol that connects clients. There's ways around both, but they require some effort to shift to a protocol that connects users with multiple clients. XML isn't really a problem, exce4pt that people perceive it to be one and get very hung up over it when they start.
intosihas left
intosihas joined
dwd
I think the XML problem is much less problematic than people think it is, but only because XMPP really doesn't use XML as much as it uses some serialization and namespacing from XML. And that's very hard to explain, when people see XML and assume we're built on SOAP.
adiaholichas joined
dwd
The "connection-orientated" problem is another conceptual problem, but also has technical problems. Mobile phones and suchlike simply cannot hold a connection open - a flaw in their design, but one we need to deal with. I've tried addressing this with XEP-0198 and persisting sessions beyond TCP connections, and I think that works, especially given the increasing need to persist a lot of information about clients in use. But that's met with resistance and I'm out of energy.
dwd
Similarly, the clients versus users problem; we have a series of half-solutions in that space too, but again, no energy.
dwd
And, of course, we're dealing with Matrix, which has a nice set of shiny clients, and a marketing/sales team happy to distort the truth as much as they can, which is stealing away a lot of market share.
adiaholichas left
Daniel
addressing both persistent connections AND clients v users is so overwhelming that it sometimes feels like we might as well start over
lorddavidiiihas left
wgreenhousehas joined
Rixon 👁🗨has left
homebeachhas left
uhoreghas left
Matthewhas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
Wojtekhas left
lorddavidiiihas left
dwd
Oh, note I didn't say "persistent connections", I said "connection-orientated". They're somewhat different.
intosihas left
kurisuhas left
lorddavidiiihas joined
neshtaxmpphas left
neshtaxmpphas joined
lorddavidiiihas left
dwd
And clients v users feels achingly close to solved, some days. In fairness, it's easier to go in this direction than the other - a lot of effort on IMAP went on going from user to multiple clients, and it was *hard*.
lorddavidiiihas joined
kurisuhas joined
lorddavidiiihas left
intosihas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
rafasaurushas left
rafasaurushas joined
lorddavidiiihas joined
lorddavidiiihas left
intosihas left
lorddavidiiihas joined
COM8has joined
COM8has left
lorddavidiiihas left
florettahas joined
intosihas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
dwd
The other thing we could do - and I gave it some thought a while back - would be to define a server-side client and a standardized traditional HTTP API (whether graph or RESTish).
lorddavidiiihas joined
lorddavidiiihas left
dwd
That's somewhat akin to what Lloyd Watkin did a few years back, mind, but perhaps taking things a bit further.
ti_gj06has joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
intosihas left
djorzhas joined
intosihas joined
lorddavidiiihas joined
nycohas left
lorddavidiiihas left
Link Mauve
dwd, mod_rest in Prosody is already kind of like that I think.
Link Mauve
Minus the standardisation.
lorddavidiiihas joined
lorddavidiiihas left
papatutuwawahas joined
papatutuwawahas left
papatutuwawahas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
dan.caseleyhas left
dan.caseleyhas joined
adiaholichas left
lorddavidiiihas left
Wojtekhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
Titihas left
tykaynhas left
pasdesushihas left
lorddavidiiihas left
nycohas joined
lorddavidiiihas joined
lorddavidiiihas left
tykaynhas joined
Titihas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
jonas’
huh
lorddavidiiihas left
jonas’
so
jonas’
there is that idea of tracking devices
jonas’
if we were to track devices and had device-specific tokens which are good for, say, a day or so.
jonas’
and which can be renewed via a proper connection with SASL
jonas’
and those token would, while valid, represent a session with smacks and push and whatnot and could be used with a mod_rest-ish interface
pasdesushihas joined
jonas’
that would be like 95% of what's needed to resolve the connection-oriented stuff, right?
jonas’
and it doesn't seem that complex
lorddavidiiihas joined
ti_gj06has left
jonas’
I mean, tracking devices and per-device auth is a bit of work, but there are people interested in solving that anyway (I think Snikket is, even if only for proper multi-device onboarding and management)
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
florettahas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
chronosx88has left
chronosx88has joined
lorddavidiiihas joined
lorddavidiiihas left
Wojtekhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
MattJ
I definitely wouldn't say "if only for" - I think the server having no knowledge of a user's clients is one of the big things holding us back right now
MattJ
We do, sort of, have this knowledge already (XEP-0198, push registrations) but it's incomplete and fragmented
intosihas left
florettahas joined
intosihas joined
lorddavidiiihas joined
lorddavidiiihas left
bunghas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
restive_monkhas left
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
restive_monkhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
John
CSS of the wiki pages does not look right on my phone using Chrome https://wiki.xmpp.org/web/Main_Page
lorddavidiiihas joined
Wojtekhas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
intosihas left
andrey.ghas joined
lorddavidiiihas joined
lorddavidiiihas left
intosihas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
jl4has left
kurisuhas left
kurisuhas joined
adiaholichas joined
intosihas left
atomicwatchhas joined
intosihas joined
lorddavidiiihas left
Wojtekhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
kurisuhas left
intosihas left
kurisuhas joined
Wojtekhas joined
intosihas joined
dan.caseleyhas left
x51has joined
nycohas left
dan.caseleyhas joined
nycohas joined
Johnhas left
lorddavidiiihas joined
mjkhas left
mjkhas joined
nycohas left
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
papatutuwawahas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas left
adiaholichas joined
adiaholichas left
neshtaxmpphas left
neshtaxmpphas joined
adiaholichas joined
nycohas joined
kurisuhas left
restive_monkhas left
kurisuhas joined
adiaholichas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
Johnhas joined
lorddavidiiihas joined
kyemxdenhas left
kyemxdenhas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
restive_monkhas joined
andrey.ghas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
andrey.ghas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Vaulorhas left
COM8has joined
lorddavidiiihas joined
lorddavidiiihas left
COM8has left
COM8has joined
COM8has left
andrey.ghas left
adiaholichas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
restive_monkhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Vaulorhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
kurisu
dwd:
> And, of course, we're dealing with Matrix, which has a nice set of shiny clients, and a marketing/sales team happy to distort the truth as much as they can, which is stealing away a lot of market share.
Sales team? How do they make money?
Sam
kurisu: it's created by a VC funded company that sells consulting services and maintains the only usable clients
lorddavidiiihas joined
Zash
and hosting
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
kurisu
Sam: someone pays for matrix related consulting? What sort of consulting I wonder
kurisu
Anything similar seem happening with xmpp?
andyhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Daniel
> Anything similar seem happening with xmpp?
That's how a good amount of the people working within the XSF make a living
lorddavidiiihas joined
Daniel
See https://xmpp.work/all-listings/ for example
lorddavidiiihas left
lorddavidiiihas joined
neshtaxmpphas left
neshtaxmpphas joined
eabhas left
florettahas left
Mikaelahas left
florettahas joined
restive_monkhas joined
emus
> Daniel escribió:
> See https://xmpp.work/all-listings/ for example
Btw reminder to everyone here to place make their entries as I plan to advertise sooner or later
wgreenhousehas left
jl4has joined
papatutuwawahas joined
MattJ
emus, Process One are missing, you may want to reach out to them directly
emus
yes ok thanks!
emus
any contact recommendations?
arnehas left
arnehas joined
jl4has left
jl4has joined
pjnhas left
COM8has joined
COM8has left
pjnhas joined
reimarhas joined
jonas’
emus: you could try the ejabberd muc
arnehas left
Wojtekhas left
emus
jonas’: oh surez totally forgot
jl4has left
jl4has joined
arnehas joined
wgreenhousehas joined
arnehas left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Matthewhas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
arnehas joined
arnehas left
arnehas joined
kurisuhas left
kurisuhas joined
intosihas left
intosihas joined
Wojtekhas joined
Wojtekhas left
harry837374884has left
dwd
kurisu, Lots of consulting, but also Element have a bunch of pay-for addons. Most of what Matrix is being used for is bridging, as far as I can see. But their Teams and WhatsApp bridges are not open source, but per-seat licensing.
dwd
Sam, You're wrong, of course. Matrix is maintained by a foundation which is entirely seperate from Element, and just happens to have the same staff, infrastructure, and accounts.
Sam
Heh, oh yes, silly me, how could I ever forget
dwd
In any case, I've been told by people that XMPP can't do picture messaging, for example. They've been told this by Matrix/Element sales staff. Of course, the Matrix bridge is curated carefully to prevent anything nice from working, so it appears this way, but...
intosihas left
intosihas joined
rafasaurushas left
moparisthebest
Also matrix invented the concept of bridging, nothing else had this decades before
rafasaurushas joined
adiaholichas left
wladmishas joined
kurisuhas left
adiaholichas joined
Wojtekhas joined
Ge0rG
I feel severely insulted as the developer of the matrix client with the longest code history.
adiaholichas left
Shackletonhas joined
adiaholichas joined
marc0shas left
marc0shas joined
nycohas left
goffihas left
intosihas left
mjkhas left
neshtaxmpphas left
Shackletonhas left
mjkhas joined
Paganinihas joined
me9has joined
neshtaxmpphas joined
roccohas joined
intosihas joined
Wojtekhas left
neshtaxmpphas left
neshtaxmpphas joined
marc0shas left
marc0shas joined
Wojtekhas joined
John
dwd: I'm in a MUC has bridge with Matrix and Discord, I can download files but can't open them. Is that intended?
wladmishas left
nycohas joined
adiaholichas left
neshtaxmpphas left
neshtaxmpphas joined
adiaholichas joined
neshtaxmpphas left
neshtaxmpphas joined
intosihas left
alex11has left
intosihas joined
Mikaelahas joined
roccohas left
wgreenhouse
John: bridged by a bot, or using bifröst?
harry837374884has joined
andyhas joined
wladmishas joined
pjnhas left
rionhas left
neshtaxmpphas left
neshtaxmpphas joined
adiaholichas left
adiaholichas joined
marc0shas left
marc0shas joined
pjnhas joined
Wojtekhas left
Wojtekhas joined
wladmishas left
intosihas left
wladmishas joined
goffihas joined
John
wgreenhouse: I'm not sure, I think bot, I can see the Matrix users as participants in the MUC, like in other transports
intosihas joined
jl4has left
Menel
If you can download, and not open, its a problem of your OS isn't it?
adiaholichas left
papatutuwawahas left
John
Menel: I tried to download using Conversations. You can try https://matrix.andrzejszczepaniak.co.uk/_matrix/media/v1/download/t2bot.io/15c36c5778f007732c5b98139069f93a6a8e91f9
Maranda: I see the link as a plain text, no download button
Maranda
That depends on mime / size and C related configuration iirc
intosihas left
stpeterhas joined
stpeterhas left
Maranda
I don't recall issues with the oob element in the stanza itself, but if that's the case just give me a poke and I'll fix what runs on aria-net.org at least
wladmishas left
wladmishas joined
Zash
No OOB there.
Zash
Presumably because of the module that stops you from posting pictures here.
Ge0rG: to be able to sent pictures?
It is the bridge you are paying?
benhas left
Ge0rG
msavoritias: posting pictures in this room is only allowed to members since The Incident. The "premium" part was just a bit of irony about membership being paid in most places (but not here)
intosihas joined
msavoritias
Ah. Totally missed the joke on my part :p
I just assumed it to be a matrix closed feature out of habit
me9has left
huhnhas joined
harry837374884has left
restive_monkhas left
raghavgururajanhas joined
Wojtekhas left
intosihas left
Wojtekhas joined
inkyhas left
wladmishas left
wladmishas joined
adiaholichas joined
wladmishas left
intosihas joined
jl4has joined
florettahas left
Johnhas left
eabhas joined
inkyhas joined
eabhas left
eabhas joined
jl4has left
jl4has joined
florettahas joined
intosihas left
adiaholichas left
adiaholichas joined
intosihas joined
Yagizahas left
Wojtekhas left
kyemxdenhas left
kyemxdenhas joined
kyemxdenhas left
kyemxdenhas joined
huhnhas left
Mikaelahas left
marc0shas left
marc0shas joined
stpeterhas joined
stpeterhas left
intosihas left
papatutuwawahas joined
adiaholichas left
jl4has left
adiaholichas joined
sonnyhas left
sonnyhas joined
intosihas joined
jl4has joined
BASSGODhas left
marc0shas left
marc0shas joined
BASSGODhas joined
adiaholichas left
me9has joined
msavoritiashas left
adiaholichas joined
jl4has left
adiaholichas left
Johnhas joined
Johnhas left
Johnhas joined
paulhas left
intosihas left
Nekithas joined
intosihas joined
Titihas left
kyemxdenhas left
kyemxdenhas joined
rafasaurushas left
rafasaurushas joined
x51has left
jl4has joined
jl4has left
intosihas left
kyemxdenhas left
kyemxdenhas joined
stpeterhas joined
stpeterhas left
millesimushas left
adiaholichas joined
paulhas joined
stpeterhas joined
stpeterhas left
adiaholichas left
reimarhas left
intosihas joined
adiaholichas joined
Johnhas left
Johnhas joined
papatutuwawahas left
adiaholichas left
stpeterhas joined
stpeterhas left
Tobiashas left
jjrhhas left
jjrhhas joined
Maranda[x]has left
Matthewhas left
Rixon 👁🗨has left
uhoreghas left
homebeachhas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Maranda[x]has joined
adiaholichas joined
florettahas left
adiaholichas left
adiaholichas joined
lorddavidiiihas left
adiaholichas left
Menelhas left
Sevehas left
pasdesushihas left
intosihas left
adiaholichas joined
intosihas joined
adiaholichas left
jjrhhas left
jjrhhas joined
BASSGODhas left
BASSGODhas joined
adiaholichas joined
adiaholichas left
florettahas joined
intosihas left
arcxihas left
jcbrandhas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Syndacehas left
kurisuhas joined
Syndacehas joined
emushas left
bunghas left
Johnhas left
Johnhas joined
kurisu
moparisthebest:
> Also matrix invented the concept of bridging, nothing else had this decades before
Matrix bridges are well integrated into clients. Now to use xmpp bridges to just irc I had to actually ask about working instances on biboumi chat (b/c you can't just google them, let alone connect automatically), then also find out which ones work lmao. I think we should give credit where credit's due
mathieui
kurisu: I fail to see the links between your three statements
kurisu
Try being honest with yourself and you will
mathieui
I haven't dabbled in matrix clients in a while so I will ignore the first, the second is more about having a SPOF with a humongous IRC bridge on matrix.org, as far as I understand it?
mjk
Aren't matrix bridges practically centralized? In which case there's nothig to discover
mathieui
(I am not saying it does not work, or that the matrix IRC bridging is not a success, although I find it to be a bit abrasive from the IRC side, but I fail to see how it is relevant)
Alexhas left
kyemxdenhas left
Johnhas left
Johnhas joined
moparisthebest
kurisu: are you saying the matrix clients have the IRC gateways hardcoded? Doesn't sound very federated to me
moparisthebest:
> kurisu: are you saying the matrix clients have the IRC gateways hardcoded? Doesn't sound very federated to me
I don't know, I only know that it just werks
And no, builtin gateways don't harm federation. At the end of the day Conversations by default offers its server, is that a problem now?
moparisthebest:
> kurisu: https://www.moparisthebest.com/images/xmpp-vs-matrix.jpg
I wish that honesty were the case irl.