XSF Discussion - 2022-04-07

goffi: as a module to an existing server?

any source code I could look at?

> goffi: as a module to an existing server? As a component with my pubsub component. No code published yet, I'm updating XEP-0356 implementation in it and Prosody first.

does the specs allow for (non-namespaced) attributes to be added to message/iq/presence stanza elements?

`<message foo='bar' ... `

Yes officer, this message right here ↑

Guus, have fun with the protocol police 😉

Woop woop~

Guus, most certainly not

Meanwhile, in Matrix: -- This is not the protocol violation you're looking for *waves hand, making the protocol support it* -- Woah...

use namespaced attributes, they're there for that use case

or stuff it in a namespaced element

or that, but you can't do that for IQs

Please don't shove new stuff in a stanza header, I would expect most of the world to break in that case.

I expect half the world to pass it along to the other half, where it'll break.

one half being prosody, the other half being ejabberd?

I'm asking because I was amazed that I'm looking at client traffic that does it, without it breaking in dramatic ways.

are _namespaced_ attributes on those elements even ok?

Not really.

Slightly less not okay at least.

We're bad at documenting our extension points, though.

It's XML! Everywhere's an extension point if you namespace it!!

You'd need to somehow add the namespace to the ... stream element? Feels pretty messy.

So, yeah, shove it in a child element somewhere.

to make you share in my misery, I'm looking at an attribute on a message stanza that starts with this:

no no noooooooo

`sensorList="{&quot;data&quot;:[{&quot;type&quot;:&quot;sensorOne&quot;,` followed by slightly over 2000 characters

and that's just one of those attributes. :D

JSON inside a default-namespaced attribute on a message stanza. I don't see what could possibly go wrong.

Really, what's the odd Eldritch Horror between friends? ✏

but as I said: this doesn't break, apparently.

I think you've just not found the myriad places it breaks, yet :)

Guus, no you don't have to declare it on the stream header, you can <message xmlns:foo='bar' foo:fnord='xyz'/> ✏

jonas’ ah yes. Still not a good idea probably.

Kev: let me put it this way: it's running in production, but they're now reaching out because of some issues.

Oh, I'm happy to believe that given some controlled subset of software it might work. Just that I would expect it to break in the general case.

Guus, show them https://xmpp.org/extensions/xep-0432.html

(also: hardcoded stanza IDs)

Zash: but it has a big red warning on top of it! must be worse than rolling our own!

(should we make those warnings slightly less off-putting by renaming them to 'beware' and print them in a color that's not firetruck-orange?)

Guus: Or push for advancement?

this sounds like a low-hanging push-for-advancement fruit indeed

Zash we can do that for individual XEPs - I was trying to go for a more generic approach.

I think I even added that to mod_rest

RFC6121 8.4 explicitly states that 'extension attributes' _are_ allowed, I think. See https://datatracker.ietf.org/doc/html/rfc6120#section-8.4

Is now the time to remember how the `@c` attribute in `<a xmlns="b" c="d"/>` isn't in the "b" namespace?

XML prefixes

as jonas showed earlier.

Like `xmlns:extension="blah" extension:attr="moo"`, yeah that's fine.

`xmlns:prefix="uri" prefix:c="yey"`

yeah, exactly.

Guus: Yes, it does. I predict it would still break things.

It will break broken things

Sure. Whereas doing it inside jabber:client will break unbroken things.

nobody proposed doing it in jabber:client

which I'm sure will cause fun effects :D

That's exactly what the sample Guus pasted was doing.

no

Nobody was proposing it was a good idea, naturally.

in <message xmlns="jabber:client" foo="bar"/>, @foo is *not* in the jabber:client namespace.

Ok, default namespace, yes.

no

without namespace.

Let's just pretend it's in jabber:client plz

<message xmlns="jabber:client" xmlns:jc="jabber:client" jc:foo="bar"/> is in jabber:client then.

and it is semantically different from the former

That's what all code I have ever known does

so please let's not pretend that

I know what I mean, even if I'm not using the right terms for it.

Dino’s internal representation does the wrong thing here. :<

This is a silly part of XML

I do know that attributes without a namespace live outside, although I always miscall 'no namespace' 'the default namespace'.

> in <message xmlns="jabber:client" foo="bar"/>, @foo is *not* in the jabber:client namespace. so every websocket implementation ever is broken ?

No, I don't believe so.

moparisthebest, why?

moparisthebest, the attributes on stanzas in XMPP are supposed to be in no namespace

The attributes in XMPP are in the null-namespace, whatever the right term is.

oh, ok then

But they ... belong with the whatever namespace xmlns specifies, somehow

this hurts my brain and I do not like it

Yes. Let's pretend this obscure corner of XML doesn't exist!

Everyone pretends they live in the jabber:client/jabber:server namespaces because that's what XML would do if it wasn't insane.

But they're not.

We're really using XmppML anyways 😉

Really all the attributes in XMPP should have been namespaced, but that would have been hideous.

I'm all for going back to pretending it worked the way I always thought it worked

moparisthebest, what do you do on `<message xmlns="jabber:client" xmlns:jc="jabber:client" jc:foo="bar" foo="baz"/>` then? ✏

honestly I have no idea

reject whatever made it as bad software? :)

