XSF Discussion - 2023-03-29

The website at xmpp.org is unresponsive to me.

wfm

won't work on on phone or desktop

can you provide the output of `mtr -4 --report xmpp.org` and `mtr -6 --report xmpp.org`?

oh, does work if I do not use my ISP but a mobile network

then I blame your ISP

ack

I cannot resolve xmpp.org at all, it seems.

ISP(s) and DNS are the MIM

One DNS NS is currently borked, but the other one was fine last I looked

.. and how recursors handle that differs

... do we have statistics of our website? Do we see a notable drop in traffic?

We don't

I expect we would see a drop though, yes

IPv6 is broken, for example

The DNS and mail server is entirely unreachable

count web server log lines per day?

That might have gone up with lots of errors. :)

Probably only noticable for silly people like me, running their own resolvers

well, my ISP isn't liking this either.

given 2 weeks of logs, I don't see any drop

It certainly *shouldn't* be an issue. And if it is, it at least shouldn't be permanent. Handling this kind of failure is supposed to be one of the primary features of DNS :)

The IPv6 issue on top of things probably isn't helping though

shouldn't be != isn't

ralphm / intosi : I think we share the same ISP (Freedom). Are DNS lookups for xmpp.org working for you?

Not fair for me, because one of the name servers is in my garage

But ns1.xmpp.org is unresponsive

And I think that host is in our own infra, as the IP address is in the XSF range

Yes, there have been a number of infra issues this week, I don't know if this one is related or something new. I've emailed Jerry and folk (since the mailing lists probably aren't working)

@Guus: I don't use their resolvers, so wouldn't know.

A quick test seems to suggest it's resolving them, but a query that triggers a fetch takes a moment, probably because it tries ns1.xmpp.org first.

Will it break anything if I take ns1 off the domain? The secondaries will still be happy to sync from it when it comes back?

It shouldn't break anything.

The secondaries will sync once the master becomes back.

* comes.

Can always set up a free secondary like https://freedns.afraid.org/secondary/ or https://dns.he.net/

ns1 removed

Is .org one of the ones that requires 2 name servers? Some tlds do

We have several

xmpp.org is back for me.

Great

Has anyone ever dealt with a scenario where entities are subscribing to a pubsub node that is expected to exist in the future, but isn't yet?

Options: 1) auto-create the node with some defaults (that's an optional feature defined in XEP-0060), 2) reject the subscription request (node doesn't exist, after all), 3) some weird thing where you pretend the subscription succeeded, as if the node exists

(3) sounds like what you're thinking, but it really doesn't seem sensible to me

No technical reason it can't be done though, like a kind of waiting list thing

I didn't know about the auto-create option

At the point where you're storing a list of "future" subscribers, and telling them that their subscription worked, you might as well just create the node

I was thinking about the same thing. I'm not sure if there are requirements around ownership etc

I'll see where I get with auto-create. Not even sure if Openfire supports it.

Thanks

There is a technical reason for not allowing subscriptions to nodes that do not exist: A persistant subscription needs to be persisted. Typically, such subscriptions are removed, if the node is removed; that is the means to clense the database. If there’s no node, no such mechanism to cleanse the database would exist. There would also not exist rules for how/when/how many such subscriptions would be allowed, and by whom. You would therefore create a machanism to completely fill the database with nuisance subscriptions to nodes that do not exist, efficiently taking the server down. If subscriptions are not persistant, they would have to be kept in internal memory, and the same applies there: You would create a mechanism to deplete the internal memory of the server.

> At the point where you're storing a list of "future" subscribers, and telling them that their subscription worked, you might as well just create the node I see the logic here, but allowing random people to cause a node to be created feels Really Bad ✏ ↺

That's why it's optional, and the other specified approach is to simply return an error

Basically, allowing random people to create random nodes creates the same vulnerability: Ability for malicious actors to create nuicanse nodes, and take the server down.

auto-create is a feature that's used for PEP, for instance. Doesn't mean there can't be ACLs involved.

