XSF Discussion - 2019-04-17

rion, did you consider writing to standards@ and probably the xep authors in CC about the stuff you wrote regarding xep260 in the wiki? I am also interested about the rationale behind proxy-error. Unfortunately this appears to be another example where a XEP tells you what to do, but not why…

flow: Hi. maybe in the evening. Working for now.

btw at work I do some modifications in Janus server for our customer. and in its signaling has a special attribute for final local candidate. That's what missed in Jingle S5B

Ge0rG are you slowly turining 0060 into MIX 😱

edhelas: I'm not touching 0060 with a pole.

There was a place in the RFCs that say thou shalt not add yourself to the roster, right? I can't find it

CCC is demanding freedom for Assange, Manning and Bini: https://www.ccc.de/de/updates/2019/chaos-computer-club-besorgt-uber-aktuelle-angriffe-auf-die-pressefreiheit

(Link in German)

they are preparing a nice conference for the 36c3 :p

vanitasvitae, Freeing Assange? Why?

Ge0rG: Do you think you'll find time to look at the 45 anti-gc changes or should I just post it to xsf/xeps ?

Zash: I don't know, sorry. Is it done yet?

https://github.com/Zash/xeps/commit/7dcee765750f78de31763444df4c3a9640c73809

Question is whether that's enough or if there are more references to GC10 lurking somewhere

Mostly that just moves the GC1.0 part so that it's not the first thing you see when you go to the "joining a room" section.

Zash, Make it a PR, and mention it on standards@. As good a way to get feedback as any.

Zash: moving is not the same as deleting, right?

> Compliant multi-user chat services MUST accept [GC 1.0] ... https://xmpp.org/extensions/xep-0045.html#enter-muc

dwd: first of all freeing bini.

vanitasvitae, I'd argue Ecuador should either charge him or release him. As for Assange, he skipped bail. I'm hoping Sweden put in an extradition claim, as that would take precedence over the US claim, but simply freeing Assange would break UK law quite clearly.

I'm also hoping that Sweden puts in an extradition claim. I don't want to resolve the questions of the claims the US is making :/

It is interesting how being locked into a building for seven years doesn't count as a jail sentence.

I thought Sweden did so already

Because journalists there seem really dumb about it and don't understand that throwing him under the bus could also affect them

Ge0rG, He wasn't locked in. He could leave at any time.

Zash, They might have, I've not been following.

> Ge0rG, He wasn't locked in. He could leave at any time. Reminds me of that one prison cell from Game of Thrones...

https://awoiaf.westeros.org/index.php/File:MKomarck_TyrionSkyCells.jpg

What can I use to keep some personal settings per muc? Like if I ever want to receive notifications from a specific muc or if I want to load URLs' previews etc. Some extended bookmarks would be perfect probably.

Our bookmark XEPs are not really bookmarks.. They're more of a sync protocol hacked together. Maybe someday we'll have a real bookmark XEP ("This time it's really real")

So you probably don't want that in there

rion, server-side notification settings are interesting for other reasons, as well, and one would probably want a protocol where the server is aware about what’s going on for push etc

yeah that'd be cool to have

pep.: the one thing that the Bookmarks XEP _doesn't_ do, is sync.

Not even Bookmarks in PEP?

Ge0rG, autojoin?

What does "sync" even mean here?

sync client state, joined or not joined

pep.: it's pull-based

Ge0rG, yeah ok we're not talking about the same thing

pep.: never.

Can't you just stuff extension elements into Bookmarks?

Ge0rG: Sure you can.

Zash: will they persist?

will they persist another client adding a bookmark?

Excellent question

I'm full of them.

I can only tell you that Prosody will preserve whatever data you put there. I don't know about other servers or clients.

Let's put notification preferences into there.

Also for contacts.

Or even better: let's stuff them into pep.

Ge0rG, gajim did that

i removed it

it just needs one client and your user loses his data

thats not something i would build any features on

That applies to basically everything where data is moved between serialization and native data structures.

Lossy transforms, loss of data.

yes but we do that not very often

vcard comes to mind

rion, you can use private storage

yep.

private PEP

and i dont mean the private storage bookmark namespace

