https://github.com/xsf/xeps/pull/905 can council review this wrt stpeter comment?
Andrzejhas left
jonas’
rion, sorry, I missed this
jonas’
after stpeters approval, this is just a matter of Editors, since this spec is still Experimental/Deferred
jonas’
rion, can you ping me (@horazont) in the PR so that I get an explicit email from it?
rion
jonas’: done
jonas’
thank you
jonas’
rion, can you also update the revision block with a more recent date to reduce confusion?
jonas’
(please do so by amending the commit, do not create a new commit changing the date, otherwise I’ll have to rewrite that)
emushas joined
neshtaxmpphas joined
marchas joined
esilhas joined
esilhas left
sonnyhas left
sonnyhas joined
rion
jonas’: force-pushed
sonnyhas left
marchas left
sonnyhas joined
jonas’
<3
debaclehas joined
Andrzejhas joined
karoshihas left
karoshihas joined
Andrzejhas left
Andrzejhas joined
Vaulorhas joined
marc0shas left
marc0shas joined
mukt2has left
sonnyhas left
papatutuwawahas left
APachhas left
mukt2has joined
Dele Olajidehas joined
debaclehas left
sonnyhas joined
Andrzejhas left
Andrzejhas joined
Andrzejhas left
krauqhas left
krauqhas joined
sonnyhas left
mukt2has left
mukt2has joined
sonnyhas joined
Andrzejhas joined
lovetoxhas left
debaclehas joined
mukt2has left
lovetoxhas joined
sonnyhas left
krauqhas left
krauqhas joined
marchas joined
Holger
So the reason to have the server do all this ping and MAM dance rather than just having the client ping the MUC is filtering push notifications based on nick mentions?
Steve Killehas left
eta
Holger: that's one reason
Steve Killehas joined
Holger
Which obviously only works for unencrypted MUC. And then you need additional protocol for making that configurable?
eta
Holger: it's a bad thing if clients have to implement a bunch of retry logic
eta
the XEP I'm writing doesn't actually address push
eta
it's mainly about keeping clients in the MUC in the face of disruption
APachhas joined
eta
also, mobile clients can't retry if the phone is in deep sleep
Holger
About keeping them? I thought it was about detecting kicks that got unnoticed due to TCP fuckup?
Ge0rG
eta: what about having a client register for XEP-0357 on a MUC if it wants to stay inside?
eta
Holger: it also handles MUC service restarts
Holger
By auto-rejoining?
Zash
The MUC model is client-based, so the client doing stuff fits.
Ge0rG
and when that specific full JID falls out of the MUC, it will be push-pinged?
eta
Ge0rG: that requires server support
eta
and doesn't work if there's no s2s at the time of the disruption
eta
s/server/MUC service/
eta
Holger: yeah
Ge0rG
eta: if there is no s2s, nothing will work
eta
and either asking the client to handle MAM, or doing it for the client in some cases
eta
Ge0rG: well the client's server polling until s2s comes back will :p
eta
Holger: basically the client can just join a MUC and never get kicked out, if this spec is implemented
eta
(well, unless the server gives up after an extended period)
Holger
As long as the 0198 session is alive, you mean. (Which can't be kept alive if the mobile client cannot be push-woken out of its deep sleep.)
eta
Holger: well that's why the server also always keeps a resource joined that it controls
Holger
Eww.
eta
so then a follow up XEP can use that connection to do push things :p
eta
why is that eww?
Holger
Well I should read the spec.
eta
Holger: I should write the spec 😉
eta
I'll fill out the design considerations section with some rationale
sonnyhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
sonnyhas left
Ge0rG
eta: a user's server could act as a XEP-0045 bouncer without any protocol changes; it just needs to define how joined channels are maintained, e.g. by using the bookmark autojoin flag
eta
Ge0rG: there aren't really any protocol changes :)
Ge0rG
eta: so the user's server would join all the user's MUCs under a specailly crafted resource, and keep track of which clients join/leave the MUC
Ge0rG
no more multiple copies of MUC-PMs, all the benefits. Somebody just needs to write it
eta
Ge0rG: hmm, but multiplexing multiple resources into one sounds more complicated
Ge0rG
eta: not so much really
Ge0rG
a MUC has to do that for multi-session nicks already
eta
more to the point, it somewhat breaks things like transports that do per-resource history
eta
and now introduces fun questions about whether the server has to keep a MAM archive
Zash
Ge0rG: Pretty sure the server could use the bare JID to join.
Ge0rG
per-resource history is horrible anyway
Ge0rG
Zash: maybe, maybe not
eta
why?
Steve Killehas left
Ge0rG
eta: so many reasons, I can't even start.
Zash
That's what that experimental "minimix" thing does and I'm pretty sure it didn't break everything
Ge0rG
There was a bunch of issues on the biboumi tracker related to that
eta
Ge0rG: I mean, that's one way you could implement this XEP, btw
Steve Killehas joined
eta
like I don't think the client has to care about whether it's one resource or multiple on the server side
eta
we can add that in as a "Servers MAY choose to only join one resource" or something
eta
I'm just worried doing it that way would break assumptions in existing software
Ge0rG
I'm not following
eta
the XEP doesn't mandate you actually join each resource
eta
I mean, from the client's perspective it should appear that way
sonnyhas joined
eta
but you're free to multiplex everything into the barejid and just join that if you like
Zash
Gets easier to distinguish server-based things if the bare JID is used, but yeah there might be some "there's always a resource" assumption in some MUC implementation.
eta
Ge0rG: (that being said, I was originally going to stipulate each resource be joined, so thanks for the suggestion)
sonnyhas left
matkorhas left
matkorhas joined
sonnyhas joined
karoshihas left
karoshihas joined
sonnyhas left
Alex
does the XSF website deploy automatically over CD after PRs or are there additional steps required?
Zash
May require a swift kick in the Docker by iteam, unless it's been automated without me noticing (possible)
sonnyhas joined
thorstenhas joined
Andrzejhas left
Rixon 👁🗨has left
Half-Shothas left
uhoreghas left
uhoreghas joined
Half-Shothas joined
Rixon 👁🗨has joined
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
Holger
Ge0rG, eta, sorry but to me all this sounds like throwing another non-trivial pile of terrible hacks on top of MUC just to try to work around MUCs presence-basedness by pretending the client is present while its not. I think this would just open up a new can of worms to keep us busy.
To me it makes way more sense to try to get rid of the presence-basedness rather than working around it. E.g. by doing 0357 on the MUC JID; or if you want to leave push to the user's server, by going for Tigase' solution of having the MUC send groupchat messages to the bare JID of offline members, so the user server can push-notify (which seems the most straightforward variant of MUC-Lite and MUC/Sub and whatnot to me).
eta
Holger: the main issue I have with that sort of solution is it requires MUC services to upgrade
Holger
eta, and you think having user servers upgrade to a version that implements an absolutely non-trivial pile of hacks is easier?
eta
Holger: define "non-trivial pile of hacks"
eta
I don't think my proposal is that terrible
Holger
Are user servers somehow easier to upgrade than MUC servers?
eta
Holger: well, your ideas also would require clients to upgrade
Holger
My other suggestion would be to spend our limited time on MIX rather than on poll-pinging MUCs, playing presence games, having servers perform MAM queries and whatnot.
eta
backwards compat is important
eta
MIX is grand, but it'll be a long time before everyone is using it
eta
and using it requires effort on behalf of all servers and clients
Holger
AFAICS the Tigase solution requires an absolutely trivial upgrade to "subscribe" with the MUC. One could probably even go without that.
Holger
Backwards compat is important but we don't break it at all by introducing optional improvements.
eta
Holger: from the user's perspective though, now they have some MUCs where push works and some MUCs where it doesn't
Holger
Everything that works today will work tomorrow with my suggestions.
eta
Holger: sure; my point is, with my suggestions, everything that works today will work better tomorrow, transparently
eta
Holger: I don't disagree with you about MUC being less than ideal :)
eta
but the pace of XMPP development is slow enough as is
Holger
Right, that's not our disagreement. We disagree on how to tackle that problem.
Kev
Often because we worry too much about compatibility with broken systems ;)
Kevgoes back to lurking
eta
Holger: we've had MIX / mucsub / etc for a while now though
eta
and if they'd gained traction, we wouldn't be having this conversation
eta
perhaps this is because the last chat system I tried to use was IRC, but I think there's significant value in having older clients work without requiring them to change anything
Holger
MUC/Sub & friends are non-standard extensions of vendors for their customers.
Holger
I totally agree on backwards compat being essential.
eta
Holger, well hang on, let's look at this from another angle, actually
eta
I actually don't think we're in disagreement at all
eta
because you can have both a pile of hacks for old hacky stuff and a cleaner way to do things for non legacy MUC services
Holger
I just disagree on the idea of implementing a pile of hacks to bring new functionality to clients transparently.
eta
ah
Holger
So I disagree on that we're even talking about a backwards compat issue.
Andrzejhas left
eta
well what about that idea do you dislike?
eta
is it the pile of hacks part, or the transparent part?
Holger
The hack part. I'm obviously all for improving things transparently if it can be done in a clean way.
winfriedhas left
winfriedhas joined
eta
hm
sonnyhas left
eta
the issue is, hacks are kinda required to deal with legacy services
eta
I mean what I've written already makes some provision for doing mucsub-esque things (along the lines of "keep a list of MUC participants, and notify their servers if they drop out for whatever reason")
eta
but then you don't get the benefit if the MUC doesn't upgrade
sonnyhas joined
eta
(I also don't think auto-rejoining is thaaat hacky :p)
eta
I guess you could split the XEP and make the hacky part optional? (at the cost of negating a lot of the benefits)
Holger
I’ve implemented tons of horrible hacks for backwards compat myself. But I’m not keen on implementing hacks to get new improvements just to avoid the requirement for the MUC service to be updated.
sonnyhas left
Holger
What Ge0rG and you outlined did sound way more complex than just poll-pinging and auto-rejoining.
Holger
Maybe.
eta
Holger, I mean I'm really not a fan of the whole join-using-only-one-resource thing
serge90has left
serge90has joined
eta
it's just one way to implement it, right
papatutuwawahas joined
sonnyhas joined
Andrzejhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
Andrzejhas left
sonnyhas joined
mdoschhas left
mdoschhas joined
Andrzejhas joined
Ge0rG
Holger: there are so many trade-offs here!
sonnyhas left
eta
how do you reference another section of an XEP
eta
(cc jonas’ as resident XEP XML expert)
jonas’
eta, of the same XEP?
eta
jonas’, yeah
Ge0rG
eta: <link url='#lists'>
jonas’
you need to put an anchor='some-unique-and-urlsafe-string' on the <sectionX/> and then you can <link url='#some-unique-and-urlsafe-string'>...</link>
eta
thanks!
marchas left
marchas joined
stpeterhas joined
stpeterhas left
lorddavidiiihas left
eta
can one say "This section is non-normative" in XEPs, or is that generally avoided?
jonas’
eta, what would you put there?
jonas’
(the schema is, for example, generally non-normative)
eta
jonas’, I'm describing how the way the XEP is written provides backwards compatibility
Andrzejhas left
jonas’
that’d be good for a Design Considerations section I pioneered in e.g. XEP-0392
eta
this part isn't really normative; I've already described that, for example, you MUST implement the compat mechanisms in XEP-0402
jonas’
go ahead please
eta
maybe I should use one of those inset box things
jonas’
eta, if it’s a longer explanation, please put it in a separate section
jonas’
eta, https://xmpp.org/extensions/xep-0392.html#design like here
eta
jonas’, it isn't really, it's more of a "just to be clear, this legacy mechanism is also expected to work, but I've already said that"
sonnyhas joined
jonas’
I think that falls in that section, too
Ge0rG
jonas’: it would be great to have a bunch of styling examples in xep-template.xml, like boxes and stuff
jonas’
Ge0rG, go ahead
Ge0rG
but I'm the one who always struggles to find the right elements!
sonnyhas left
lorddavidiiihas joined
Ge0rG
there are thirteen sections in the template and none does quite fit
amuza@riseup.nethas joined
Andrzejhas joined
lorddavidiiihas left
Ge0rG
> xep-template.xml:82: element p: validity error : Element code is not declared in p list of possible children
When your example accidentally becomes a unit test.
Ge0rG
you can have <code> in <li> but not in <p>?!
jonas’
yes
Ge0rG
Also <code> is not what I expected.
Ge0rG
but what's <dl>?
jonas’
a definition list
sonnyhas joined
Ge0rG
cool
sonnyhas left
vanitasvitae
i stumbled across p being not allowed as child of li recently as well✎
vanitasvitae
i stumbled across p not being allowed as child of li recently as well ✏
Ge0rG
jonas’: <cite> isn't being rendered in bold any more
Ge0rG
nowait, it's my local copy only.
sonnyhas joined
Ge0rG
TIL that some of the XEPs contain images as embedded data:image/png;base64
lorddavidiiihas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
Andrzejhas left
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
karoshihas left
karoshihas joined
Yagizahas left
mukt2has joined
mdoschhas left
mdoschhas joined
sonnyhas joined
adiaholic_has left
adiaholic_has joined
sonnyhas left
mukt2has left
sonnyhas joined
moparisthebesthas joined
krauqhas left
krauqhas joined
Andrzejhas left
Andrzejhas joined
Mikaelahas left
Mikaelahas joined
sonnyhas left
sonnyhas joined
etamade a funny typo: "If clients attempt to send to send presence to a MUC experiencing an outrage condition, ..."
sonnyhas left
Ge0rG
OUTRAGE!
MattJ
It should be possible to filter by such conditions on search.jabber.network
sonnyhas joined
sonnyhas left
rionhas left
Andrzejhas left
karoshihas left
winfriedhas left
winfriedhas joined
lovetoxhas left
karoshihas joined
karoshihas left
Andrzejhas joined
lovetoxhas joined
sonnyhas joined
bearhas joined
karoshihas joined
neshtaxmpphas left
sonnyhas left
sonnyhas joined
stpeterhas joined
stpeterhas left
sonnyhas left
mdoschhas left
mdoschhas joined
Andrzejhas left
karoshihas left
karoshihas joined
mdosch
eta: Also you doubled 'to send'
eta
mdosch, oh, oops
eta
nice catch
mdosch
I got stuck there first and wondered why that typo is funny. 😄
lovetoxhas left
bearhas left
Andrzejhas joined
mdoschhas left
!XSF_Martinhas left
!XSF_Martinhas joined
Mikaelahas left
mdoschhas joined
neshtaxmpphas joined
sonnyhas joined
mdoschhas left
jonas’
the duplication was on a linebreak for me so I did not notice it :D
alameyohas left
alameyohas joined
mdoschhas joined
Danielhas left
sonnyhas left
Danielhas joined
sonnyhas joined
APachhas left
APachhas joined
sonnyhas left
Andrzejhas left
APachhas left
APachhas joined
Andrzejhas joined
mdoschhas left
lorddavidiiihas left
karoshihas left
bearhas joined
mdoschhas joined
Wojtekhas joined
sonnyhas joined
sonnyhas left
sonnyhas joined
krauqhas left
krauqhas joined
sonnyhas left
Andrzejhas left
krauqhas left
krauqhas joined
Andrzejhas joined
Nekithas left
sonnyhas joined
mdoschhas left
mdoschhas joined
sonnyhas left
Rixon 👁🗨has left
Half-Shothas left
uhoreghas left
stpeterhas joined
uhoreghas joined
Half-Shothas joined
Rixon 👁🗨has joined
stpeterhas left
sonnyhas joined
Wojtekhas left
Wojtekhas joined
karoshihas joined
APachhas left
papatutuwawahas left
lovetoxhas joined
Shellhas left
bearhas left
bearhas joined
Shellhas joined
Wojtek
eta, I was just pondering your stance (let's patch MUC instead of doing MIX) a bit and... wouldn't you say that favouring patching actually adds to the relative slow evolution of XMPP? If there is no need to move to the next thing then there is less motivation. What's more - with said Conv.Compat tester there is quite significant push for server operators to upgrade - with introduction of ext component with turn/stun the deployment reached 50% of tested servers in roughly 3 months (and then reached plateau) - whad makes you think that with MIX it wouldn't be the same?
Wojtek
one thing to consider is also migration path - there was a MUC room and then there is a MIX room - it would be nice to have some way to convert those (with members and history maybe?) and inform the user that addresses changed
Steve Killehas left
thorstenhas left
APachhas joined
eta
Wojtek, my stance isn't "let's patch MUC instead of doing MIX", it's "let's patch MUC *and* do MIX"
eta
a reliable way of joining and staying in a MUC room is required, no matter whether clients use MUC or MIX, because there will always be old MUC rooms / transports people want to use
eta
it'd be entirely possible to use the backend parts of my proposal and stick a MIX frontend on them, and make a MIX-to-MUC bridge
lovetoxhas left
Ge0rG
there are also valuable lessons for MIX to be learned from making MUC reliable.
Steve Killehas joined
Wojtek
doing tho things strains our resources
Wojtek
@Ge0rG true that
eta
Wojtek, I mean writing this specification mostly strains my resources, and I wasn't going to do anything else anyway :P
Wojtek
the biggest issue here are "MAM holes"
rionhas joined
eta
and yeah, I agree spreading our effort across 2 things isn't great, but on the other hand joining old MUC rooms is kinda needed
winfriedhas left
winfriedhas joined
eta
especially if MIX has semantics where the client only has to join once and stays in, you'll need something like my specification to actually implement that in a MIX-to-MUC bridge
Rixon 👁🗨has left
Half-Shothas left
uhoreghas left
uhoreghas joined
Half-Shothas joined
Rixon 👁🗨has joined
eta
Wojtek, also, doing durable MUC doesn't really strain client developers at all
neshtaxmpphas left
eta
they have to implement like one thing (and they don't really even need to do that, if they don't want to)
eta
and AFAICT the main blockers seem to be on the client side, in terms of evolving XMPP
Andrzej
eta, I suppose not for long as I'm aware of 2-3 groups working on MIX right now (client side)
Wojtek
I kinda agree, but in case of MIX in MIX-PAM user's server, upon receiving stanza which references previous stanza-id that doesn't exist locally could query the MIX server for missing messages (it's not specified now but that was the idea at last summit). And this could actually be extended on whole MAM it seems
Wojtek
on the other hand doing that in MUC semantics requires more logic on user's server to correctly maintain user's session
eta
Andrzej, oh? which? (that's pretty cool)
Andrzej
I know that there was (is?) a branch of Conversations which had some support for MIX (if I recall correctly), we at Tigase are working on iOS,Android and macOS clients with MIX and if I'm correct Kaidan is working on MIX as well
eta
oh right, yeah, I forgot about those other 2
neshtaxmpphas joined
Lancehas left
krauqhas left
mimi89999has left
krauqhas joined
Mikaelahas joined
bearhas left
mdoschhas left
mdoschhas joined
papatutuwawahas joined
winfried
Has anybody an idea how well ecdsa signed certificates are supported for s2s communication? Would saying RSA /or/ ECDSA result in any interoperability issues?
moparisthebest
if the web is anything to go by, I don't think anyone is doing ecdsa-only nowadays, some run both though
moparisthebest
winfried, as far as "would ECDSA result in interop issues" the answer is absolutely yes, we *just* had a server break s2s with xmpp.org with a DH key > 1024 which was widely fixed in 2007 when xmpp.org upgraded in 2020
lovetoxhas joined
neshtaxmpphas left
moparisthebest
of course I'd argue if you haven't upgraded your server in the last 10 years who cares if your s2s works but others have different opinions :)
winfried
moparisthebest: well, it should become part of a security norm, so 10y legacy should not be a major argument...
adiaholic_has left
adiaholic_has joined
moparisthebest
should it? I thought there were numerous problems with ECDSA and in general people were waiting for CA approval of ED25519 certs?✎
moparisthebest
should it? I thought there were numerous problems with ECDSA and in general people were waiting for CAB approval of ED25519 certs? ✏
mdoschhas left
mdoschhas joined
mdoschhas left
Lancehas joined
mdoschhas joined
mdoschhas left
vanitasvitaehas left
esilhas joined
esilhas left
vanitasvitaehas joined
sonnyhas left
sonnyhas joined
sonnyhas left
vanitasvitaehas left
vanitasvitaehas joined
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
krauqhas left
krauqhas joined
eevvoorhas left
moparisthebest
winfried, best summary I can find I guess https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868