XSF Discussion - 2022-04-29

Well, it seems this group is equally stunned.

crypt: XMPP is not better than Matrix and Matrix is not better than XMPP. They are _different_: https://www.freie-messenger.de/en/systemvergleich/xmpp-matrix/

Associating XMPP to WhatsApp's use-case only is quite limiting :/

Also it seems you're mixing XMPP and XSF.

This is the reason for > Partly the question which app should be used is answered like this ... but suggestions are always welcome.

> Also it seems you're mixing XMPP and XSF. What has to be changed/corrected?

XSF rules are not XMPP rules, that's it

The XSF is just an actor contributing to XMPP like anybody else could

> XSF rules are not XMPP rules, that's it Ah ok - will edit this. Thanks!

That is, there can't be a hostile takeover of XMPP anymore. Of the XSF "it depends", and surely it could impact protocol making within the XSF but it shouldn't impact projects that much. There's no reference implementation, etc. (or is there?)

Maybe it makes sense to differ here between XMPP as a standard/protocol and when talking about XMPP as an entire ecosystem/network (jabber, \me hides 😬) ✏

Maybe it makes sense to differ here between XMPP as a standard/protocol and when talking about XMPP as an entire ecosystem/network (jabber, _emus_ hides 😬) ✏

I don't like to use the term jabber as it's 'owned' by Cisco. Also I met people who were not willing to try xmpp because I called it jabber and they use Cisco jabber in the company and they don't like it.😂

There's still a good term missing that's not as technical as xmpp but not burned by Cisco.

Jitsi jami jabber... joom? ✏

Snikket!

It has a good baseline of “modern” clients, so you won’t burn your users too much either. :)

So headline "Explanation of XMPP rules" -> "Explanation of rules in XMPP environment"?

:/

*IM*: > So headline "Explanation of XMPP rules" -> "Explanation of rules in XMPP environment"? The heading is okay either way, the important bit is to first say that xmpp isn't ruled by any single entity and briefly explain the roles of ietf and xsf as major contributors ✏

Link Mauve, names could be for: - The technical protocol. ActivityPub. XMPP. - The federated open network of said protocol. Fediverse. ? - A selection of client and server software. Mastodon. Snikket

mjk, I think the headline is bad either way, but I agree with what you say next

larma, the discussion was about which name to use to talk with random people who you might want to bring to XMPP.

> I think the headline is bad either way Well it's not _wrong_ at least, I think

I think it is

XMPP is bound by no XSF rule

Hmmyeah

The goal in this category is to say XMPP isn't going to be subject to hostile takeover, which it isn't in any case

> Fediverse. ? Jnikket!.. Oh no, there's something ominous in the first 3 letters

:D

Mind you, I'm not saying XMPP isn't being improved / influence greatly. And the XSF plays a (too important, imo) role in this, without acknowledging it, but that may be another topic

But here I use XMPP as a protocol AND as the community of projects / use-cases

*IM*, I'd formulate it differently, as mjk says and I confirm here. XMPP isn't bound by XSF rules, and anybody can reuse the protocol as they wish. Now, in practice, there is a number of people and projects gravitating around the XSF and these are influenced by decisions the XSF make to some extent (a great extent sometimes)

Just look at the number of projects holding features hostage because the XSF hasn't stamped them ✏

> xmpp isn't ruled by any single entity and briefly explain the roles of ietf and xsf as major contributors Would this text be ok/enough? Otherwise, a concrete suggestion of what the text could look like would help me a lot here (english is not my native language).

*IM*, also if you cite german military as user count, you can cite NATO using XMPP. Same kind of .. ✏

pep., so custum extensions such as ProcessOne's MUC/Sub or those published by Tigase are standard XMPP in exactly the same way as the extensions published by the XSF?

If there's some kind of open process to contribute to them I don't see why not

The protocol used by WhatsApp is standard XMPP, or at least it would be if they published the specs on some random web site?

Ah it's about "contributability".

To me yeah. Standard doesn't mean "good", but it's better than not

I'm not trying to make some "standard" == "good" statement, but I do think there's value in trying to stick to a single entity being responsible for maintaining an open spec. Because interop.

Holger, I'd say it's in the spirit of the 4 freedoms, to me. Use, Study, Share, Modify

Holger, which single entity, IETF or XSF? :)

Or IEEE?

pep., for XMPP, clearly the XSF, it's even mentioned in RFC 6120

Isn't it a problem for a communication protocol if modification breaks communication?

You're obviously "free" to publish arbitrary modifications, I'm just questioning whether that's desirable.

jonas’, also from 6120: « Although extended namespaces for XMPP are commonly defined by the XMPP Standards Foundation (XSF) and by the IETF, no specification or IETF standards action is necessary to define extended namespaces, and any individual or organization is free to define XMPP extensions. »

Holger, and the XSF isn't publishing modifications to its own documents maybe?

