XSF Discussion - 2020-08-26

https://github.com/xsf/xeps/pull/905 can council review this wrt stpeter comment?

rion, sorry, I missed this

after stpeters approval, this is just a matter of Editors, since this spec is still Experimental/Deferred

rion, can you ping me (@horazont) in the PR so that I get an explicit email from it?

jonas’: done

thank you

rion, can you also update the revision block with a more recent date to reduce confusion?

(please do so by amending the commit, do not create a new commit changing the date, otherwise I’ll have to rewrite that)

jonas’: force-pushed

<3

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?

Holger: that's one reason

Which obviously only works for unencrypted MUC. And then you need additional protocol for making that configurable?

Holger: it's a bad thing if clients have to implement a bunch of retry logic

the XEP I'm writing doesn't actually address push

it's mainly about keeping clients in the MUC in the face of disruption

also, mobile clients can't retry if the phone is in deep sleep

About keeping them? I thought it was about detecting kicks that got unnoticed due to TCP fuckup?

eta: what about having a client register for XEP-0357 on a MUC if it wants to stay inside?

Holger: it also handles MUC service restarts

By auto-rejoining?

The MUC model is client-based, so the client doing stuff fits.

and when that specific full JID falls out of the MUC, it will be push-pinged?

Ge0rG: that requires server support

and doesn't work if there's no s2s at the time of the disruption

s/server/MUC service/

Holger: yeah

eta: if there is no s2s, nothing will work

and either asking the client to handle MAM, or doing it for the client in some cases

Ge0rG: well the client's server polling until s2s comes back will :p

Holger: basically the client can just join a MUC and never get kicked out, if this spec is implemented

(well, unless the server gives up after an extended period)

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.)

Holger: well that's why the server also always keeps a resource joined that it controls

Eww.

so then a follow up XEP can use that connection to do push things :p

why is that eww?

Well I should read the spec.

Holger: I should write the spec 😉

I'll fill out the design considerations section with some rationale

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

Ge0rG: there aren't really any protocol changes :)

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

no more multiple copies of MUC-PMs, all the benefits. Somebody just needs to write it

Ge0rG: hmm, but multiplexing multiple resources into one sounds more complicated

eta: not so much really

a MUC has to do that for multi-session nicks already

more to the point, it somewhat breaks things like transports that do per-resource history

and now introduces fun questions about whether the server has to keep a MAM archive

Ge0rG: Pretty sure the server could use the bare JID to join.

per-resource history is horrible anyway

Zash: maybe, maybe not

why?

eta: so many reasons, I can't even start.

That's what that experimental "minimix" thing does and I'm pretty sure it didn't break everything

There was a bunch of issues on the biboumi tracker related to that

Ge0rG: I mean, that's one way you could implement this XEP, btw

like I don't think the client has to care about whether it's one resource or multiple on the server side

we can add that in as a "Servers MAY choose to only join one resource" or something

I'm just worried doing it that way would break assumptions in existing software

I'm not following

the XEP doesn't mandate you actually join each resource

I mean, from the client's perspective it should appear that way

but you're free to multiplex everything into the barejid and just join that if you like

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.

Ge0rG: (that being said, I was originally going to stipulate each resource be joined, so thanks for the suggestion)

does the XSF website deploy automatically over CD after PRs or are there additional steps required?

May require a swift kick in the Docker by iteam, unless it's been automated without me noticing (possible)

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).

Holger: the main issue I have with that sort of solution is it requires MUC services to upgrade

eta, and you think having user servers upgrade to a version that implements an absolutely non-trivial pile of hacks is easier?

Holger: define "non-trivial pile of hacks"

I don't think my proposal is that terrible

Are user servers somehow easier to upgrade than MUC servers?

Holger: well, your ideas also would require clients to upgrade

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.

backwards compat is important

MIX is grand, but it'll be a long time before everyone is using it

and using it requires effort on behalf of all servers and clients

AFAICS the Tigase solution requires an absolutely trivial upgrade to "subscribe" with the MUC. One could probably even go without that.

Backwards compat is important but we don't break it at all by introducing optional improvements.

Holger: from the user's perspective though, now they have some MUCs where push works and some MUCs where it doesn't

Everything that works today will work tomorrow with my suggestions.

Holger: sure; my point is, with my suggestions, everything that works today will work better tomorrow, transparently

Holger: I don't disagree with you about MUC being less than ideal :)

but the pace of XMPP development is slow enough as is