somebody should define a format.

Get it into Bookmarks 2 early

Get it into Roster 2

Before people start relying on non-extensible data structures

Zash: did you say data forms?

Noooooooooooooooooooooooo

“Ge0rG> Or even better: let's stuff them into pep.”, please don't stuff things in me

pep.: it's fortunately very easy to find the right balance between insulting you and plausible deniability.

https://github.com/xsf/xeps/pull/786 - does this qualify as editorial?

Zash: is this merely the move? git diff isn't very good about showing moved paragraphs

https://cerdale.zash.se/upload/ljHhZXxxx5B9XBte/xep-0045-hide-gc10.html

s/git //

Ge0rG: ^ less xml noise at least

Zash: I suppose all I wanted to hear is "yes, I only moved the block down, promised!"

Ge0rG: I think I moved some sentences around to make it make sense, but I don't think any semantics are changed

Does it make sense to vote on that before getting rid of all of GC1?

oorrrrr

-Compliant multi-user chat services MUST accept the foregoing as a where "the foregoing" is GC 1.0 ...

Not that I think it will succeed

Because somebody wanted to ensure removing GC1 doesn't "break things"

Do we care? Prosody doesn't follow XEP-0045 anymore since it rejects GC 1.0 joins.

Zash, Do you have any figures for how many rejected joins that's caused?

Zash, And perhaps more importantly, whether that figure changed when you stopped accepting GC-1?

dwd: Very few.

IIRC we only saw GC 1.0 joins from one client, which happened to be our own web chat.

The rest were all mis-identified presence updates

Yes.

I've had similar stats on yax.im

Mabye there was some other old version of some random client I never heard of before that did gc1.0?

(I had it running for ~a week, and the GC1 joins were from prosody-chat.tar.gz or from clients that definitively support MUC join)

Seems a small price to pay for not going out of sync when a join is mis-identified as a presence update.

And that web chat was fixed, and then we switched to Converse.js

Then we drop GC-1.0 support from '45. Change it to MAY initially, perhaps?

MUST NOT.

Eventually, yes.

Hm, if there had been some way to signal that a complete state dump is being sent, it'd be easier.

Zash: in GC1.0?

Ge0rG: in MUC

Zash: I might have proposed something in that direction.

A MUC client that sends a presence update that gets treated as a GC1.0 join might end up with stale presence from departed occupants.

Zash: let me scrap some parts from the junkyard of standards@

I need a mutt macro for `/~f georg ~C standards ~s `

dwd: stats on GC1: https://mail.jabber.org/pipermail/standards/2018-April/034760.html

Zash: https://mail.jabber.org/pipermail/standards/2017-October/033501.html at the bottom, Proposed Solutions #3

I suppose I can take the fact that I can recite years old threads with solutions to problems that still come up as a lack of progress and general direction in the XSF.

Ge0rG: I'm not sure that's what I was thinking.

I was thinking a thing from the server that says "you were desynced. please drop all state. full state follows"

Then, if a presence update is treated as a join, it won't get out of sync

Could also be useful in case of intermittent s2s problems or cluster merges

Zash: how is the server supposed to know that you were desynced?

Ge0rG: It knows in the case of receiving a presence update from someone not in the room

Zash: provided you deny the existence of GC1

Zash: and even in that case, how do you know that client can understand a full-state-reset?

Hence why such a thing would have been useful if it already existed.

Zash: this is not how you evolve protocols

As it is now, I think just killing GC 1.0 is fine.

Ge0rG: How are we supposed to fix problems without time travel???? :P

Zash: as sad as it is, the presence of these problems is a clear sign of the non-existence of time travel

Ge0rG, Erm. But the Council agreed to removing GC-1.0 in principle, and asked for a PR: https://mail.jabber.org/pipermail/standards/2018-April/034768.html

Ge0rG, It was unanimous and everything. And you promised to do a PR.

dwd: not quite. There was a long-ish discussion about whether it improves things.

> Kev is OK with this in principle, as long as it results in an improvement.

> ... OK with one that doesn't break anything, but isn't sure it's possible

