[Standards] Re: Council (and what it does, and what it should do)

[MSavoritias]

On Tue, 04 Jun 2024 17:29:00 +0200
Marvin W  wrote:

> Hi Goffi,
> 
> Thanks for your message.
> 
> I know I'm not particularly good with words and my language sometimes
> tends to be perceived as aggressive or exclusive. I did not intend to
> attack or insult anyone and I apologize if I did.
> 
> On Tue, 2024-06-04 at 14:52 +0200, Goffi wrote:
> > Though I usually appreciate your feedback, I find this particular
> > comment 
> > especially pedantic and patronizing. You are aware that you say
> > people who 
> > implemented OMEMO, for instance, were irresponsible and should be
> > "educated", 
> > right?  
> 
> The people that *first* implemented and deployed OMEMO to a large
> number of end-users of the public XMPP network, before making a
> reasonable effort to stabilize the specification and to actually get
> the implementation itself to a stable state were in my opinion acting
> too careless.
> 
> It's not always black and white, and to some degree the fault was and
> is often the XSF here, which is what this discussion was meant to be
> about: To adjust our XSF procedures to better reflect the need of the
> community.
> 
> OMEMO was a mess, I think we all remember the days when half the
> messages on half of the devices would show up as "Message is OMEMO
> encrypted", even if their client was supposedly supporting some kind
> of OMEMO. Developers of clients were put on a public blame list for
> not implementing OMEMO fast enough. The reference for how things
> needed to work was not a specification, but a single implementation.

As a person who is using OMEMO that is still the case. Nothing has
changed. I get OMEMO encryption problems regularly to the point that i
am using it only if:
- The person I am talking to has only one device
- Owns/will own the device for a long time and the key will remain
  static
- Is 1:1 conversation

Everything else is doomed to fail and get the XMPP is bad reaction.

MSavoritias

PS. I am NOT saying this to get responses of "File bug reports" or
"Work together to improve things", for multiple reasons. One of them
being that in general the community seems to have given up on making
OMEMO work.

> 
> And OMEMO still is a mess, next to nobody is implementing the latest
> revision, even though we know there are ways to upgrade that do not
> break anything. And those few that only implement the latest revision
> are totally screwed because their client is incompatible with what all
> others do, so they can't even do a lot of testing and are considered
> incompatible to OMEMO, even if technically it's everyone else that's
> incompatible.
> 
> I sure hope we learn from this, "educate" ourselves and try to make
> sure it won't happen like that again.
> 
> Marvin
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Council (and what it does, and what it should do)

[Peter Saint-Andre]

On 6/3/24 3:02 AM, Goffi wrote:


All feedback from experienced community members is valuable, and I see no
reason why council feedback should matter more.


This is a very important point.

Council members are not special people with special insight - they are 
simply community members who are temporarily serving in a role that is 
necessary within our standards process.


When I was elected to the IESG, I wrote [1] the following quote on my 
whiteboard: "Power tends to corrupt." --Lord Acton


Peter

[1] https://stpeter.im/journal/1399.html

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Council (and what it does, and what it should do)

[Goffi]

Hi Marvin,

Le mardi 4 juin 2024, 17:29:00 UTC+2 Marvin W a écrit :
> Hi Goffi,
> 
> Thanks for your message.
> 
> I know I'm not particularly good with words and my language sometimes
> tends to be perceived as aggressive or exclusive. I did not intend to
> attack or insult anyone and I apologize if I did.

Thanks for your balanced reply. I'm not always diplomatic either :).

Thing is, most of us are putting a lot of effort and passion into our work, 
often for many years. We may disagree on strategy, the way to do things, etc. 
This is perfectly fine and that's why we are discussing.

But I trust the community to know well what it is doing, and even if we may 
disagree on the right way, I believe that dev teams know what they are doing.


> The people that *first* implemented and deployed OMEMO to a large
> number of end-users of the public XMPP network, before making a
> reasonable effort to stabilize the specification and to actually get
> the implementation itself to a stable state were in my opinion acting
> too careless.
> 
> It's not always black and white, and to some degree the fault was and
> is often the XSF here, which is what this discussion was meant to be
> about: To adjust our XSF procedures to better reflect the need of the
> community.
> 
> OMEMO was a mess, I think we all remember the days when half the
> messages on half of the devices would show up as "Message is OMEMO
> encrypted", even if their client was supposedly supporting some kind of
> OMEMO. Developers of clients were put on a public blame list for not
> implementing OMEMO fast enough. The reference for how things needed to
> work was not a specification, but a single implementation.

AFAIR there was also a specification on Conversations website from  early days.