Yes my ideal standards organization would have an even stronger focus on consistency & interop than the XSF does. The usual response is "Compliance Suites". Assuming that's the proper solution, I think it's desirable to have a single entity maintaing those.

Whereas my understanding of what you're saying is that consistency/interop would be a non-issue, so I'm just asking whether I got that right 🙂

I don't. I don't think interoperability is achievable at a protocol level, or we're talking about a very low bar, I'd rather aim for it at the product level

How's that different from the WhatsApp and Signal products then?

They're not decentralized?

Ok Wire.

I don't know Wire

Maybe it isn't. Is Wire anything else than their implementation?

Ok yeah I remember them promising to publish their s2s specs but my guess would be that didn't happen yet, heh.

But yeah that's where we can agree to disagree then I guess.

To be clear, I'm not saying I don't want to achieve some kind of interop at the protocol level. I'm saying it's hard. Everybody's got different use-cases and thinking interop can be achieved at this level is nothing but a lie to me

I definitely believe interop at the protocol level is achievable & desirable.

We see this everyday

Every day users saying "I want this and I can do half of it with clientX and the other half with clientY"

"It's a feature"

They get as a reply

We'll easily agree it's hard 🙂 But hard != impossible. There's countless communication solutions that interop based on IETF specs.

pep., let them eat ~cake~ Snikket?

Zash, yeah that's one good example

It's of course still not perfect but at least goals are clear

IP, TCP, SMTP, SIP, ...

> "I want this and I can do half of it with clientX and the other half with clientY" Yes that's a problem, we just disagree on the proper solution.

It's a natural consequence of implementers having different priorities, no?

Holger, I think the thing is, by wanting to gain interop at the protocol level, you end up limiting the protocol in use-cases

And the collection of features and corresponding specifications is large

Zash> It's a natural consequence of implementers having different priorities < yes

I don't think the real problem is an unlimited number of use cases.

(it's never really unlimited either, but we understand each other)

We do, but I think the fragmentation we see is largely due to missing manpower/$$$ and less so due to incompatible use cases.

XMPP users want to do WhatsApp, Slack, or IoT. Then there's very specific stuff such as Isode customers using sattelites or whatever, but that's not the issue.

The network layer doesn't change that most chat users are looking either for WhatsApp or Slack style, I think.

Why not both!

.. is that one of those things where, X or Y is doable, but X AND Y is multiplicatively more expensive to implement?

Something something https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/

ActivityPub is also a good example of this

ITYM MastodonPub?

Ok they've got interop at a really low level, but these apps don't work together once you get below the surface

Well, true, s2s works decently well from what I've seen.

Or yeah, they use ConversatioMPP

Conversations and Messaging Protocol?

So XMPP wants to be many things to many people? 🤔

Kev, right. I guess there's also higher level examples such as security labels or whatever, but I think those aren't a problem, the 'X' in our protocol name is really good in specifying optional extensions for specific use cases. The problem is that we're having a hard time standardizing a given use case such as WhatsApp. It's not clear how to do avatars, or group chat, or E2EE, let alone avatars or E2EE within the group.

(fwiw standardizing avatars in MUC has been attempted at least 2 or 3 times, and shot down)

(within the XSF* :p)

And I just doubt this would improve if ProcessOne started to spec their own solutions in addition to the existing mess.

pep., yes.

I'm not entirely sure why we're trying to keep efforts centralised when we're working on a decentralized spec. Isn't that saying something about people working on the spec and their mindset?

I guess I could only repeat myself. I want interop between decentralized entities and I don't see how to get there without a centralized effort to specify how that interop works. If that says bad things about my limited mindset so be it 😉

I haven't said limited

And I didn't mean limited, either

I totally get how it's easier to give up this mindset and just let Jitsi or Snikket or Wire build their products using self-baked specs.

>> Holger: >> 2022-04-29 05:10 (CDT) >> We do, but I think the fragmentation we see is largely due to missing manpower/$$$ and less so due to incompatible use cases. Lack of focus on who you're trying to serve and what the shared goal is would definitely contribute to fragmentation and energy being spread out to unrelated projects.

I definitely agree with lack of resources in general, fwiw. But I don't think that calls for all rallying under the same umbrella that promotes values that it doesn't want to admit

(the so-called neutrality)

I think also having ideas / specifications sprout from other places would be benefitial for the protocol and the community at large ✏

I think _if_ the goal is to have a centralized effort to specify how interop between decentralized players works it's essential to allow for participation of those players, which implies trying to protect against hostile takeover, which I guess was the motivation behind the neutrality stance, But maybe such protection wouldn't have to contradict the value promotion you'd like to see, esp. if all players can agree with those values ...

Neutrality is a lie :)

Not getting into this right now (again) sorry 🙂

hehe

I think that may be my biggest disagreement on how to handle the protocol

To have to operate under one single entity with which I disagree in goals