Right, that's not our disagreement. We disagree on how to tackle that problem.

Often because we worry too much about compatibility with broken systems ;)

Holger: we've had MIX / mucsub / etc for a while now though

and if they'd gained traction, we wouldn't be having this conversation

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

MUC/Sub & friends are non-standard extensions of vendors for their customers.

I totally agree on backwards compat being essential.

Holger, well hang on, let's look at this from another angle, actually

I actually don't think we're in disagreement at all

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

I just disagree on the idea of implementing a pile of hacks to bring new functionality to clients transparently.

ah

So I disagree on that we're even talking about a backwards compat issue.

well what about that idea do you dislike?

is it the pile of hacks part, or the transparent part?

The hack part. I'm obviously all for improving things transparently if it can be done in a clean way.

hm

the issue is, hacks are kinda required to deal with legacy services

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")

but then you don't get the benefit if the MUC doesn't upgrade

(I also don't think auto-rejoining is thaaat hacky :p)

I guess you could split the XEP and make the hacky part optional? (at the cost of negating a lot of the benefits)

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.

What Ge0rG and you outlined did sound way more complex than just poll-pinging and auto-rejoining.

Maybe.

Holger, I mean I'm really not a fan of the whole join-using-only-one-resource thing

it's just one way to implement it, right

Holger: there are so many trade-offs here!

how do you reference another section of an XEP

(cc jonas’ as resident XEP XML expert)

eta, of the same XEP?

jonas’, yeah

eta: <link url='#lists'>

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>

thanks!

can one say "This section is non-normative" in XEPs, or is that generally avoided?

eta, what would you put there?

(the schema is, for example, generally non-normative)

jonas’, I'm describing how the way the XEP is written provides backwards compatibility

that’d be good for a Design Considerations section I pioneered in e.g. XEP-0392

this part isn't really normative; I've already described that, for example, you MUST implement the compat mechanisms in XEP-0402

go ahead please

maybe I should use one of those inset box things

eta, if it’s a longer explanation, please put it in a separate section

eta, https://xmpp.org/extensions/xep-0392.html#design like here

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"

I think that falls in that section, too

jonas’: it would be great to have a bunch of styling examples in xep-template.xml, like boxes and stuff

Ge0rG, go ahead

but I'm the one who always struggles to find the right elements!

there are thirteen sections in the template and none does quite fit

> 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.

you can have <code> in <li> but not in <p>?!

yes

Also <code> is not what I expected.

but what's <dl>?

a definition list

cool

i stumbled across p not being allowed as child of li recently as well ✏

jonas’: <cite> isn't being rendered in bold any more

nowait, it's my local copy only.

TIL that some of the XEPs contain images as embedded data:image/png;base64

OUTRAGE!

It should be possible to filter by such conditions on search.jabber.network

eta: Also you doubled 'to send'

mdosch, oh, oops

nice catch

I got stuck there first and wondered why that typo is funny. 😄

the duplication was on a linebreak for me so I did not notice it :D

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?

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

Wojtek, my stance isn't "let's patch MUC instead of doing MIX", it's "let's patch MUC *and* do MIX"

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

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

there are also valuable lessons for MIX to be learned from making MUC reliable.

doing tho things strains our resources

@Ge0rG true that

Wojtek, I mean writing this specification mostly strains my resources, and I wasn't going to do anything else anyway :P

the biggest issue here are "MAM holes"

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

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

Wojtek, also, doing durable MUC doesn't really strain client developers at all

they have to implement like one thing (and they don't really even need to do that, if they don't want to)

and AFAICT the main blockers seem to be on the client side, in terms of evolving XMPP

eta, I suppose not for long as I'm aware of 2-3 groups working on MIX right now (client side)

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

on the other hand doing that in MUC semantics requires more logic on user's server to correctly maintain user's session

Andrzej, oh? which? (that's pretty cool)

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

oh right, yeah, I forgot about those other 2

Has anybody an idea how well ecdsa signed certificates are supported for s2s communication? Would saying RSA /or/ ECDSA result in any interoperability issues?

if the web is anything to go by, I don't think anyone is doing ecdsa-only nowadays, some run both though

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

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 :)

moparisthebest: well, it should become part of a security norm, so 10y legacy should not be a major argument...

should it? I thought there were numerous problems with ECDSA and in general people were waiting for CAB approval of ED25519 certs? ✏

winfried, best summary I can find I guess https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868

moparisthebest: thanks