XSF Discussion - 2024-03-09

anyone has any points for this https://about.psyc.eu/XMPP#Technical_Problems_with_XMPP the context is somebody was saying they wanted to adapt xmpp to work over gnunet, which coincidentally is something i am doing :P and they got a reply here https://lists.gnu.org/archive/html/gnunet-developers/2024-03/msg00020.html besides the usual misinformation about "video" is not in the core protocol and xmpp is not p2p i was wondering about the link they sent

from a quick look it seems to push their own binary format

im drafting a reply atm :)

framing has been mentioned before as I remember

https://xkcd.com/386/

pretty much yeah ^^'

MSavoritias fae.ve, framing is also done in XMPP-over-Websockets, maybe that's something worth directing them at

will do. replied on other stuff so im going through the article now

also tell them about SAX and streaming parsers -- I only know of one implementation which uses counting of `<` / `>` instead of proper sax-style parsing for XML streams, that's definitely not commonplace.

this is also bogus " XMPP does not allow unescaped use of > according to the XML spec (see also Mr. Karneges' mail). "

though I note that rxml::writer does indeed escape `>`...

ah ralph is mentioned > When asked about multicast, Ralph Meijer, member of the XSF Council, stated in a conversation at the FSW2011 that you cannot entrust subscriber nodes to correctly forward your message to further subscribers. They might censor or fake messages. FETHR approaches this problem by applying digital signatures and using hash chains. It's not such an attractive option for XMPP however, since all this cryptographic data cannot be transmitted in native binary form – inefficient base64 encoding is needed instead, but it would probably still be better than giving up on efficient distribution altogether.

it basically talks about multicasting in xmpp and also mentions this https://xmpp.org/extensions/xep-0253.html but this is above my knowledge i am afraid

they are basically saying that presence stanzas are a bottleneck. but afaik newer MUC and MIX and generally xmpp is relying less on the endless presence stanza around.

the article was more interesting than i thought actually because i wasnt aware xmpp has been forked before. and some efforts they did around improving xmpp. that was at 2006 mind you

MSavoritias fae.ve: it is wildly inaccurate to suggest that xmppnetwork.goodbytes offers an up-to-date server count. I know of many, many thousands of servers that are not on there.

i know. thats why i added > its opt-in tho so not every server is there. in the next line

s.j.n, at this point in time, knows about about ~1500 domains ✏

s.j.n, at this point in time, knows about ~1500 domains ✏

(which is not identical to "servers")

Still, that suggests that it is a representation of a good deal of the network. It really really isn't.

after i saw the article is from 2006 to 2008 probably? i just left it there too many points to address

322 of the domains identify as "user account server"

my point was that it shows that its not a "few" big servers because xmpp cant scale

as suggested in the article

not that we are many. anything above 100 is good anyway to show that it scales

imo at least

Fair. I'm just cautious about people thinking that my site gives any kind of accurate representation

personally i think when somebody says: stickers are not integrated natively into the protocol, and we should fork telegram server/client and convert it to another OSI model the argument is suspect from the beginning

sure

that was what was proposed in the email

Heh

and i mean the *whole* OSI

not just a protocl

also (re that wiki article again) it may be worth pointing out that the things XMPP disables are by no means related to "the full potential of XML". They are security vulnerabilities waiting to happen. The full potential of XML is built-in namespacing.

yeah. i still have a lot to read and implement because i want to understand what namespaces are, why xmpp doesnt use them much, and why we should

we use them a lot

the only thing we don't use are namespaced attributes because people are afraid that some obscure parsers may break at them

any link what are namespace attributes?

namespace*d* attributes

that

example: <foo a="b" xmlns:ns0="http://example.com/some-ns" ns0:a="c"/>

`a` is a namespace-less attribute (very common), ns0:a is an attribute `a` in the namespace `http://example.com/some-ns` ✏

I have so much fun at the expense of people insisting that XML is terrible, only for them to get bogged down with Json schema ...

right. so if we had namespaced attributes then we could scope ns0 to that namespace