Does autocreate mean the creator is the owner?

Not all XMPP server instances operate in an open-federation chat model.

^ What Guus said.

Oh, I may have misremembered. Auto-create in XEP-0060 only talks about auto-create on *publish*, not subscribe

Prosody, however, supports both

M-Link only supports that on publish.

pep., in Prosody's implementation subscribers triggering node creation does not make them owner, no. The node doesn't have an explicit owner, in that case. Typically owners/admins of the service have access to it.

Didn't we change how that works?

Did we?

We store recipients outside of the pubsub service, which gets used on publish, at least for the +notify type of implicit subscription

Ah, for PEP, yeah

Oh, were we only talking about generic pubsub?

I don't know. I was :)

I was too. Is it true that MQTT-like implemenations of pub/sub do not take into account the existence of a topic? Maybe driven by having no persistency, making a 'subscription to a topic' almost like a filtering operation?

this is true

you don’t create topics in MQTT

subscription is a filtering operation

(subscriptions can include wildcards)

You can use random topics, fwiw ✏

example: You can publish sensor data to topics of the type Sensor/ID/FIELD/VALUE, and then a client can subscribe to Sensor/+/Temperature/+ to get all temperature sensor values. ID can be any random value

Value could be floating point values for instance

(in this example)

(Perhaps the Value-part of the topic in this examples, make little sense, but nothing prohibits it, unless you publish a lot of meta-data there for different values)

Ok, thanks.

That's helpful. Does anyone know why such a mode of operations does not seem to be built into the XMPP spec for pub/sub? Does that have to do with leaning more on persistent data, in XMPP-world?

I’ve tried to lift in such issues, many years ago however. Interest in other than IM-based-technologies was limited…

(in these groups, I have to add; many other groups exist that use these technologies. They just don’t discuss them here. Pointer for those who wonder why companies keep quiet about using XMPP.)

Why do they?

> Does anyone know why such a mode of operations does not seem to be built into the XMPP spec for pub/sub? I don't see anything in the spec that prevents this mode of operation, should an implementation desire to support it

auto-create on publish makes node awareness optional, PEP uses the subscription filter model heavily

In May of 2014 (soon 9 years ago) I made a study of the differences (strengths/weaknesses) between XMPP and MQTT, and tried to create interest to improve XMPP with extensions of things lacking in XMPP, but that existed in MQTT. (This includes Quality of Service and queue-ing, for instance, but also other adjacent areas. Let me know if anyone is interested in reading results.) Interest was low from the XSF group, which focused(-s) mainly on IM, rather than viewing XMPP as a more generic transport protocol for multiple use cases (other than IM). (Interest is/was higher in other groups, who wish to stay more agnostic to overlying use cases).

The XSF is an open group. If the XSF is focused mainly on IM, it's because more IoT folk did not join it.

"the XSF" isn't a group with a focus at all

Individual members of the XSF have different focuses of course, but anyone can join with their own

That's what I've always found sad about the XSF :(

Hard disagree, that's what's great about the XSF, a major strength

You disagree that I find this sad?

well obviously it has a focus as it is obvious here

Hehe, well I disagree that it's a sad thing

from people being uniterested in the study i mean

and because most of the xeps are focused on messaging

*members individually* have interest and focus, not the XSF

we can pretend its not but that doesnt help the conversation

And still, MQTT (mqtt.org), representing an inferior protocol (in how it is being used in reality) has had much more success in promoting its ideas and technology, compared to the XSF (xmpp.org)… To understand why, first you need to be interested in figuring out why, and analyze the problem openly, and self-critically, without coming to premature conclusions… Self-criticism is not the forte of this group unfortunately, and therefore improvement in this field is difficult/impossible.

I pretty much despise iot things, why would I have an interest in improving them? Other people might be interested in iot and not interested in personal chat, we can all be XSF members and work on different things and share work on the overlap

> And still, MQTT (mqtt.org), representing an inferior protocol (in how it is being used in reality) has had much more success in promoting its ideas and technology, compared to the XSF (xmpp.org)… To understand why, first you need to be interested in figuring out why, and analyze the problem openly, and self-critically, without coming to premature conclusions… Self-criticism is not the forte of this group unfortunately, and therefore improvement in this field is difficult/impossible. yeah. there seems to be a lot of self reinforcing mindsent sadly... ↺

imagine your car have a JID and you send a text to turn on the air-con before you leave the house 😁 that'd be cool

The premise that the XSF should have a singular focus at the expense of others is frankly absurd, we are a volunteer org

Trung: no, cars shouldn't be connected to the internet at all ever :P

well volunteer doesnt mean we are not focused :)