Ge0rG, Sure, there was no certainty the resulting PR would be accepted. But certainly unanimous agreement that we could in principle remove GC-1.0 support.

dwd: IIRC the minutes aren't clear and accurate in that regard, and that "silently cover up desyncs" was considered a desired feature.

dwd: I'm pretty sure that everybody in Council can understand the implications of removing GC1 without seeing a PR.

But yes, I owe us a PR.

This is a thing I may regret asking, because it shows how asleep I am, but what happens if instead of removing gc1 joins, you treat any presence from someone not in the room as a 45 join?

Kev, Isn't that what GC-1.0 is?

With full sync? I vaguely remember this was floated, but I don't remember the discussion.

Kev: You may proceed with regretting

Kev: that is equivalent to gc1

dwd: Not quite, you don't get the MUC payloads, do you?

Kev: Problem is that you don't know that it was a full sync until the last few stanzas of the sync.

Kev, I think you do, don't you? We assume a GC-1.0 client will ignore it.

Kev, The only difference is that room creation via GC-1.0 doesn't lock.

Ah, that was the problem, was it? Not knowing from the first stanza that it's treated as a join?

Or, do you even know? It might be ambigous.

Hence "it'd be nice if there was a state reset signal"

Zash: the self-presence _might_ give that away.

Ge0rG, In any case, COuncil probably can understand the implications in principle of removing GC-1.0 in principle, yes. But Council has to vote on any PR, anyway.

It's a clue, but not proof.

It can certainly go wrong, where MSN is concerned.

Ge0rG: I'm not so sure. Does it say "you joined" or "this is a presence from you"?

Zash: yes

At least as long as the codes aren't used consistently.

Ge0rG: Ah, status code 210?

Zash: no. you also get just a 110 on nick changes.

(I'm happy to agree it's simpler to error a non-joining presence than try and guess if the response is a sync or not)

https://xmpp.org/extensions/xep-0045.html#changepres doesn't say whether to include 110 in presence update reflections

110 is "this is your presence" 210 is "service assigned you this nickname"

dwd: have you just gone through https://mail.jabber.org/pipermail/standards/2017-October/033501.html ?

Ge0rG, No, because it's late and I'm going to bed.

Next question: What happens if you respond to a gc1 join with a kick?

I feel we've had that discussion too, and don't remember why that doesn't work.

Kev, Protocol or physical?

Kev: When joined or not joined?

A gc1 join when you're joined is just a status change.

Kev: how is that different from an error presence?

An error doesn't, on its own, say you're not in the room.

https://xmpp.org/extensions/xep-0045.html#example-23

Also what you get if you try to change nickname and the service says no

no!

https://xmpp.org/extensions/xep-0045.html#example-53

This looks copy&pasted.

It's far too late, and I'm too tired to think properly, but ISTM in my current state that sending a kick if you try to GC1 join would address the resync properties of gc1 from a different angle.

Maybe

(That is: ensure the user knows they're not in the room any more, so they can manually resync, even on old clients, and on new clients they can autorejoin)

(Although you'd want to annotate the kick so a new client would know it's not a 'normal' kick and an autorejoin is ok)

Kev: what's the GC1 syntax for kick?

I'm assuming, possibly wrongly, that the only 'use' these days for gc1 joins is the silent resync, not from gc1 clients.

"""use"""

Do we really want silent resync?

Kev: I agree with your assumption, if we don't imply a positive connotation to 'use'

There's positives and negatives to it. I don't think it's entirely either.

Whereas the explicit kicks might be superior to both.

> Kev: what's the GC1 syntax for kick?

There isn't one. That's what I was saying ,you'd use a 45 kick.

Right, bedtime.

Ge0rG, The assumption is that the only things sending GC-1.0 are resyncing '45 clients doing so by accident, and so they'd understand a '45 kick.

Ah!

So now we need a new status code or error condition for not-in-room.

But not an not-acceptable error?

Zash: which means "you may not change your name" -- "what? Did I try to change my name? Maybe my MSN alter ego did!"

Zash: thank you, I've made good use of your PR #2

everybody who hasn't gone to bed yet: https://github.com/xsf/xeps/pull/787

the PR number does bear a certain irony.