even in `<ns0:foo a="b" xmlns:ns0="http://example.com/some-ns" ns0:a="c"/>`, `a` is namespace-less (but sementically still associated with `ns0:foo`, it's a bit icky in that corner of the XML standards)

https://www.w3.org/TR/REC-xml-names/ for the full namespacing spec

MSavoritias fae.ve, I'm not sure I understand.

> I have so much fun at the expense of people insisting that XML is terrible, only for them to get bogged down with Json schema ... yeah and the article is just comparing xmpp to what an ideal protocol with perfect efficiency would look like. but guess what tech is never optimal so :P

> MSavoritias fae.ve, I'm not sure I understand. i was thinking that we cant "assign" or namespace that ns0 to a because we dont have namespaced attributes. so ns0 needs to be unique to a xml document

ns0 is the namespace prefix

but will read the w3 rfc to understand

yeah, do that, I guess.

It's a bit hard to explain in a text conversation without a whiteboard otherwise :)

yeah xml is still magic to me. sure :) ✏

> In XEP-0343, the `&lt;sctpmap&gt;` elements use `number` attribute for the port in all the examples, but the §4.2 syntax says to use `port` instead. Which one must be used? Is the author (Jens Bavendiek) here? goffi Daniel from what I see the only thing I did is the Jingle <-> SDP conversion of the element, nothing more ↺

My whole media stack is actually handled by the browser, so I just pass the SDP to it and it "deals with it"

edhelas, yes thanks. that’s confirming what i thought

edhelas: OK I see. Why is XEP-0343 advertised in your DOAP then? Thanks for the update.

Anything to do with https://en.wikipedia.org/wiki/Goodhart's_law ?

Namespaced attributes, they're coming! See 0463 :)

> edhelas: OK I see. Why is XEP-0343 advertised in your DOAP then? Thanks for the update. I'll change it to partial support, there's partial SCTP support in the browsers ↺

Daniel: in your gist, I see a proprietary namespace ("http://gultsch.de/xmpp/drafts/jingle/transports/ice-udp/option"). I'd really like to avoid the OLDMEMO situation with proprietary namespace and people starting to build on this. Would it be possible to make protoXEP with proper namespace of that?

edhelas: but at this stage we can't do data channel with Movim at all, it's misleading to see it in supporting client. For instance, I was planning to test it with Movim because I saw it in supporting clients list.

goffi: fwiw you don't need this for data channels

That's unrelated and just me copy pasting stuff directly from the debug output

OK

> I have so much fun at the expense of people insisting that XML is terrible, only for them to get bogged down with Json schema ... Mouhahah, /me uses JSON Schema for XML purposes 😈️ ↺

> edhelas: but at this stage we can't do data channel with Movim at all, it's misleading to see it in supporting client. For instance, I was planning to test it with Movim because I saw it in supporting clients list. Guess I'll just remove it ↺

edhelas: probably better for now. But would be nice to have Jingle FT with data channel on Movim, it's a really neat feature in web clients.

and with Jingle already implemented, the most difficult part is already done.

> the only thing we don't use are namespaced attributes because people are afraid that some obscure parsers may break at them I use namespaced attributes. But I agree it's not popular in most xeps ↺

use them more, make people get over their fear

I should draft link preview this year, which is one place I'm using them because link previews are rdf

seen any server or client choke on that?

Not yet

supports my theory that this was 95% FUD.

Daniel, larma: after reading a bit more, your change seems sensible. Indeed XEP-0343 is a streaming transport based on UDP, so it makes sense to encapsulate it. I'll do the implementation based on Daniel's gist, but I feel uncomfortable to work like this, with unofficial spec (make me think about the bad side of ActivityPub). I know that you are all busy and all, but do you have to publish a XEP update with your change in coming weeks? I can help if necessary.

*do you have plan to publish a protoXEP

no XEP update, not protoXEP sorry

lovetox, Gajim is marked as "partial" for XEP-0377. I assume that's because it supports reporting JIDs but not messages, or something?

tmolitor, why is Monal marked as "wontfix" for XEP-0377 (spam reporting)?

you mean attaching the stanza-id?

Yeah

yeah we dont do this yet

is this important?

or rather helpful?

It's helpful, not essential

should be trivial to add, i will add a issue for it on the tracker

Thanks! Let me know if you need any help testing

I made https://xmppbl.org/software with an overview of the state of implementations (to the best of my knowledge/research so far)

Ah great! Maybe tracking issues could be added as well, once there are some