oh rite sorry hahahahaha

Trung: We are involved in exactly such projects. Also, allowing the car to pay for parking automatically… XMPP in the back-end.

Peter Waher, if you want more IoT in the XSF, you need to participate in the XSF, you need to encourage others in your space to participate in the XSF. That's about it.

We have an iot channel on this server and you're not in it :)

well sadly thats half the work

If no one is paying me I'm not going to focus on iOT in my free time, if they try to pay me I'll try and find another job :P What's wrong with focusing where you want to focus personally?

the other half is xsf being open to it and promoting such stuff

MattJ: I did that, and retracted proposals as there was little interest in this group. It’s greater elsewhere.

as pep. has said also many time

MSavoritias (fae,ve), the XSF is open, as I said

The XSF is the people who participate in it

The XSF is not some mythical being behind a curtain

Things will have overlap and collaboration is great and is what the XSF is for, but it having a focus outside that is absurd

of course not. i didnt say it was

Nothing says you _have to_ do it in the XSF

Examples: * https://xmpp.org/extensions/xep-0323.html * https://xmpp.org/extensions/xep-0324.html * https://xmpp.org/extensions/xep-0325.html * https://xmpp.org/extensions/xep-0326.html

but being open is half the work as i said

(and several others)

If you wanna publish XEP-like things trough other means, that is also allowed.

If nobody with IoT interests or expertise participates in the XSF, the XSF does not have any IoT expertise or interests

MSavoritias (fae,ve), and who do you expect to do the other half of the work?

The point is: It is a volunteer organization. A lot of energy goes into writing proposals. You only spend that time and energy, if the recipients is interested in receiving the message. The alternative is to wait for a better opportunity (times change, and so do interests), or find other communities, more interested in these fields.

That's fine. If IoT folk are gathered elsewhere, that's the best place to reach them, indeed.

> MSavoritias (fae,ve), and who do you expect to do the other half of the work? collectively :) how do we expect people to contribute xeps and their time if we are not proactively helping in that direction ↺

MSavoritias (fae,ve), step up and get us engaged in IoT then

Peter Waher: has anyone written a XEP the XSF has said "no we aren't interested in that" ? Not that I've seen

This is why other groups and technologies are more successful. It is also why XMPP is not mentioned in commercial settings: There’s no benefit of doing so, or be associated with it unfortunately (or they would have promoted it).

MSavoritias (fae,ve): I've also never seen anyone not help with anything asked

Thank you for sharing your interest Peter Waher. I'm looking forward to trying your XMPP client. ✏

moparisthebest: Yes, many times.

If iot folks don't want to be involved in the XSF fine, if they do great, it's no problem that needs addressed either way imho

Peter Waher: example?

