> 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.
yushyinhas left
Samhas left
adiaholichas left
adiaholichas joined
wladmishas left
BASSGODhas joined
Samhas joined
mjkhas joined
Steve Killehas left
gooyahas left
gooyahas joined
stphas joined
Samhas left
florettahas joined
restive_monkhas left
վարյաhas left
վարյաhas joined
konstantinoshas joined
lovetoxhas joined
adiaholichas left
BASSGODhas left
yushyinhas joined
adiaholichas joined
millesimushas left
restive_monkhas joined
millesimushas joined
neshtaxmpphas left
marchas joined
վարյաhas left
Andrzejhas left
վարյաhas joined
florettahas left
BASSGODhas joined
florettahas joined
pasdesushihas left
pasdesushihas joined
marc0shas left
marc0shas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
ti_gj06has left
Paganinihas joined
վարյաhas left
վարյաhas joined
pasdesushihas left
lskdjfhas joined
Samhas joined
yushyinhas left
pasdesushihas joined
restive_monkhas left
restive_monkhas joined
Samhas left
Steve Killehas joined
Samhas joined
Samhas left
gooyahas left
pasdesushihas left
gooyahas joined
lovetoxhas left
Menelhas left
yushyinhas joined
stphas left
qyhas left
Samhas joined
stphas joined
lovetoxhas joined
Samhas left
Samhas joined
adiaholichas left
adiaholichas joined
Samhas left
adiaholichas left
adiaholichas joined
mjkhas left
Neustradamushas left
ti_gj06has joined
mjkhas joined
Menelhas joined
Samhas joined
adiaholichas left
adiaholichas joined
Samhas left
Wojtekhas left
Samhas joined
Andrzejhas joined
adiaholichas left
adiaholichas joined
mjkhas left
debaclehas joined
mjkhas joined
qyhas joined
ti_gj06has left
ti_gj06has joined
ti_gj06has left
ti_gj06has joined
վարյաhas left
վարյաhas joined
Samhas left
ti_gj06has left
Samhas joined
ti_gj06has joined
atomicwatchhas left
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
mhhas left
mhhas joined
Samhas left
xnamedhas joined
pasdesushihas joined
Samhas joined
عبودhas joined
ti_gj06has left
ti_gj06has joined
Maranda[x]has left
Maranda[x]has joined
Samhas left
adiaholichas left
gooyahas left
gooyahas joined
adiaholichas joined
Samhas joined
harry837374884has left
pasdesushihas left
antranigvhas joined
beanhas joined
pasdesushihas joined
adiaholichas left
yushyinhas left
adiaholichas joined
emushas left
emushas joined
atomicwatchhas joined
adiaholichas left
Guus
does the specs allow for (non-namespaced) attributes to be added to message/iq/presence stanza elements?
Andrzejhas left
konstantinoshas left
Guus
`<message foo='bar' ... `
Zash
Yes officer, this message right here ↑
adiaholichas joined
Zash
Guus, have fun with the protocol police 😉
Link Mauve
Woop woop~
yushyinhas joined
gooyahas left
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
jonas’
Guus, most certainly not
gooyahas joined
restive_monkhas left
pasdesushihas left
mjk
Meanwhile, in Matrix:
-- This is not the protocol violation you're looking for *waves hand, making the protocol support it*
-- Woah...
jonas’
use namespaced attributes, they're there for that use case
Zash
or stuff it in a namespaced element
jonas’
or that, but you can't do that for IQs
Kev
Please don't shove new stuff in a stanza header, I would expect most of the world to break in that case.
Zash
I expect half the world to pass it along to the other half, where it'll break.
jonas’
one half being prosody, the other half being ejabberd?
lovetoxhas left
Guus
I'm asking because I was amazed that I'm looking at client traffic that does it, without it breaking in dramatic ways.
Guus
are _namespaced_ attributes on those elements even ok?
Kev
Not really.
Zash
Slightly less not okay at least.
Kev
We're bad at documenting our extension points, though.
Zash
It's XML! Everywhere's an extension point if you namespace it!!
Guus
You'd need to somehow add the namespace to the ... stream element? Feels pretty messy.
restive_monkhas joined
lovetoxhas joined
Guus
So, yeah, shove it in a child element somewhere.
Guus
to make you share in my misery, I'm looking at an attribute on a message stanza that starts with this:
Zash
no no noooooooo
Guus
`sensorList="{"data":[{"type":"sensorOne",`
followed by slightly over 2000 characters
Guus
and that's just one of those attributes. :D
Kev
JSON inside a default-namespaced attribute on a message stanza. I don't see what could possibly go wrong.
Guuswalks out of the bar, whistling.
Zashfills eyes with kerosene
Kev
Really, what's the odd Eldrich Horror between friends?✎
Marandahuhus.
Kev
Really, what's the odd Eldritch Horror between friends? ✏
Guus
but as I said: this doesn't break, apparently.
Kev
I think you've just not found the myriad places it breaks, yet :)
jonas’
Guus, no you don't, you can <message xmlns:foo='bar' foo:fnord='xyz'/>✎
jonas’
Guus, no you don't have to declare it on the stream header, you can <message xmlns:foo='bar' foo:fnord='xyz'/> ✏
Apollohas joined
Guus
jonas’ ah yes. Still not a good idea probably.
Guus
Kev: let me put it this way: it's running in production, but they're now reaching out because of some issues.
lovetoxhas left
Kev
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.
Zash
Guus, show them https://xmpp.org/extensions/xep-0432.html
Guus
(also: hardcoded stanza IDs)
Guus
Zash: but it has a big red warning on top of it! must be worse than rolling our own!
lovetoxhas joined
wladmishas joined
Guus
(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?)
Zash
Guus: Or push for advancement?
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
jonas’
this sounds like a low-hanging push-for-advancement fruit indeed
Guus
Zash we can do that for individual XEPs - I was trying to go for a more generic approach.
Ingolfhas left
Zash
I think I even added that to mod_rest
adiaholichas left
lovetoxhas left
Ingolfhas joined
վարյաhas left
վարյաhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
عبودhas left
yushyinhas left
lovetoxhas joined
pasdesushihas joined
xnamedhas left
antranigvhas left
antranigvhas joined
florettahas left
florettahas joined
yushyinhas joined
adiaholichas joined
antranigvhas left
lovetoxhas left
adiaholichas left
adiaholichas joined
yushyinhas left
antranigvhas joined
harry837374884has joined
Guus
RFC6121 8.4 explicitly states that 'extension attributes' _are_ allowed, I think. See https://datatracker.ietf.org/doc/html/rfc6120#section-8.4
moparisthebesthas joined
Zash
Is now the time to remember how the `@c` attribute in `<a xmlns="b" c="d"/>` isn't in the "b" namespace?
Guus
XML prefixes
Guus
as jonas showed earlier.
Zash
Like `xmlns:extension="blah" extension:attr="moo"`, yeah that's fine.
arcxihas left
Guus
`xmlns:prefix="uri" prefix:c="yey"`
Guus
yeah, exactly.
antranigvhas left
Kev
Guus: Yes, it does. I predict it would still break things.
MattJ
It will break broken things
adiaholichas left
adiaholichas joined
Kev
Sure. Whereas doing it inside jabber:client will break unbroken things.
jonas’
nobody proposed doing it in jabber:client
jonas’
which I'm sure will cause fun effects :D
Kev
That's exactly what the sample Guus pasted was doing.
jonas’
no
Wojtekhas joined
sbachhas left
sbachhas joined
Kev
Nobody was proposing it was a good idea, naturally.
jonas’
in <message xmlns="jabber:client" foo="bar"/>, @foo is *not* in the jabber:client namespace.
Kev
Ok, default namespace, yes.
jonas’
no
jonas’
without namespace.
Zash
Let's just pretend it's in jabber:client plz
jonas’
<message xmlns="jabber:client" xmlns:jc="jabber:client" jc:foo="bar"/> is in jabber:client then.
jonas’
and it is semantically different from the former
Zash
That's what all code I have ever known does
jonas’
so please let's not pretend that
Kev
I know what I mean, even if I'm not using the right terms for it.
Link Mauve
Dino’s internal representation does the wrong thing here. :<
Zash
This is a silly part of XML
Kev
I do know that attributes without a namespace live outside, although I always miscall 'no namespace' 'the default namespace'.
wgreenhousehas left
wgreenhousehas joined
moparisthebest
> in <message xmlns="jabber:client" foo="bar"/>, @foo is *not* in the jabber:client namespace.
so every websocket implementation ever is broken ?
Kev
No, I don't believe so.
jonas’
moparisthebest, why?
jonas’
moparisthebest, the attributes on stanzas in XMPP are supposed to be in no namespace
Kev
The attributes in XMPP are in the null-namespace, whatever the right term is.
moparisthebest
oh, ok then
Zash
But they ... belong with the whatever namespace xmlns specifies, somehow
moparisthebest
this hurts my brain and I do not like it
adiaholichas left
yushyinhas joined
Zash
Yes. Let's pretend this obscure corner of XML doesn't exist!
վարյաhas left
Kev
Everyone pretends they live in the jabber:client/jabber:server namespaces because that's what XML would do if it wasn't insane.
Kev
But they're not.
qyhas left
Zash
We're really using XmppML anyways 😉
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
qyhas joined
Kev
Really all the attributes in XMPP should have been namespaced, but that would have been hideous.
moparisthebest
I'm all for going back to pretending it worked the way I always thought it worked
MattJvotes for that plan
jonas’
moparisthebest, what do you do on `<message xmlns="jabber:client" xmlns:jc="jabber:client" jc:foo="bar"/>` then?✎
jonas’
moparisthebest, what do you do on `<message xmlns="jabber:client" xmlns:jc="jabber:client" jc:foo="bar" foo="baz"/>` then? ✏
moparisthebest
honestly I have no idea
moparisthebest
reject whatever made it as bad software? :)
jonas’
:(
Zash
redirect whoever made the software to an insane asylum perhaps?
moparisthebest
up until 2 minutes ago I would have said that's a duplicate attribute, both under jabber:client
վարյաhas joined
wgreenhousehas left
wladmishas left
yushyinhas left
antranigvhas joined
wladmishas joined
restive_monkhas left
wgreenhousehas joined
antranigvhas left
restive_monkhas joined
Kev
Sometimes being wrong is the better option :)
antranigvhas joined
yushyinhas joined
moparisthebest
so to be clear, any attribute that doesn't have an explicit `namespace:` in front is *not* in a namespace at all ?
Zash
apparently
moparisthebest
ever, regardless of higher level namespaces ?
Zash
so like `(null):attr=""`
Zash
I'm not about to read the XML specification.
moparisthebest
:mind-blown:
wgreenhousehas left
վարյաhas left
kinetikhas joined
Wojtekhas left
Kev
I believe that to be correct, yes, although it's a while since I checked in the spec and I might misremember.
Kev
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.
xnamedhas joined
florettahas left
florettahas joined
wgreenhousehas joined
վարյաhas joined
antranigvhas left
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
antranigvhas joined
wgreenhousehas left
wgreenhousehas joined
brunrobehas left
Marandahas left
Mjolnir Archonhas left
Mjolnir Archonhas joined
Marandahas joined
brunrobehas joined
վարյաhas left
վարյաhas joined
arcxihas joined
flow
maybe there is a good reason why non-qualified attribute names are in a namespace without value?
վարյաhas left
վարյաhas joined
flow
what's again the difference between xep432 and xep335?
> Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear.
jonas’
> The namespace name for an unprefixed attribute name always has no value.
jonas’
(namespace name == namespace URI in more common lingo)
jonas’
The second example in https://www.w3.org/TR/REC-xml-names/#uniqAttrs here 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✎
jonas’
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 ✏
antranigvhas joined
antranigvhas left
Apollohas joined
adiaholichas left
millesimushas left
millesimushas joined
debaclehas joined
adiaholichas joined
Steve Killehas left
lovetoxhas joined
nicolahas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
harry837374884has joined
kinetikhas left
kinetikhas joined
nicolahas left
atomicwatchhas joined
wurstsalat
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?
adiaholichas left
ralphm
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.
yushyinhas left
adiaholichas joined
moparisthebest
> 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* ?
wurstsalat
ralphm, thank you!
Link Mauve
moparisthebest, no, it means that it applies to the element, which incidentally defines which attributes are accepted and how to interpret them.
jonas’
unnamespaced attributes inherently belong to the element, and how to interpret them is at the elements discretion
moparisthebest
Link Mauve, still not understanding, if an attribute doesn't have a prefix, does it ever have a namespace ?
jonas’
moparisthebest, no.
Link Mauve
moparisthebest, never.
jonas’
otherwise, the second example from that uniqAttrs anchor would not universally be valid
Link Mauve
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).
Link Mauve
(The latter is an addition in SVG2, it would usually be in the http://www.w3.org/1999/xlink namespace.)
adiaholichas left
moparisthebest
so a namespace for an element decides which non-namespaced attributes it can have on it ?
moparisthebest
s/non-namespaced/null-namespaced/
Link Mauve
Of course, since it defines the element.
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
jonas’
no, the element decides which non-namespaced attributes it can have on it✎
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
jonas’
indirectly, the element decides which non-namespaced attributes it can have on it ✏
moparisthebest
I think I understand this now, thanks
moparisthebest
I don't understand in what universe this makes sense though, so if anyone wants to help with that...
adiaholichas joined
Link Mauve
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.
jonas’
Link Mauve, but that would still work if attributes worked the same way as elements
jonas’
however, it allows namespaces to define attributes which have a meaning independently from the element they appear on
Link Mauve
Right.
yushyinhas joined
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 (in the way xlink:href or xml:lang is used generically)
jonas’
though I think that this particular trade-off is not worth the headaches it causes
jonas’
as namespace URIs are cheap
kinetikhas left
Link Mauve
We have no way to go back in time and change XML 1.0 + Namespaces anyway.
Link Mauve
No known* way.
moparisthebest
unfortunately this feels like proof that time travel is impossible
moparisthebest
surely if it was, someone would have fixed this first
Guus
> 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.
Titihas left
Link Mauve
Guus, XML 1.0 + Namespaces forbids redefining the namespace of the xmlns or xml prefixes.
kinetikhas joined
adiaholichas left
adiaholichas joined
djorzhas joined
lovetoxhas left
Guus
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?
Andrzejhas left
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
Link Mauve
Guus, “that attribute”, the @xml:lang?
adiaholichas left
Link Mauve
It already has a prefix, which is xml, and is illegal to redefine or to define anything to the same namespace.
antranigvhas joined
BASSGODhas joined
Guus
Link Mauve: I misinterpreted jonas’ earlier comment.
BASSGODhas left
adiaholichas joined
inkyhas left
rafasaurushas left
rafasaurushas joined
adiaholichas left
flow
> 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?
ti_gj06has left
antranigvhas left
Link Mauve
flow, conceptually, an attribute only refines its element.
Link Mauve
It wouldn’t make any sense to use e.g. the XHTML video/@loop on an XMPP message/body.
ti_gj06has joined
Link Mauve
It would make sense to include an XHTML video element in an XMPP message though.
Link Mauve
As it is a standalone element.
BASSGODhas joined
Link Mauve
Note also that even in a single namespace, multiple different elements might define an identically-named attribute.
Link Mauve
Possibly with different semantics.
pasdesushihas left
lovetoxhas joined
antranigvhas joined
adiaholichas joined
kinetikhas left
pasdesushihas joined
Danielhas left
ti_gj06has left
ti_gj06has joined
jgarthas joined
harry837374884has left
atomicwatchhas left
restive_monkhas left
harry837374884has joined
Danielhas joined
mjk
I feel more enlightened and a little bit deader inside at the same time. Thanks everyone for the questions and the answers!
Link Mauve
:D
adiaholichas left
moparisthebest
same mjk
tykaynhas joined
Andrzejhas left
adiaholichas joined
Andrzejhas joined
lovetoxhas left
BASSGODhas left
adiaholichas left
BASSGODhas joined
inkyhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
moparisthebest
After 2 years of intense research, Twitter proposes inventing XMPP: https://blueskyweb.xyz/blog/3-6-2022-a-self-authenticating-social-protocol
gooyahas left
jgarthas left
gooyahas joined
atomicwatchhas joined
adiaholichas joined
Andrzejhas left
TheCoffeMakerhas left
adiaholichas left
TheCoffeMakerhas joined
lovetoxhas joined
mjk
at last! The fourth xmpp!
mjk
(counting activitypub towards that)
moparisthebest
> With email, if you change your provider then your email address has to change too.
flat-out lying is fine guys, they are twitter
Sam
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"
moparisthebest
"their audience" the subset of people that will read an article about a protocol but not understand basic email concepts? :/
Guushas left
Sam
It's a high level overview, not a deep dive into technical details. It seems like a reasonable thing to elide over.
Guushas joined
moparisthebest
then don't mention it, rather than lie
Sam
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.
mjk
> We want users to have an easy path to switching servers, even without the server’s help.
That's, like, rocket science! Right, Matt? ;)
Zash
And then just burn massive amounts of coal to power the blockchain to record what server every username is currently living on?
Zash
Easy! Why didn't we think of this????
kinetikhas joined
papatutuwawahas joined
Fishbowlerhas left
mjk
If only there was a global infrastructure for paying to reserve a name...
Fishbowlerhas joined
pasdesushihas left
moparisthebest
what if we invented some type of name service people could use to register names of their choosing?
moparisthebest
and like some type of hierarchical protocol to look them up? it would be revolutionary!
Zash
humans often organize themselves in hierarchies, perhaps something modeled after that?
Andrzejhas joined
kinetikhas left
TheCoffeMakerhas left
mjk
It could also have authentication of records built in from the start!✎
mjk
It could also have hierarchical authentication of records built in from the start! ✏
moparisthebest
now that would be something...
Titihas joined
TheCoffeMakerhas joined
Andrzejhas left
Andrzejhas joined
pasdesushihas joined
kinetikhas joined
lovetoxhas left
Titihas left
Andrzejhas left
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
TheCoffeMakerhas left
adiaholichas joined
TheCoffeMakerhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
Titihas joined
Wojtekhas left
wladmishas left
wladmishas joined
marc0shas left
marc0shas joined
lovetoxhas joined
Andrzejhas left
kinetikhas left
marc0shas left
marc0shas joined
karoshihas left
inkyhas left
inkyhas joined
gooyahas left
gooyahas joined
antranigvhas left
inkyhas left
inkyhas joined
adiaholichas left
adiaholichas joined
TheCoffeMakerhas left
TheCoffeMakerhas joined
antranigvhas joined
Dele Olajidehas joined
Dele Olajidehas left
adiaholichas left
antranigvhas left
florettahas left
florettahas joined
inkyhas left
restive_monkhas joined
karoshihas joined
inkyhas joined
antranigvhas joined
Andrzejhas joined
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
mhhas left
restive_monkhas left
harry837374884has left
harry837374884has joined
restive_monkhas joined
Andrzejhas left
Andrzejhas joined
Samhas left
marchas left
sbachhas left
adiaholichas joined
sbachhas joined
TheCoffeMakerhas left
Andrzejhas left
Andrzejhas joined
TheCoffeMakerhas joined
raucaohas left
mhhas joined
inkyhas left
inkyhas joined
eevvoorhas left
eevvoorhas joined
Andrzejhas left
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
adiaholichas left
Andrzejhas left
Andrzejhas joined
restive_monkhas left
Samhas joined
marchas joined
gooyahas left
gooyahas joined
adiaholichas joined
Andrzejhas left
beanhas left
BASSGODhas left
inkyhas left
beanhas joined
BASSGODhas joined
inkyhas joined
V_torhas joined
Apollohas left
TheCoffeMakerhas left
TheCoffeMakerhas joined
inkyhas left
adiaholichas left
beanhas left
BASSGODhas left
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
atomicwatchhas left
beanhas joined
BASSGODhas joined
inkyhas joined
atomicwatchhas joined
restive_monkhas joined
inkyhas left
antranigvhas left
restive_monkhas left
beanhas left
BASSGODhas left
MattJ
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)
MattJ
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
beanhas joined
MattJ
So one alternative option is to add a vhost for muc.xmpp.net or similar to this server
MattJ
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.
konstantinoshas left
moparisthebest
or just stop playing that game and call it an official XSF thing
moparisthebest
not official, only ran 100% by the same people running the XSF
beanhas left
BASSGODhas joined
beanhas joined
emus
moparisthebest: that will end up in lots of "discussion" I assume?
MattJ
Making things official XSF things is not always a good thing for such projects, or the XSF
emus
I tend to agree with Matt
MattJ
This is my opinion, I know we have had discussions in the past where people disagreed with it
MattJ
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
BASSGODhas left
moparisthebest
just seems silly to me to continue "it's not official ;D" vs "ok XSF runs it"
BASSGODhas joined
inkyhas joined
Yagizahas left
MattJ
Partly because it has proven time and time again to be pretty bad at doing anything else, but mostly okay at the standards thing :)
emus
^^
inkyhas left
emus
MattJ - nothing against the Newsletter - OKKK?!?!! 😉
inkyhas joined
mjk
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"? :)
MattJ
emus, no, the newsletter has been a rare exception... but that's mostly thanks to your dedication :)
emus
just kidding 🙂
stphas left
inkyhas left
Sam
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)
inkyhas joined
Sam
The newsletter itself is great, the XSF involvement not so much :)
inkyhas left
beanhas left
BASSGODhas left
inkyhas joined
beanhas joined
BASSGODhas joined
inkyhas left
inkyhas joined
emus
Well, no its not on me of course, I always try to list and make transparent who supported and it alright like that✎
phoeboshas joined
phoeboshas left
emus
Well, no its not on me of course, I always try to list and make transparent who supported and its alright like that ✏
antranigvhas joined
edhelashas left
edhelashas joined
harry837374884has left
Alexhas left
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
msavoritiashas left
adiaholichas joined
gooyahas left
gooyahas joined
antranigvhas left
flow
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 we 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✎
adiaholichas left
flow
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 ✏