Can't follow the discussion 🤷‍♂️ - need a german summary at the end (please).

Not like I haven't tried to move the direction in the past, and I've also been shot down.

>> Holger: >> 2022-04-29 05:11 (CDT) >> XMPP users want to do WhatsApp, Slack, or IoT. Then there's very specific stuff such as Isode customers using sattelites or whatever, but that's not the issue. I didn't even know this was a thing. Scratching my head.

And here I thought it was about "presence, instant messaging, and real-time communication" between regular people.

pep., I'm aware. Moving existing entities into new directions is hard and frustrating.

crypt: not really. Xmpp can be used for social networks, iot monitoring systems. It can be basically anything. Libervia has built blogs on top.

crypt, between regular people, or regular Things!

msavoritias: I'm beginning to understand.

So instead of being the best at something, the project aims to be good (or mediocre) at many things... that may or may not be related.

Do all things and do them well!!

The thread between them all is comms protocol.

Quality doesn't always lead to success, depressingly

And just a regular user who is somewhat happy with Conversations on Android and disappointed I can't find a decent client to recommend to my iOS friends.

I'm thinking about the here and now - hehehe

But we've got others talking about IoT and sattelites.

> crypt wrote: > So instead of being the best at something, the project aims to be good (or mediocre) at many things... that may or may not be related. Depends on what your goal is. Xmpp goal is to be a transport and a syntax for "stuff". Messaging just happens to be one of the uses that people like xmpp and use it for. I would say its pretty succsefull with how widely it is used.

I'm not a fan of Matrix, but they have focus and vision for what they aim to be. I guess it's apples and oranges.

> msavoritias: > 2022-04-29 05:57 (CDT) > Xmpp goal is to be a transport and a syntax for "stuff". Well said. I have to adjust what I think XMPP is.

Being a secure messenger is just a use case of the platform. Up to devs to do anything with it.

It's strength tomorrow could be IoT.

Correct. It's even reflected in the RFCs, the core transport protocol <https://xmpp.org/rfcs/rfc6120.html> being separate from instant messaging basics in <https://xmpp.org/rfcs/rfc6121.html>

Feel a little sad for some reason. Ok, best of lucky with the expansion.

> crypt wrote: > I'm not a fan of Matrix, but they have focus and vision for what they aim to be. I guess it's apples and oranges. Its maybe smaller scope than xmpp. But they still have messaging, blogs, social networks, comment systems ✏

Are there groups within the XSF that focus on specific usecases of the platform. It seems there should be some compartmentalization if this is the direction XSF is going.

Like modernxmpp?

there are groups loosely associated with the XSF (as in: a lot of contributor overlap).

Or snikket ✏

such as modernxmpp or snikket, yes

There are also XSF work groups

are there

But nothing formal or encouraged by the XSF?

In theory?

does it matter?

I think it does

Xmpp is pretty permisionless. You can start whatever initiative and group you want

"work teams" was the term even. depends on the team I guess?

Hm, or was I thinking of Special Interest Groups

Oh wait, work teams is like iteam, so probably irrelevant here.

Yup, Modern XMPP is more of what I'm after. > Modern XMPP is an independent project launched to improve the quality of user-to-user messaging applications that use XMPP. XMPP is a mature open standard for internet messaging. If you are reading this, you have probably heard of it.

If there were official work groups, they could vet the extension proposals and submit and endorse the ones the group most definitely want to see implemented. This will become more important as the protocol branches out into unrelated usecases.

Without this, I don't know how you guys are going to do it.

Vetting is done by Council. Endorsement is done by whoever authors the latest Compliance Suite (also vetted by Council)

But ultimately, implementers decide what to implement, probably influenced by what their users ask for.

Correct. I'm suggesting another way that compliments that.

Zash, also greatly influenced by what The XSF says. As I said earlier, how many projects are holding features hostage because it hasn't been stamped

Random Joe presenting to a council who can't be familiar with every usecase is inefficient.

pep.: tell them to get the stamp

it's not as if council were some uber beings who always know what's right and who cannot be talked to

Often they've tried already.

See reactions?

> Zash, also greatly influenced by what The XSF says. As I said earlier, how many projects are holding features hostage because it hasn't been stamped What does holding features hostage mean? Hostages are hold against their will and can't escape. So they keep features to their own client and prevent them to get implemented by (escape to) others? This metaphor doesn't make any sense to me. 🤔 ✏

Ephemeral messages for example. Or sorry i meant "Mutual deletion of loggin capabilites on a server context or something"

mdosch, they have features ready but don't release them in part because it hasn't been accepted by the one entity

Maybe I should say the one entity holds features hostage, instead of projects :)

The age old conundrum. What comes first, implementation or specification?

> pep.: > 2022-04-29 07:14 (CDT) > Maybe I should say the one entity holds features hostage, instead of projects :) Hold features **back**.

Yeah one or the other