moparisthebest: Many, from many years ago. The latest is recent, when you also were active in the group. It concerns content-type declaration of messaging content (such as Markdown). Resent a previous proposal (that was never accepted, even to Experimental for discussion) to the XSF editor a couple of weeks ago; no interest, not a response. It is not badly formed. The problem is that members of this group work against the interests of others, because they see no personal interest in the proposals, and therefore also restrict the possibilties for others, who do see a potential. Lack of ability to accomodate different use cases, reduce the benefit of a standards body. You don’t have to agree to implement all standards, just allow the XSF, as a body, to standardize interfaces as a means to improve interoperability in those fields. Today it’s all or nothing. (cf. IETF, W3C, IEEE and others, that accomodate different use cases/interests in different working groups and different standards, even opposing standards, for the benefit of those that wish to interoperate accordingly). Only parties interested in the corresponding use case would have a meaningful say in if that standard is well defined (or sufficiently defined) or not. If you take Markdown as an example: An interoperable way of transmitting Markdown is useful for those that want to do so. Those that make a decision NOT to use Markdown (for whatever reason) don’t need to implement it. But, as the XSF is defined now, they can also work against those that wish to use it. I.e. for a standards body to be more generic, it should accomodate stake-holders to vote on specific proposals, and decrease the ability of non-stake-holders to restrict such use. The latter only leads to fragmentation, which is what is happening to the XSF and XMPP-related technologies.

"moparisthebest> Peter Waher: has anyone written a XEP the XSF has said "no we aren't interested in that" ? Not that I've seen" Nobody representing the XSF said that ever, probably. But not saying "we're not interested" doesn't mean you're interested either.

I (Editor) replied to that mail, Peter, asking you to confirm whether the protoXEP was unchanged since last submission so I could just reforward to Council, and told Council that it was inbound. So it wasn't ignored.

Ok, interesting. Do you have a time-stamp? From what e-mail was this sent?

(content-type)

I've been desperately shit at keeping up with Editor stuff, but that one ball I didn't drop :)

That is some positive news

Should have been from my Isode account, I think.

But if you just say "Yes, it's unchanged", now I'll ask Council to deal with it.

to the same mail I sent it from? Or an old e-mail address?

I did not change anything, just resent the earlier proposal

(Or if it is changed, I'll commit etc.)

I just hit Reply All.

moparisthebest, that's typical liberal thinking. "We're not preventing something from happening" thinking it's people's fault if they don't come for the thing. As opposed to actively doing stuff encouraging this something to happen.

And that's generally what I don't like around here

Peter Waher: glad to see it's not still happening at least, please speak up if it does

Kev: No isode-mail in any of my mail accounts. Can you please resend, to see if I get it this time?

pep.: sorry I don't understand that at all, if there's a problem I want to know about it, if people don't feel like submitting specs I literally don't care

Peter - I'd rather just answer it here and save time, if we could :)

Oh FFS.

Kev, Peter Waher: I am unsure if we are having generic mail issues at the moment, and if this prevents you from reaching out to eachother over mail, if that's what you are trying to do now.

So the issue is that I did 'reply all', which unhelpfully, with Editor's mailing list configuration, seems to reply to editors@ twice, and to the sender not at all.

So, sorry, the mail went to the Editors' list and never to you.

Oh, that is not very helpful indeed.

Wait... It wasn't DNS ? 😳

I really don't know. I think I heard someone mention mail too, but I might be wrong.

Kev: If possible, please resend, or send anything. I want to make sure there’s nothing wrong that prevents me from receiving messages from you.

See above :)

> MSavoritias (fae,ve), step up and get us engaged in IoT then thats not how it works though is it? As i said theoretically a group being open doesnt mean anything if it practically doesnt "elevate" and do effort to have such contributions. See women in tech for example. Which people seem to think its fixed to just be "open" ↺

also not really a nice way to engage the convo with its your responsibility :)

Stop inventing problems

> pep.: sorry I don't understand that at all, if there's a problem I want to know about it, if people don't feel like submitting specs I literally don't care well you will care when all the devs leave for matrix or other ventures ;) ↺

XSF is mostly about specs and not devs or users AFAICT? But also that's just down to what members perceive as the purpose I guess. If we all do something else the org becomes something else :)

> Stop inventing problems just want to add as my last message in this that me saying we are not encouraging things and getting the response that I am "inventing problems" is insulting. and what i was pointing out too :) ↺

Still don't care, I'm here to improve XMPP for communication between my family, if it benefits others great, if not I can still use it