I don't think that is was a mistake, I've already exposed my opinion, but 
there was pressure from the IM alternatives and the users too, and at the time 
only OTR was available, and only implemented by few (with problems as we 
know).

If we had waited, for the "right" version which was done at 2021-10-07  
(version 0.8.1), I'm pretty sure that the state of XMPP ecosystem would be 
worst that it is nowadays. First specification is from 2015-10-25, that 6 
years!

OMEMO has been quoted many times in literature. I believe that XMPP is still 
considered as a viable protocol for IM and more by many partly thanks to 
OMEMO.

The "Message is OMEMO encrypted" thing was notably due to one client using it 
by default, which is the only case I remember of a breaking protocol thing, 
and has nothing to do with specifications. This thing put a lot of pressure on 
developers. I don't blame the dev which did that, it was done for a reason and 
it's totally understandable, and maybe a good move.

Again, we have disco and namespace to handle various versions, if a client 
implement a new version, it's a choice to keep previous implementation for 
compatibility, and I believe most are doing that in critical cases

In the case of OMEMO, I only know one client that implement OMEMO:2 and not 
the legacy one, and this client is young and took some radical decision; I'm 
not sure if it's still the case, but at one point they didn't wanted to 
implement XEP-0045, despite its "stable" status, and wanted to focus on MIX, 
so the specification status didn't change a thing here.

I really think that we should separate "specification" work from 
"implementation" work (put aside the reference implementation thing):
you can have a buggy implementation of a final specification, or incomplete, 
and 
an "experimental" specification can have a rock solid implementation (which can 
be updated if new version arise).

Also, it's not necessarily a good thing to rush to put something to stable: 
feedback also come from end-user, and they may suggest an interesting change 
which could be done with, say, a new attribute or element with a namespace 
bump, which is easily done with an experimental XEP, but hard to impossible in 
stable or final.

And there are many use cases where important things may not be anticipated at 
all by developers because they don't know specific fields. I'm thinking about 
accessibility for instance. Feedback from community from implementing clients 
is previous there.

Trying to freeze as many specification as possible as soon as possible can be 
counterproductive.

> 
> And OMEMO still is a mess, next to nobody is implementing the latest
> revision, even though we know there are ways to upgrade that do not
> break anything. And those few that only implement the latest revision
> are totally screwed because their client is incompatible with what all
> others do, so they can't even do a lot of testing and are considered
> incompatible to OMEMO, even if technically it's everyone else that's
> incompatible.

It's a choice to implement only latest version when everybody know that only 
few clients are implementing it at the time. First iteration took years too, 
because resources a

[Standards] Re: XEP proposal: filtering chat notifications

[Nicolas Cedilnik]

Hi all,

I gave an attempt at this, you can read a built version here: 



I made it so it can be a bookmarks  child, but did not make 
that a requirement, to leave the door open for use in other places, 
possibly best suited for 1:1 chats.


I opened a PR on github: .

Feedback welcome!

-- nicoco

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Council (and what it does, and what it should do)

[Marvin W]

Hi,

On Tue, 2024-06-04 at 08:43 -0500, Stephen Paul Weber wrote:
> Implementors should be aware this is 
> experimental and may change and be flexible to support multiple
> versions of 
> it over time, etc.

I think my point is that I don't have the feeling that this the case.
With my developer hat, I for once do not generally expect that I will
be forced anytime soon to do adjustments to the implementations of
Experimental XEPs that are implemented in Dino. I obviously can't speak
for others, but with OMEMO we certainly see that implementers are not
generally aware that they should or are not willing to change to newer
versions of it over time. Also, as some XEPs stay in Experimental for a
long period of time, the people that originally implemented it
somewhere might long have stopped working on it if an update happens
years later - so there might just be nobody that can update the code
for realizing a breaking change in some codebase.

Marvin
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Council (and what it does, and what it should do)

[Marvin W]

Hi Goffi,

Thanks for your message.

I know I'm not particularly good with words and my language sometimes
tends to be perceived as aggressive or exclusive. I did not intend to
attack or insult anyone and I apologize if I did.

On Tue, 2024-06-04 at 14:52 +0200, Goffi wrote:
> Though I usually appreciate your feedback, I find this particular
> comment 
> especially pedantic and patronizing. You are aware that you say
> people who 
> implemented OMEMO, for instance, were irresponsible and should be
> "educated", 
> right?

The people that *first* implemented and deployed OMEMO to a large
number of end-users of the public XMPP network, before making a
reasonable effort to stabilize the specification and to actually get
the implementation itself to a stable state were in my opinion acting
too careless.

It's not always black and white, and to some degree the fault was and
is often the XSF here, which is what this discussion was meant to be
about: To adjust our XSF procedures to better reflect the need of the
community.