:(

redirect whoever made the software to an insane asylum perhaps?

up until 2 minutes ago I would have said that's a duplicate attribute, both under jabber:client

Sometimes being wrong is the better option :)

so to be clear, any attribute that doesn't have an explicit `namespace:` in front is *not* in a namespace at all ?

apparently

ever, regardless of higher level namespaces ?

so like `(null):attr=""`

I'm not about to read the XML specification.

:mind-blown:

I believe that to be correct, yes, although it's a while since I checked in the spec and I might misremember.

It's a bit like Dialback. You understand it, you go to sleep, and you instantly forget how bad it really is, to protect yourself.

maybe there is a good reason why non-qualified attribute names are in a namespace without value?

what's again the difference between xep432 and xep335?

ahh ep432 builds upon xep335

moparisthebest, https://www.w3.org/TR/REC-xml-names/#defaulting

> Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear.

> The namespace name for an unprefixed attribute name always has no value.

(namespace name == namespace URI in more common lingo)

The second example in https://www.w3.org/TR/REC-xml-names/#uniqAttrs is the "adversarial" example we talked about earlier, with xmlns="x" xmlns:prefix="x" and attributes with and without prefix on the same element being legal ✏

hi! I would like to attribute autor(s) of the XMPP logo: https://commons.wikimedia.org/wiki/File:XMPP_logo.svg Who should I attribute this to? "XMPP Standards Foundation", "Raja SANDHU" (as the original author), all of the authors who modified the logo, or all of the above?

wurstsalat: I think Raja Sandhu first, and XSF second. I don't think that the cosmetic fix was actually "authored", but instead working around an SVG rendering artifact.

> Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear. wait, what? later it says: > the default namespace does not apply to attribute names the first seems to say that default namespace declarations apply to attribute names *sometimes* ?

ralphm, thank you!

moparisthebest, no, it means that it applies to the element, which incidentally defines which attributes are accepted and how to interpret them.

unnamespaced attributes inherently belong to the element, and how to interpret them is at the elements discretion

Link Mauve, still not understanding, if an attribute doesn't have a prefix, does it ever have a namespace ?

moparisthebest, no.

moparisthebest, never.

otherwise, the second example from that uniqAttrs anchor would not universally be valid

In <a xmlns='http://www.w3.org/1999/xhtml' href='/'/> and in <a xmlns='http://www.w3.org/2000/svg' href='/'/>, both @href are in the null namespace but both are defined by their parent element(’s namespace).