moparisthebest, I also think your response ("Stop inventing problems") is inappropriate. ✏

you may disagree about the importance, but please don't dismiss concerns of others like that.

(<https://xmpp.org/extensions/xep-0458.html#sect-idm45396429693776> is relevant)

"XSF needs to attract iot devs" "XSF needs to attract contributions from X" these are the "newly invented problems" I was referring to, if that's what you want to do as an XSF member, great, but pretending it's a problem the XSF as a whole should address is, again, as I said before, absurd

moparisthebest, I fully understood that, and my response to your response was phrased with that in mind.

you may disagree about the importance, but don't dismiss such contributions like that. that's patronizing, presumptuous and overall unkind and I'd like to not read such stuff here. thanks.

> So, sorry, the mail went to the Editors' list and never to you. Hey guys, I think the problem has been solved 😁

Sorry I didn't mean it to come off that way

Thanks Trung, for noticing that; missed that part. Thanks Kev. BTW: Nothing changed from the original proposal.

Thanks very much.

MSavoritias (fae,ve): again sorry for that, you are doing excellent work over at joinjabber etc, I didn't mean that aimed at you as much as the general: > See women in tech for example. Which people seem to think its fixed to just be "open" Which I have never bought into. imho being open is enough and if people don't want to participate fine. It's of course valuable to find out if there is a problem preventing them from participating, hence my question to Peter and such, but otherwise I see no reason to go out of the way to involve anyone who isn't motivated to be involved... And that's what I should have said instead of accusing anyone of creating problems... :(

apology accepted :) I get it we have different perspective in this. As i said being open is half the work for me.

For me the cool thing about XMPP/XSF is the overlap, pubsub was kinda iot-ish, but then it found uses for im encryption, and blogging, etc etc so it's actually good we have different focuses individually and can collaborate here anyway, again, in my opinion :)

i agree

@emus I’ve created https://wiki.xmpp.org/web/Board-Meeting-2023-04-05 - you and others should feel free to edit it.

(I am not sure how to modify the official XSF calendar - perhaps @ralphm can enlighten us.)

"imho being open is enough and if people don't want to participate fine." yeah exactly that's the issue. This isn't helping at all those who do want to participate, if no care is given to the question. Anyway as I said at first, I've always found this sad about the XSF. (And it's not like I haven't tried to push for change, and also why JJ is a thing)

I haven't seen that though, how can you fix something when you have no evidence of it happening, cannot reproduce... In fact I've seen only the opposite, people encouraged to participate, as members or not, people offering to help with specs and all that too

So don't say "we're just open and that's enough" if it's not the case? Even though I do think plenty more could be done

I think that's all part of being open no?

Open isn't "you can join but we'll flame you, noob"

"open" also isn't "we unlocked the door, good luck opening it"

Or rather.. sorry, that's what it sounds like to me when you say it

IoT is so 2010. What we need is ~block chain~ the metaverse

Peter Waher: fwiw I think the content type xep has a good chance at being accepted as an experimental xep under the current council

Thanks for the info

Might be of interest to ponder, is how good-faith, bad-faith and pretense affect our discussions. These are old concepts, old problems, that have been solved many times before, and that need to be re-solved every time an organization tries to include people with different interests to cooperate, especially if the goal is cooperation for working together for a “common good”. https://en.wikipedia.org/wiki/Good_faith ✏

The arguments brought forward against the XEP in 2016 are valid but I think council has shifted more towards 'handing out xep numbers to give people a stable location to work on something'

It would be good to reiterate those when the XEP is published, so they can be addressed.

The most valid one (imho) are the undressed security issues around multiple contents and what happens if they don't have the same meaning. (when your markdown version says something completely different then your plain version) and different users thus get shown different things ✏

This is correct, as you mention. Same problem exists with all Internet Content-Type’s and MIME-types BTW. And, there are efforts that are worked on, some partially solved, but in other layers (i.e. not transport layer). So, a security note would be good to add.