OMEMO was a mess, I think we all remember the days when half the
messages on half of the devices would show up as "Message is OMEMO
encrypted", even if their client was supposedly supporting some kind of
OMEMO. Developers of clients were put on a public blame list for not
implementing OMEMO fast enough. The reference for how things needed to
work was not a specification, but a single implementation.

And OMEMO still is a mess, next to nobody is implementing the latest
revision, even though we know there are ways to upgrade that do not
break anything. And those few that only implement the latest revision
are totally screwed because their client is incompatible with what all
others do, so they can't even do a lot of testing and are considered
incompatible to OMEMO, even if technically it's everyone else that's
incompatible.

I sure hope we learn from this, "educate" ourselves and try to make
sure it won't happen like that again.

Marvin
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Council (and what it does, and what it should do)

[Stephen Paul Weber]

3. We should more actively discourage release of functionality based on
ProtoXEP and Experimental XEPs in production (except hidden behind feature
flags or options clearly marked as experimental).


And that's how you end up with Pidgin not having MAM or the like for years.
Because they indeed refuse to implement Experimental specs.

In other words. You can discourage all you want, that won't stop anybody 
from

implementing what they need. And I'd rather have people take a half-baked spec
in Experimental and try to improve on it and report back. They may release it
however they want.


The key this is not to refuse to implement experimental XEPs (indeed I would 
hope for at least one implemenation before it reaches experimental!) but 
rather to not refuse to make breaking changes to experimental XEPs based on 
the fact that people are using it. Implementors should be aware this is 
experimental and may change and be flexible to support multiple versions of 
it over time, etc.


signature.asc
Description: PGP signature
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Council (and what it does, and what it should do)

[Goffi]

Le mardi 4 juin 2024, 12:18:34 UTC+2 Marvin W a écrit :

> Of course there are three kinds:
> (a) Those that consider the protocol ready for use in production
> software and thus use in production software
> (b) Those that consider the protocol not ready for use in production
> software, but don't care because they want the feature and don't want
> to fix the protocol before using it in production software
> (c) Those that consider the protocol not ready for use in production
> software, but need to implement it for compatibility with other
> production software, because of those in (a) or (b)
> 
> I'd say that:
> (a) should just step up and make sure the protocol is turned stable, if
> it can't be turned to stable, they might even learn why the protocol is
> in fact not ready for use in production, so it's good for them if they
> try to move it further.
> (b) is just irresponsible behavior. Irresponsible towards your users
> (by shipping things to them you consider broken yourself) and towards
> the wider community (by requiring everyone to now deal with what is not
> ready for production in their production software).
> (c) is the worst that we have it, but impossible not to have as long as
> there is (a) and (b).
> 
> I'd hope we can get rid of (a) and (c) through changes in the process
> and (b) by education.
> 

Though I usually appreciate your feedback, I find this particular comment 
especially pedantic and patronizing. You are aware that you say people who 
implemented OMEMO, for instance, were irresponsible and should be "educated", 
right?

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: Council (and what it does, and what it should do)

[Marvin W]

Hi,

On Tue, 2024-06-04 at 11:10 +0200, Maxime Buquet wrote:
> No, this only says that this is a much needed feature, whether or not
> the
> protocol is considered "ready for use in production software"
> (whatever that
> means[0]) is irrelevant IMO.

Of course there are three kinds:
(a) Those that consider the protocol ready for use in production
software and thus use in production software
(b) Those that consider the protocol not ready for use in production
software, but don't care because they want the feature and don't want
to fix the protocol before using it in production software
(c) Those that consider the protocol not ready for use in production
software, but need to implement it for compatibility with other
production software, because of those in (a) or (b)

I'd say that:
(a) should just step up and make sure the protocol is turned stable, if
it can't be turned to stable, they might even learn why the protocol is
in fact not ready for use in production, so it's good for them if they
try to move it further.
(b) is just irresponsible behavior. Irresponsible towards your users
(by shipping things to them you consider broken yourself) and towards
the wider community (by requiring everyone to now deal with what is not
ready for production in their production software).
(c) is the worst that we have it, but impossible not to have as long as
there is (a) and (b).

I'd hope we can get rid of (a) and (c) through changes in the process
and (b) by education.

When I talk about production software, I'm referring to the server and
clients that are used by thousands of end-users and that are therefor
impossible to ensure are properly updated. And I'm talking exclusively
about released production software (whatever that means for the
project, aka what they suggest their end-users that want somewhat
stable software to use).

> Experimental isn't the issue. The thing is that people want features
> /
> improvements and will implement them, and that's great. There's no
> preventing
> it. By doing so they should also ready to also do the work to update
> their
> software whenever the spec gets updated.

