Also, why is it entirely ad-hoc instead of reusing e.g. MUC or PubSub primitives?
Zash
Why not?
Link Mauve
Zash, because the semantics very much match iqs.
pep.
SXE?
Link Mauve
XEP-0284.
pep.
k
Chobbeshas left
winfriedhas left
winfriedhas joined
Link Mauve
Also, why is there both a Jingle initialisation and another initialisation based on messages afterward?
larma
Link Mauve, I guess so that you don't have to ack state changes? Not that I like it, but it could have been the motivation. And also doesn't apply to the initial state offer which really is exactly iq semantics.
winfriedhas left
larma
Because someone said: "You should use Jingle for that"? đ
Link Mauve
Most likely; Iâll have to go and read the council minutes from back then.
Shellhas joined
larma
Seems it was only added in 0.0.8, but there is no history from before 2010 in git đ
And what if I want to send a message without a body and a subject�
mathijshas left
mathijshas joined
jonasâ
"", ""
jonasâ
\o/
Link Mauve
/o\
jonasâ
std::optional?
Link Mauve
This is an API I probably canât modify.
jonasâ
pity
Link Mauve
I could add a new one I guess.
Link Mauve
Still not sure why Iâm doing this in C++ and not in Rust.
jonasâ
because C++ is more awesome than this newfangled mess of "systems programming" languages :)
kokonoehas left
Link Mauve
Iâm not doing systems programming though, just adding collaborativeness to a text editor.
Zash
Link Mauve: Aaaah, CW those C++ lines plz!!!! NSFMybrain
Link Mauve
Sorry, XEP-0382 still isnât implemented in my client.
larma
Link Mauve, how is your council candidacy going? Not sure which timezone we are using for the deadline, but it's something like today...
Link Mauve
Some timezone. :)
Link Mauve
Iâll start working on it once I give up on this C++.
mukt2has joined
larma
You can not become a candidate after the election đ
Link Mauve
I know that!
winfriedhas left
winfriedhas joined
dwdhas left
dwdhas joined
debaclehas left
adiaholichas joined
mathijshas left
mathijshas joined
mukt2has left
adiaholichas left
adiaholichas joined
winfriedhas left
winfriedhas joined
mukt2has joined
winfriedhas left
winfriedhas joined
mathijshas left
mathijshas joined
Ge0rG
Link Mauve: just give up on it. I never thought I'd say that, but: RIIR!
Zash
RIIC
Zash
+Lua
winfriedhas left
winfriedhas joined
jonasâ
we already have >5 candidates. I am amazed
jonasâ
and two new ones at that
Link Mauve
Ge0rG, I wonder if Swiften might not be better than gloox.
Link Mauve
But Iâll definitely have to fix the SXE spec too.
Zash
Link Mauve: Existing thing already using gloox?
Link Mauve
No, it isnât collaborative yet.
jonasâ
larma, from your application
> That said, my criteria for accepting a XEP as experimental would be: [âŚ]
jonasâ
I think this misses an important part (which is even mentioned in XEP-0001 IIRC): "It should not duplicate existing protocols."
jonasâ
although that might be implicit in "It should solve a problem."
larma
Yeah, I think it's implicit in there. A duplicate doesn't solve any problems
jonasâ
fair enough
jonasâ
in any case, thanks for running
winfriedhas left
winfriedhas joined
Zash
jonasâ: How do you replace / improve on existing things without duplication?
Zash
Does XEP-0313 not duplicate some subset of XEP-0136?
winfriedhas left
winfriedhas joined
kokonoehas joined
winfriedhas left
winfriedhas joined
pep.
Ge0rG, https://i.imgur.com/10k62WA.png RIIR!
pep.
larma, ^
Zash
RIIR https://www.r-project.org/
pep.
:D
marc_has left
marc_has joined
Mikaelahas left
Mikaelahas joined
Chobbeshas joined
winfriedhas left
winfriedhas joined
rionhas joined
larma
pep., I will consider it for version 2.0 đ
pep.
hahaha
mathijshas left
mathijshas joined
winfriedhas left
winfriedhas joined
jonasâ
larma, re your council election again and since you have an interesting view about personal opinions:
One thing which has repeatedly come up is the debate between amending existing standards vs. creating new documents to add features (specifically around XEP-0045 and XEP-0060). Do you think this is a matter of opinion or "taste"? If not, what is the objectively correct way? If it is, how would voting on this question work with your goal to avoid personal preferences?
jubalhhas left
jubalhhas joined
mukt2has left
winfriedhas left
winfriedhas joined
pep.
jonasâ, tbh, I don't care which, but I want things to move
pep.
I think it's similar for larma(?)
Nekithas joined
larma
jonasâ, I just put something related to that topic on my candidacy page.
1. I think both 45 and 60 should probably be Final already. Most of the changes actually applied to them could be done to Final XEPs as well.
2. Many of the changes proposed to 45 and 60 could also be standalone XEPs.
3. Even if things are not properly defined, it can be later clarified that they are not part of that specification and (even opposing) proposals can then be made in new XEPs (for example IQ routing in 45).
pep.
To me it's exactly the same if somebody modifies a XEP or recreates a new XEP amending the first one. it's just the form. We as a group could settle on sth if necessary
jonasâ
larma, thanks
larma
pep., yes and no: the rules how things are advanced to Draft should also apply to significant changes and that won't be possible without a new XEP.
Danielhas left
jonasâ
larma, I think you make a very good point in that
Danielhas joined
pep.
larma, but in the end, you add a new disco feature anyway
jonasâ
and at that point itâs questionable whether namespace bumps should be needed at all anymore... but thatâs a bigger topic, too big for me right now (-> afk)
larma
I would like to get rid of "namespace bumps" and introduce "new namespaces" in new XEPs (which might just look like a namespace bump, i.e. can have only a version number added/increased)
pep.
"which might just look like a namespace bump", it's exactly the same to me indeed. and I'm fine with both, as long as things move
adiaholichas left
adiaholichas joined
Zash
Huh?
pep.
?
Zash
Namespaced mini-extension protocols without breaking everything using the previous version/namespace?
winfriedhas left
winfriedhas joined
pdurbinhas joined
winfriedhas left
winfriedhas joined
pep.
"without breaking everything using the previous version/namespace", we're not magicians
Zash
Something something like semantic versioning? You can to some extent add new stuff without replacing the namespace.
waqashas joined
waqashas left
waqashas joined
pep.
You mean "clarify"
Zash
No
ajhas left
Zash
I mean add new features
Zash
Something supporting the previous version won't know about those features, so no problem.
pep.
Yeah ok that's fine. I'm mostly talking about breaking stuff
Zash
I'm confused
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
adiaholichas left
adiaholichas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
larma
Namespace bumps should in general be barely needed IMO. Most of it can be done using disco and just additional elements
larma
but of course it's so much easier to just break things and do a namespace bump
Zash
Sometimes
larma
Well it's easier for the XEP author, not easier for the developers đ
flow
I don't think that you can make a specific statement, it really depends on the specific case.
flow
err "generic statement"
larma
True.
larma
I am also not against new namespaces, I just feel they belong in a new XEP
pdurbinhas left
flow
A fresh experimental XEP only a few months old where are developers, and that includes implementing developers, are in the same groupchat is probably easier to namespace bump than a year old xep in draft state
larma
If it's easy to namespace bump, it's also easy to just not namespace bump. That's exactly the point
flow
so what's your stance on jingle ft then? should be collect improvements and bump it?
larma
flow, not sure what improvements are you talking about?
larma
IMO Jingle FT should be at least Draft already, so if there are significant changes required they should go in a new XEP
flow
I wouldn't be suprised to find some if I am going to implement it.
Zash
Maybe what we should do is bump the namespace of Experimental XEPs even more often, so everyone either gets used to it or gets together and makes it Draft?
flow
larma, so what is the advantage if having a new XEP versus a major overhaul of the existing? (note that i have no strong opinion in that direction, just wanting to hear the rationale behind it)
winfriedhas left
winfriedhas joined
Shellhas left
Shellhas joined
larma
Zash, would actually be fine as well. Point is: Experimental XEPs should be deployed in wild, so any changes (if they bump namespace or not) shouldn't have any influence on any running systems.
flow
I'm not opposed to having Jingle-FT-2, but it doesn't feel like the question if we should new-xep or bump-the-existing-xep is something that tackles our most important issues
rion
Jingle-ft is fine as for me. Maybe separate XEPs may describe various meta information for it. Like it was done with thumbnails. Jingle-s5b needs fixes
larma
flow, If it's a new protocol it should get a new XEP number so we have a proper name/identifier for the protocol.
Zash
Jingle FT Base and a File Metadata XEP?
larma
"My server supports archives." "Which version?" "XEP-0313" isn't really helpful
Zash
larma, "XEP-0313 v0.6" tho?
Zash
== `urn:xmpp:mam:2`
goffihas left
goffihas joined
larma
So we don't define protocols in XEPs anymore but in XEP versions?
larma
and a different version could be a completely different protocol?
Zash
That's how it is now
larma
Only for very few XEPs, and I consider this an issue.
winfriedhas left
winfriedhas joined
Ge0rG
So we should define protocols by namespaces instead?
Zash
Don't we already, in a way?
winfriedhas left
winfriedhas joined
Ge0rG
On the wire, but not in the documentation.
flow
larma> flow, not sure what improvements are you talking about?
That is actually a nice example for one of the major issues we have. We are incredibly bad at collecting and organizing protocol feedback, leave allone incooperating it into a new protocol revision
Ge0rG
Speaking of which, do I need to rewrite CS-2020 now in terms of feature namespaces? Which version of MAM should it require? From clients? From servers?
Zash
This seems like pain that comes naturally from having protocols under development be implemented and deployed in the wild.
larma
We don't always change namespace for protocol changes of Experimental XEPs
flow
Ge0rG, "From Client? From servers"? What is the issue if the compliance suites that state xep313 (and that implies the current state of xep313)?
rion
Ah yes. Jingle-ft needs some clarification how to properly finish file transfer. For example when we have multiple files in one session. Or when final checksum isn't sent
larma
Probably nobody would care to bump the references namespace if 372 is changes...
kokonoehas left
flow
larma, I think there is a sensible policy that protocol changes that break interoperability require a namespace bump in place
Ge0rG
larma: normally we do bump, except under very closely defined conditions.
winfriedhas left
winfriedhas joined
Zash
> that break interoperability
This!
Ge0rG
flow: that it's not clear at which moment of time that version is pinned. On January 1st?
flow
Ge0rG, who said something about pinning the version? :)
larma
Ge0rG, I had the feeling we bump if it would break interoperability of live deployments. As per XEP-0001 there shouldn't be live deployments of Experimental XEPs so there shouldn't be namespace bumps. Draft XEPs should and Final XEPs must not break interoperability, so no chance of a namespace bump there.
Ge0rG
We _normally_ don't bump if it doesn't affect interoperability, but this is not what larma was asking about?
Ge0rG
flow: you implied that. Otherwise, what happens if a namespace is bumped during the CS year?
flow
Ge0rG, larma wrote about "protocol changes". we obviously don't bump for every protocol change
larma
The problem is that we fail to move XEPs to Draft fast enough so that everybody started considering Experimental or even Deferred XEPs as if they were Draft
Zash
larma, isn't that the root problem? Experimental deployed in the wild?
Zash
LC all the XEPs!
flow
Ge0rG, then the compliance suite refers to the current state of the xep
Ge0rG
flow: so you say the CS defines a moving target?
Zash
Should the compliance suite even be allowed to reference Experimental XEPs outside the "future stuff" section?
flow
Zash, or, maybe even better, make XEPs IETF style immutable
Ge0rG
Zash: should we have a process in place that moves Experimental XEPs forward when they are needed?
Zash
flow, I kinda like that, but not enough to rewrite XEP-0001 for it
flow
Ge0rG, XEPs are, to some degree, always a moving target
larma
Ge0rG, IMO CS shouldn't be able to point to Experimental XEPs so that it cannot point to a moving target
larma
*highly moving target
flow
And I don't see the point in pinning XEPs to particular namespace in the compliance suites
Ge0rG
larma: that would stall XEP progress even more
flow
What Ge0rG said
larma
Why?
emushas left
flow
I have the feeling because XEPs have a hard time transitioning from 'experimental' to 'draft'
Ge0rG
larma: developers have hardly the time to implement one version of the most relevant XEPs. How are they supposed to implement multiple versions?
larma
Why should they be required to implement multiple versions just because we move experimental to draft?
Ge0rG
Can we please focus on realistic ideas, given the overall xsf time budget?
kokonoehas joined
Zash
Plz no
flow
Ge0rG, I too, fail to see where the "multiple versions" now comes from
Zash
flow, ns bump transitions?
flow
Zash, yes, but why do developers have to implement multiple namespaces if the compliance suites are not allowed to point to experimental XEPs?
Ge0rG
If we have one version in the CS and then the XEP is bumped, nobody will implement the new one.
Ge0rG
Speaking of time budget, I'm out.
adiaholichas left
Chobbeshas left
adiaholichas joined
Chobbeshas joined
larma
Ge0rG, You mean if there is one version in CS and there is a new Experimental XEP replacing it, it's not going to be widely implemented? Yes that's the whole idea of Experimental XEPs. As soon as it becomes Draft, the (next) CS can point to the new version. No need to implement two versions at the same time.
Chobbeshas left
Ge0rG
larma: and then next year everybody already has implemented the changes, disables the old version and enables the new one at midnight, January 1st?đ
Zash
Flag days?
larma
Ge0rG, well transitions are certainly a problem when breaking backwards compatibility, but that isn't any difference to the current situation. I do agree we should try to not namespace bump as long as possible, a new XEP doesn't imply a new namespace as it can also build on top of an existing XEP.
dwdhas left
dwdhas joined
Ge0rG
larma: just because you call it "new XEP" it doesn't automatically give people the time to implement it and maintain it aside to the old one
Ge0rG
Reality is, some developers will keep multiple versions in parallel, sometimes in different modules with different feature sets. Other will just bump in the least uncomfortable version release
Ge0rG
That would break CS compatibility with pinned namespaces
larma
I don't see the point you want to make here
pep.
âZash> isn't that the root problem? Experimental deployed in the wild?â not put like this but yes. The problem is that we live stuff lingering as experimental. So yes, LC more things
Ge0rG
People wouldn't adopt new versions, meaning that the CS won't be updated in a meaningful way
pep.
âZash> I kinda like that, but not enough to rewrite XEP-0001 for itâ, what's wrong about rewriting 0001?
Zash
pep., thanks for volonteering
pep.
People are afraid of change and that's the one thing I want to stop, it's quite annoying
pep.
Zash, I'm sure I'm not alone
pep.
And can we stop this "blame game", or pushing stuff onto each other game
pep.
I'm sure we can manage to do stuff collectively and not just as one person at a time
pep.
Yes we're all volonteers, so what
Zash
Welcome to volonteer based organizations.
Zash
Getting volonteers to do things is Hard.
pep.
I believe we can do better than pushing stuff onto each other because
larma
Ge0rG, The CS isn't supposed to be "This is what everyone else implements" but "This is what everyone should implement". Thus you can update the CS to the new version even without everyone implementing if you think it should be. You can also say something "you are still CS compliant this year if you implement the old standard, but next year we will probably require the new one". However I wouldn't call a client or server Advanced CS2020 compliant that only implements mam:tmp, it should probably be at least mam:1
winfriedhas left
winfriedhas joined
mathijshas left
mathijshas joined
larma
"This is what everyone should implement" -> "This is what Council suggests everyone should implement"
mathijshas left
mathijshas joined
winfriedhas left
winfriedhas joined
larma
Zash, "Getting volonteers to do things is Hard." especially if they ask to help and receive the answer "it's none of your business"
larma
(not meaning you)
Zash
Is that something someone said here?
larma
It did happen in the past yes.
mathijshas left
mathijshas joined
Zash
pep., FWIW, nothing wrong with rewriting XEP 0001, just not a current priority for me.
pep.
Zash, what I meant by that is, if we have to rewrite 0001, then so be it. I won't be afraid of it
pep.
I'm annoyed by the "thou shalt not change XEP-xxxx" and all the fearmongering around changing things
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
pep.
We cannot go ahead without changing things. XMPP would be dead already if it were not possible to do so. (Some still say it still is, but that's an opinion I'm happy to discard. Lots of changes happened in the previous years and change will come again)
mathijshas left
Ge0rG
pep.: people even dared to change 0045
Zash
pep., just do it!
Kev
Somewhere in the previous 300 messages someone mentioned me. If it's important, drop me a mail please.
mathijshas joined
Shell
XMPP honestly feels like it's been reviving - especially with omemo being supported by more things now.
pep.
I wouldn't especially name OMEMO, but ok :)
Chobbeshas joined
pep.
That definitely played in the acceptance by users
Shell
it's what got my circle using it instead of things like Signal, at least - encrypted group chats combined with being able to pick a client according to individual preferences is a big deal.
winfriedhas left
winfriedhas joined
pep.
I'd like to avoid security discussions right now when we're talking about process
Shell
sorry!
pep.
(Not that I want to prevent you from talking about this, just that this topic is a minefield, and we're already discussing another)
winfriedhas left
winfriedhas joined
pep.
well, we were..
mukt2has joined
Zash
pep., so, where's your board|council application? đ
pep.
I'm procrastinating it. Give me a sec..
mathijshas left
mukt2has left
adiaholichas left
adiaholichas joined
marc_has left
marc_has joined
mathijshas joined
xalekhas joined
debaclehas joined
waqashas left
waqashas joined
waqashas left
waqashas joined
waqashas left
DebXWoodyhas joined
mukt2has joined
winfriedhas left
winfriedhas joined
Douglas Terabytehas joined
dwdhas left
dwdhas joined
winfriedhas left
winfriedhas joined
mukt2has left
winfriedhas left
winfriedhas joined
kokonoehas left
kokonoehas joined
mathijshas left
mathijshas joined
dwdhas left
matlaghas left
matlaghas joined
lskdjfhas left
lskdjfhas joined
winfriedhas left
winfriedhas joined
jubalhhas left
Chobbeshas left
Chobbeshas joined
Chobbeshas left
Zash
Wait really? XEP-0081: Jabber MIME Type https://xmpp.org/extensions/xep-0081.xml
Zash
And https://tools.ietf.org/html/rfc3923#section-10
Zash
I was looking for this very thing the other day
kokonoehas left
Zash
haha what
Zash
https://xmpp.org/extensions/xep-0104.xml
kokonoehas joined
UᚣLhas left
kokonoehas left
kokonoehas joined
winfriedhas left
winfriedhas joined
mukt2has joined
pdurbinhas joined
mukt2has left
marc_has left
pdurbinhas left
Ge0rG
This is shameful
jonasâ
PREFIXED ATTRIBUTES!
jonasâ
there is the precedent I needed!!
flow
hmm the prefix in xep104 seems unnecessary
flow
just like the UTF-8 requirement in rfc3923 § 10
flow
but: yeah, using prefixes /o/ \o\ /o/
Zash
Oh no
flow
although I'd rather use them only when there is no alternative
jonasâ
they can be used to reduce traffic, but (in most cases) not in an RFC-compliant way.
flow
RFC-compliant way?
zachhas left
zachhas joined
Zash
RFC says something about avoiding prefixes?
Zash
https://xmpp.org/rfcs/rfc6120.html#streams-ns-declarations sounds like a relevant heading
Zash
> It is conventional in the XMPP community for implementations to not generate namespace prefixes for elements that are qualified by extended namespaces
https://xmpp.org/rfcs/rfc6120.html#stanzas-extended
Zash
jonasâ: so, we-dont-do-that-here.jpg
Zash
> Routing entities (typically servers) SHOULD try to maintain prefixes when serializing XML stanzas for processing, but receiving entities MUST NOT depend on the prefix strings to have any particular value
E.g. Prosody will likely spit out such things as ns1:foo, ns2:bar etc