Which is imho a huge problem but the same as xml:lang in plain XMPP :'(

For the interested. In the Markdown case, you have this effort: https://commonmark.org/ ✏

> Which is imho a huge problem but the same as xml:lang in plain XMPP :'( Yes the same problem is built into xml. But that doesn't mean the security considerations should skip over it

But there are other content-types of course that can be used. Playing with the idea of a LaTeX-compliant client for scientists, for instance (Content-Type application/x-latex BTW).

100% needs security considerations yes

etc.

The idea is that Content-Type is a well-known and well-recognized means to annotate the syntax and semantics (albeit not always to a 100% ) of content (text-based and other), and it would be good to incorporate that base into XMPP messaging. ✏

Peter Waher: having a content Type and having multiple contents is not the same thing. One could (theoretically) just have the 'first case' where content type is just an annotation to the body

(then users/developers can choose which they prefer, and still maintain a level of Interoperability, just as browsers maintain interoperability with web pages, etc.)

This is not council advice. Just saying

Daniel: Yes. But multiple embodiments of the content makes interoperability easier, as you can provide multiple formats of various complexity to multiple clients, without the need to check what they support (which would be the case in pubsub for instance, or muc)

fwiw, Atom allows something like this (text / html) and it's used in microblog already

(cf. copy-paste that uses this method to put various copies of the same content in the clipboard, using different encodings, allowing the recipient to choose the best option)

pep: yes, exactly. And e-mail. It is common in cases where you don’t know (or want/can know) what the client expects/is able to present.

Peter Waher, Not entirely sure what you mean though. In this case would you propose every format that ever existed?

cf. Content-Type multipart-alternative (for e-mail) ✏

Or maybe we can agree on plaintext / xhtml-im :)

pep: No, it would be at the discretion of the sender to choose. Many things would factor in. And over time, it would probably change. We send plain text, html and markdown for instance, in chat messages or social messages.

when it comes to data we could send a textual representation (html & markdown also) for human consumption, and XML dito, for machine reception

Peter Waher, well the idea behind xhtml-im isn't to send "markdown", it's to send something that maps to other input formats

You could also use RDF for instance, in graph-cases

(and outputs..)

pep: this proposal is not against xhtml-im. We use it together with xhtml-im (in the case for Content-Type text/html). Instead, it is a means to enrich the possibilities with multiple variants or content types.

Same reasons why you use <em> or <strong> to convey meaning instead of a visual cue

We use XML (machine-readable) for that

Didn’t we deprecate XHTML-IM for security reasons?

there are problems with injection unless a strict check is implemented, yes.

Right.

Peter Waher, I guess I don't see what else you want to convey

(other than rich text information, which xhtml-im already does)

stpeter, still useful and used though :)

Just responding to what I interpreted as comments or questions regarding the proposal. ✏

How many clients actually implement strict checking, though?

One

I suppose that’s better than zero. ;-)

I know of two, but not sure they are the same you’re thinking of Daniel.

I was thinking of poezio

Does mod_xhtmlim count?

Still, prohibiting/discouraging HTML (for example), because clients do not perform sufficient checks, is like prohibiting/discouraging images in e-mail just because there are many e-mail clients that do not properly check that encoded images are in fact images, and not executables. It is better to change client, if it has apparent vulnerabilities, and no support or development that will fix them; this results in better and richer clients over time. The first option results in poorer clients, and migration towards other technologies, where this is solved.

I see your point.

Peter Waher: fully agree. Any nontrivial UGC app has to deal with xhtml sanitization somewhere, every framework has tools for it

I don't implement the checking "to spec" I rather use the sanitization built into my framework which I would use for a feed reader or anything else

Millions of developer hours on character sets, encoding, and markup, no use case not met by ASCII, they have played us for fools 🤣

We had multibyte emojis in my day too, looked like this: :) :D :'(

Peter Waher: I personally think that's the right mindset to move forward, totally agree