jdev - 2021-11-10

Is there anyone who has done an implementation of Message Styling that would be interested in using a shared set of unit tests to ensure compatibility?

Sam: What do the unit tests do, check the rendering of items or so?

nephele: yah, they take in a message and spit out what parts of the message should have what styles

Ah, so it's unit tests for the parser part

Are these for https://xmpp.org/extensions/xep-0393.html ?

yes

I am reading it, I'm quite lost on what a child block is, is this only in reference to nested quotes?

Anyway, I want to implement message formatting for Renga at some point or another, If i can figure out how to include unit tests that could be quite neat to have the same ones

you can have unit tests in Renga by comparing the text_run_array in a BView with the expected output from the test, I guess? Sounds possible to do at least

I'm not sure if something like quotes could be represented with a text_run_array

the more i look into python xml libs the more i believe xmpps decision to not use prefixes is actually the weird thing that nobody does

i think one can say there i almost no support in libs for so called "default" namespaces

pythons etree.Element, has no way of setting a default namespace, nor parsing it

lxml supports them better, but it still fills like something which is a second class citizen

lovetox, I've no idea what you mean... an XML library either supports namespaces or it doesn't. XMPP doesn't do anything weird, and there's not really any such thing as a "default namespace" in XML (actually there is, but let's not go there)

i also thought that, but its not the case, or it depends what you mean by supports

if you parse that with pythons included xml lib

'<a xmlns="test" />'

you get an object and if you serialise it back its

'<ns0:a xmlns:ns0="test" />'

why the

fk would you implement xmpp in python

looks like a valid transformation?

looks like an excellent way to convince people that xml is scary and to use json instead

even though not an optimal one

flow how does that help me if xmpp says i should use no prefixes :D

should or must

i'd just say fuck it if its the first case

probably not much, but then again, I think, at least those kind of prefixes are fine

a different (and desirable) kind of prefixes are the ones that a declared in <stream/> ✏

those are probably likely to cause issues with certain impelementations

but not the prefixes that are introduced by the transformation you showed

assuming they are only done on a sub <stream/> level

so every server will be ok if i send

<ns0:message xmlns:ns0="jabber:client" />

because that would be great :D

Prosody will be fine. ``` > util.xml.parse[[<ns0:message xmlns:ns0="jabber:client" />]] <message xmlns='jabber:client'/> ```

lovetox, maybe not every server, but chances are high that the XML parser on the receiving end will handle it just fine

but still, the transformation is not space-efficient, so you may want to avoid it

maybe there is simple switch to change the behavior of serialiser?

space-efficiency would be to stuff a ton of namespace prefixes on the stream header

`<sm:r/>` etc

sure, but let's do baby steps and get this fixed first ✏

Zash, would prosody support namespace declartions in <stream/>? if so, announce it as stream feature and I'll implement an optimization in Smack for it

All that's handled transparently by libexpat, so should work fine

The receiving/parsing side at least.

Zash, then we should consider specifying a stream feature for this. so that clients can safely perform this optimization

as I have heard that other servers bail on it

Sure

But the stream feature comes after the client already sent the opening stream header...

Save it for the post-sasl stream restart

assuming we still have a stream restart in the future

Carry state between the unauthed and authed streams?!

😱️

Maybe, one day, we should redesign the whole stream startup thing.

if it's an non-TLS connection that its fine

otherwise you have to announce the feature after TLS

but before auth

I think this should be safe?

Make it client-first, where it sends all the extensions it wants, and the server picks the parts it likes

version='2.0'

Since this is the server telling the client things _after_ it has been authenticated with TLS & certs

no wait

aaaaargh, everything is backwards

or

so confused

Server does advertise things after it has been authenticated. Then the client authenticates. And then it does the thing.

So, should be fine?

simply in the stream features of step 8 in RFC 6120 § 9.1.1

then the client can declare the namespaces in step 13

so besides the <mechanisms/> in <stream:features/> you have a <namespace-prefixes-in-stream/> flag

as a bonus, after the restart, throw in a namespaced attribute on the opening stream header to tell the server it's okay to do the same thing

`<stream:stream to="example.com" ns:prefixes="ok" xmlns:ns="urn:xmpp:tbd:namespaces-prefixes">` something something