rionhttps://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?
rionjonas’: 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
rionjonas’: 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
HolgerSo 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
etaHolger: that's one reason
Steve Killehas joined
HolgerWhich obviously only works for unencrypted MUC. And then you need additional protocol for making that configurable?
etaHolger: it's a bad thing if clients have to implement a bunch of retry logic
etait's mainly about keeping clients in the MUC in the face of disruption
APachhas joined
etaalso, mobile clients can't retry if the phone is in deep sleep
HolgerAbout keeping them? I thought it was about detecting kicks that got unnoticed due to TCP fuckup?
Ge0rGeta: what about having a client register for XEP-0357 on a MUC if it wants to stay inside?
etaHolger: it also handles MUC service restarts
HolgerBy auto-rejoining?
ZashThe MUC model is client-based, so the client doing stuff fits.
Ge0rGand when that specific full JID falls out of the MUC, it will be push-pinged?
etaGe0rG: that requires server support
etaand doesn't work if there's no s2s at the time of the disruption
etas/server/MUC service/
etaHolger: yeah
Ge0rGeta: if there is no s2s, nothing will work
etaand either asking the client to handle MAM, or doing it for the client in some cases
etaGe0rG: well the client's server polling until s2s comes back will :p
etaHolger: 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)
HolgerAs 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.)
etaHolger: well that's why the server also always keeps a resource joined that it controls
HolgerEww.
etaso then a follow up XEP can use that connection to do push things :p
etawhy is that eww?
HolgerWell I should read the spec.
etaHolger: I should write the spec 😉
etaI'll fill out the design considerations section with some rationale
sonnyhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
sonnyhas left
Ge0rGeta: 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
etaGe0rG: there aren't really any protocol changes :)
Ge0rGeta: 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
Ge0rGno more multiple copies of MUC-PMs, all the benefits. Somebody just needs to write it
etaGe0rG: hmm, but multiplexing multiple resources into one sounds more complicated
Ge0rGeta: not so much really
Ge0rGa MUC has to do that for multi-session nicks already
etamore to the point, it somewhat breaks things like transports that do per-resource history
etaand now introduces fun questions about whether the server has to keep a MAM archive
ZashGe0rG: Pretty sure the server could use the bare JID to join.
Ge0rGper-resource history is horrible anyway
Ge0rGZash: maybe, maybe not
etawhy?
Steve Killehas left
Ge0rGeta: so many reasons, I can't even start.
ZashThat's what that experimental "minimix" thing does and I'm pretty sure it didn't break everything
Ge0rGThere was a bunch of issues on the biboumi tracker related to that
etaGe0rG: I mean, that's one way you could implement this XEP, btw
Steve Killehas joined
etalike I don't think the client has to care about whether it's one resource or multiple on the server side
etawe can add that in as a "Servers MAY choose to only join one resource" or something
etaI'm just worried doing it that way would break assumptions in existing software
Ge0rGI'm not following
etathe XEP doesn't mandate you actually join each resource
etaI mean, from the client's perspective it should appear that way
sonnyhas joined
etabut you're free to multiplex everything into the barejid and just join that if you like
ZashGets 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.
etaGe0rG: (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
Alexdoes the XSF website deploy automatically over CD after PRs or are there additional steps required?
ZashMay 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
HolgerGe0rG, 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).
etaHolger: the main issue I have with that sort of solution is it requires MUC services to upgrade
Holgereta, and you think having user servers upgrade to a version that implements an absolutely non-trivial pile of hacks is easier?
etaHolger: define "non-trivial pile of hacks"
etaI don't think my proposal is that terrible
HolgerAre user servers somehow easier to upgrade than MUC servers?
etaHolger: well, your ideas also would require clients to upgrade
HolgerMy 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.
etabackwards compat is important
etaMIX is grand, but it'll be a long time before everyone is using it
etaand using it requires effort on behalf of all servers and clients
HolgerAFAICS the Tigase solution requires an absolutely trivial upgrade to "subscribe" with the MUC. One could probably even go without that.
HolgerBackwards compat is important but we don't break it at all by introducing optional improvements.
etaHolger: from the user's perspective though, now they have some MUCs where push works and some MUCs where it doesn't
HolgerEverything that works today will work tomorrow with my suggestions.
etaHolger: sure; my point is, with my suggestions, everything that works today will work better tomorrow, transparently
etaHolger: I don't disagree with you about MUC being less than ideal :)
etabut the pace of XMPP development is slow enough as is
HolgerRight, that's not our disagreement. We disagree on how to tackle that problem.
KevOften because we worry too much about compatibility with broken systems ;)
Kevgoes back to lurking
etaHolger: we've had MIX / mucsub / etc for a while now though
etaand if they'd gained traction, we wouldn't be having this conversation
etaperhaps 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
HolgerMUC/Sub & friends are non-standard extensions of vendors for their customers.
HolgerI totally agree on backwards compat being essential.
etaHolger, well hang on, let's look at this from another angle, actually
etaI actually don't think we're in disagreement at all
etabecause you can have both a pile of hacks for old hacky stuff and a cleaner way to do things for non legacy MUC services
HolgerI just disagree on the idea of implementing a pile of hacks to bring new functionality to clients transparently.
etaah
HolgerSo I disagree on that we're even talking about a backwards compat issue.
Andrzejhas left
etawell what about that idea do you dislike?
etais it the pile of hacks part, or the transparent part?
HolgerThe hack part. I'm obviously all for improving things transparently if it can be done in a clean way.
winfriedhas left
winfriedhas joined
etahm
sonnyhas left
etathe issue is, hacks are kinda required to deal with legacy services
etaI 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")
etabut 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)
etaI guess you could split the XEP and make the hacky part optional? (at the cost of negating a lot of the benefits)
HolgerI’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
HolgerWhat Ge0rG and you outlined did sound way more complex than just poll-pinging and auto-rejoining.
HolgerMaybe.
etaHolger, I mean I'm really not a fan of the whole join-using-only-one-resource thing
serge90has left
serge90has joined
etait'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
Ge0rGHolger: there are so many trade-offs here!
sonnyhas left
etahow do you reference another section of an XEP
eta(cc jonas’ as resident XEP XML expert)
jonas’eta, of the same XEP?
etajonas’, yeah
Ge0rGeta: <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>
etathanks!
marchas left
marchas joined
stpeterhas joined
stpeterhas left
lorddavidiiihas left
etacan 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)
etajonas’, 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
etathis 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
etamaybe 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
etajonas’, 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
Ge0rGjonas’: it would be great to have a bunch of styling examples in xep-template.xml, like boxes and stuff
jonas’Ge0rG, go ahead
Ge0rGbut I'm the one who always struggles to find the right elements!
sonnyhas left
lorddavidiiihas joined
Ge0rGthere 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.
Ge0rGyou can have <code> in <li> but not in <p>?!
jonas’yes
Ge0rGAlso <code> is not what I expected.
Ge0rGbut what's <dl>?
jonas’a definition list
sonnyhas joined
Ge0rGcool
sonnyhas left
vanitasvitaei stumbled across p being not allowed as child of li recently as well
vanitasvitaei stumbled across p not being allowed as child of li recently as well
Ge0rGjonas’: <cite> isn't being rendered in bold any more
Ge0rGnowait, it's my local copy only.
sonnyhas joined
Ge0rGTIL 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
Ge0rGOUTRAGE!
MattJIt 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
mdoscheta: Also you doubled 'to send'
etamdosch, oh, oops
etanice catch
mdoschI 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
Wojteketa, 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?
Wojtekone 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
etaWojtek, my stance isn't "let's patch MUC instead of doing MIX", it's "let's patch MUC *and* do MIX"
etaa 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
etait'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
Ge0rGthere are also valuable lessons for MIX to be learned from making MUC reliable.
Steve Killehas joined
Wojtekdoing tho things strains our resources
Wojtek@Ge0rG true that
etaWojtek, I mean writing this specification mostly strains my resources, and I wasn't going to do anything else anyway :P
Wojtekthe biggest issue here are "MAM holes"
rionhas joined
etaand 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
etaespecially 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
etaWojtek, also, doing durable MUC doesn't really strain client developers at all
neshtaxmpphas left
etathey have to implement like one thing (and they don't really even need to do that, if they don't want to)
etaand AFAICT the main blockers seem to be on the client side, in terms of evolving XMPP
Andrzejeta, I suppose not for long as I'm aware of 2-3 groups working on MIX right now (client side)
WojtekI 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
Wojtekon the other hand doing that in MUC semantics requires more logic on user's server to correctly maintain user's session
etaAndrzej, oh? which? (that's pretty cool)
AndrzejI 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
etaoh 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
winfriedHas anybody an idea how well ecdsa signed certificates are supported for s2s communication? Would saying RSA /or/ ECDSA result in any interoperability issues?
moparisthebestif the web is anything to go by, I don't think anyone is doing ecdsa-only nowadays, some run both though
moparisthebestwinfried, 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
moparisthebestof 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 :)
winfriedmoparisthebest: well, it should become part of a security norm, so 10y legacy should not be a major argument...
adiaholic_has left
adiaholic_has joined
moparisthebestshould it? I thought there were numerous problems with ECDSA and in general people were waiting for CA approval of ED25519 certs?
moparisthebestshould 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
moparisthebestwinfried, best summary I can find I guess https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868