(The latter is an addition in SVG2, it would usually be in the http://www.w3.org/1999/xlink namespace.)

so a namespace for an element decides which non-namespaced attributes it can have on it ?

s/non-namespaced/null-namespaced/

Of course, since it defines the element.

indirectly, the element decides which non-namespaced attributes it can have on it ✏

I think I understand this now, thanks

I don't understand in what universe this makes sense though, so if anyone wants to help with that...

moparisthebest, it allows different namespaces to define their elements (and the allowed attributes on them) without fear of incompatibility with another unknown namespace defining the same elements and attributes but with a different meaning.

Link Mauve, but that would still work if attributes worked the same way as elements

however, it allows namespaces to define attributes which have a meaning independently from the element they appear on

Right.

if the namespace of an attribute was defaulted to the one of the element, all attributes which are used on *any* element in that namespace can not be used generically (in the way xlink:href or xml:lang is used generically)

though I think that this particular trade-off is not worth the headaches it causes

as namespace URIs are cheap

We have no way to go back in time and change XML 1.0 + Namespaces anyway.

No known* way.

unfortunately this feels like proof that time travel is impossible

surely if it was, someone would have fixed this first

> if the namespace of an attribute was defaulted to the one of the element, all attributes which are used on *any* element in that namespace can not be used generically (in the way xlink:href or xml:lang is used generically) Ironically, I have never seen the latter without that prefix.

Guus, XML 1.0 + Namespaces forbids redefining the namespace of the xmlns or xml prefixes.

Link Mauve: but if I read the above correctly then any element can define the usage of that attribute without explicitly requiring the namespace prefix?

Guus, “that attribute”, the @xml:lang?

It already has a prefix, which is xml, and is illegal to redefine or to define anything to the same namespace.

Link Mauve: I misinterpreted jonas’ earlier comment.

> jonas’> if the namespace of an attribute was defaulted to the one of the element, all attributes which are used on *any* element in that namespace can not be used generically why shouldn't I be able to use the attribute with a prefix in an element not beloging to the namespace the attribute was defined in?

flow, conceptually, an attribute only refines its element.

It wouldn’t make any sense to use e.g. the XHTML video/@loop on an XMPP message/body.

It would make sense to include an XHTML video element in an XMPP message though.

As it is a standalone element.

Note also that even in a single namespace, multiple different elements might define an identically-named attribute.

Possibly with different semantics.

I feel more enlightened and a little bit deader inside at the same time. Thanks everyone for the questions and the answers!

:D

same mjk

After 2 years of intense research, Twitter proposes inventing XMPP: https://blueskyweb.xyz/blog/3-6-2022-a-self-authenticating-social-protocol

at last! The fourth xmpp!

(counting activitypub towards that)

> With email, if you change your provider then your email address has to change too. flat-out lying is fine guys, they are twitter

That seems like a reasonable thing to say given their audience, they obviously just mean "they will have addresses not tied to a domain so you don't have to use your own domain if you want to move your account"

"their audience" the subset of people that will read an article about a protocol but not understand basic email concepts? :/

It's a high level overview, not a deep dive into technical details. It seems like a reasonable thing to elide over.

then don't mention it, rather than lie

It's not a lie, generally speaking what they're saying is true. They obviously just mean "it has a domain name in it", what they're suggesting is that you don't have to lug a domain name around, I think. eg. if you sign up on @twitter.com and get address "myname" then move to "example.com" your address will still just be "Myname" but a new server will be handling the data.

> We want users to have an easy path to switching servers, even without the server’s help. That's, like, rocket science! Right, Matt? ;)

And then just burn massive amounts of coal to power the blockchain to record what server every username is currently living on?

Easy! Why didn't we think of this????

If only there was a global infrastructure for paying to reserve a name...

what if we invented some type of name service people could use to register names of their choosing?

and like some type of hierarchical protocol to look them up? it would be revolutionary!

humans often organize themselves in hierarchies, perhaps something modeled after that?

It could also have hierarchical authentication of records built in from the start! ✏

now that would be something...

Topic change: As I posted a while ago to the list, xmpp.net is a home to some a handful of "not officially XSF" projects, most notably the IM Observatory (and probably its successor)

One of the projects has requested a MUC, which could live on muc.xmpp.org but might be confusing as a "not officially XSF" thing

So one alternative option is to add a vhost for muc.xmpp.net or similar to this server

From an iteam perspective I'm fine with that, and from a board perspective I'm fine with that. Does anyone have a perspective from this would not be fine? If not, I'll go ahead and set it up soon.

or just stop playing that game and call it an official XSF thing

not official, only ran 100% by the same people running the XSF

moparisthebest: that will end up in lots of "discussion" I assume?

Making things official XSF things is not always a good thing for such projects, or the XSF

I tend to agree with Matt

This is my opinion, I know we have had discussions in the past where people disagreed with it

i.e. some people are of the opinion that the XSF should aim to be and do everything XMPP, while I prefer to keep it mostly just a vehicle for publishing standards

just seems silly to me to continue "it's not official ;D" vs "ok XSF runs it"

Partly because it has proven time and time again to be pretty bad at doing anything else, but mostly okay at the standards thing :)

^^

MattJ - nothing against the Newsletter - OKKK?!?!! 😉

So it's a "trade mark" issue: "yea, we run it, but don't expect it to be as great as the main thing XSF is known for"? :)

emus, no, the newsletter has been a rare exception... but that's mostly thanks to your dedication :)

just kidding 🙂

I was about to say the opposite: the XSF is really bad at the newsletter, it's an XSF project that got dumped on the shoulders (voluntarily, of course) of a single individual who gets almost no support from anyone else :) (I say counting myself as complicit in that)

The newsletter itself is great, the XSF involvement not so much :)

Well, no its not on me of course, I always try to list and make transparent who supported and its alright like that ✏

thanks Link Mauve, but I think I new all that already and I am not sure how this answers my question. let's say I have <foo:elem xmlns:foo="foo.org" foo:favorite-lang="fr"/> and assume attribute namespaces are the ones of the element unless specified otherwise, then this could be written as <elem xmlns="foo.org" favorite-lang="fr">. Why shouldn't I then be able to use favorite-lang on a different element, in a different namespace even ✏