I never said Experimental is an issue. The problem is also not that
people want features that are currently only available in Experimental.
The problem is that we don't manage to move specifications from
Experimental (or even before that) to Stable before they are so
widespread that changes are hardly possible. If you can't experiment
with it anymore (because it would break production software), then it
shouldn't be in Experimental.

> How does one even experiment without implementation?

I was referring to production software implementations, not
implementations in test software, feature branches or other
experimentation places.

> And that's how you end up with Pidgin not having MAM or the like for
> years.
> Because they indeed refuse to implement Experimental specs.

MAM should have been Stable for years before it was marked so that
everyone has a basis they can develop on. Pidgin is right in saying
they don't want to implement something that says "don't ship this to
endusers" in it's header. It's just that many others decide to ignore
that warning and therefor there is inconsistency in what's supposed to
happen with Experimental XEPs.

> Life happens, and people working on specs also get hit by buses /
> have
> other things to take care of. The burden can't be put on just one
> person
> alone to do the work. It happens but it's rare that council does
> something about it.

Not sure what you mean. I never said a single person should do a ton of
work. I said that if a XEP becomes de-facto stable (because it has
widespread production implementations and therefor can't be changed
without causing compatibility issues) we should move it to stable. If
there is still (backwards-compatible) work to be done for the XEP to be
moved to stable and the author can't do it themselves, someone needs to
act as a Document Sheppard as outlined in XEP-0001. The process is all
defined, we just don't make use of it.

> In other words. You can discourage all you want, that won't stop
> anybody from
> implementing what they need. And I'd rather have people take a half-
> baked spec
> in Experimental and try to improve on it and report back. They may
> release it
> however they want.

I am wondering why you think it's good they use Experimental in
production. Wouldn't it be better if the spec they need is in Stable?
The list of items I provided obviously only goes if we do all of them:
Move things to Stable faster so that developers don't need to use
things from Experimental in production.


> Yes it is clear. It's you that don't want to accept that people may
> choose to
> implement a protocol that will likely break.

End-users don't decide what is implemented. If end-users see that the
message editing they have in their client stops working from one day to
the other (because other clients updated to a new, incompatible
revision), they 

[Standards] Re: Council (and what it does, and what it should do)

[Maxime Buquet]

I'm catching up on this thread and I'm replying to two of your mails at
the same time.

On Mon, 03 Jun 2024 12:37:21 +0200, Marvin W wrote:
> I tried to circumvent this by writing XEP-0447 [..] yet there already have
> been implementations from the community in released software.
> This underlines my point that Experimental is considered "ready for use in 
> production software" by some.

No, this only says that this is a much needed feature, whether or not the
protocol is considered "ready for use in production software" (whatever that
means[0]) is irrelevant IMO.

> As explained, we have de-facto reached the state where something that's
> considered useful to developers is in Experimental for more than a few
> months, we will see it in production and therefor will have to consider
> interoperability and compatibility with this specific Experimental version
> for at least some time. And that is where the feeling for the need of a
> higher bar to Experimental comes from. So to reduce the bar for
> Experimental, we have to move to Stable faster or the ecosystem will move
> faster than we manage the XEPs.

Experimental isn't the issue. The thing is that people want features /
improvements and will implement them, and that's great. There's no preventing
it. By doing so they should also ready to also do the work to update their
software whenever the spec gets updated.

> because Experimental shouldn't have had implementations.

How does one even experiment without implementation?

> 3. We should more actively discourage release of functionality based on
> ProtoXEP and Experimental XEPs in production (except hidden behind feature
> flags or options clearly marked as experimental).

And that's how you end up with Pidgin not having MAM or the like for years.
Because they indeed refuse to implement Experimental specs.

Life happens, and people working on specs also get hit by buses / have
other things to take care of. The burden can't be put on just one person
alone to do the work. It happens but it's rare that council does
something about it.

In other words. You can discourage all you want, that won't stop anybody from
implementing what they need. And I'd rather have people take a half-baked spec
in Experimental and try to improve on it and report back. They may release it
however they want.


On Mon, 03 Jun 2024 14:58:23 +0200, Marvin W wrote:
> On Mon, 2024-06-03 at 14:10 +0200, Goffi wrote:
> > The "experimental" state is clear: it may change and break.

> That seems to not be clear to anyone, to be honest, especially not end-
> users and also not in how we market our products.

Yes it is clear. It's you that don't want to accept that people may choose to
implement a protocol that will likely break.

Your following example with 0384 is only good in that it would have made
it much more easy to find if there was another XEP number assigned for >
0.3.0, as flow and goffi have said (or will say?) in this thread.

[0]: https://bouah.net/2022/09/versioning/



signature.asc
Description: PGP signature
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org