XMPP Council - 2018-03-06

Dave: https://github.com/xsf/xeps/pull/600 - "XEP-0045: Implement stable IDs on Reflection" ✏

xep-0600 already?? :)

I think somebody volunteered to write XEP-0404

I also think s o

kev maybe

I think so too

People joining with /phone and /tablet JIDs. Somebody really needs to fix their implementation :>

You mean fix Conversations?

https://hg.prosody.im/prosody-modules/file/6f34e51a23f0/mod_compact_resource/mod_compact_resource.lua An `if event.resource == "phone" then event.resource = ...` in there?

Ge0rG: join where?

Everywhere

Why not just let the server do it itself? ^

As account.getResource() doesn't seem to be used if set

random on every bind is similarly broken.

MattJ: you wanted to make public your horrible hack of per-client offline history

I did

Really, if we have that, we can get rid of MAM.

Heh

Ge0rG: Worksforme, and I dislike fixed resources like 'phone' enough to just randomize it always

I only know Swift doing what I think is right

Zash: I know some clients doing what I think is right.

And despite my opinion being clearly superior, most developers seem to ignore it and insist on dumb client and server behavior.

FWIW, I explicitly try to make clients use fixed identifiable resources because it helps my debugging.

Dave: could you please highlight the parts of your message that contain sarcasm?

None, in this instance.

Dave: thanks very much. I kind of expected that to be a sarcastic response to my megalomania, especially beacuse I was asking to have human-readable resources for debugging purposes all along.

I'm still convinced that `/phone.########` with a random postfix created by the client on account setup is the most sane middleground.

If you're using it for debugging can't the server do that? Use that library that gives you four random words and then tack on some proper randomness. Why does the client need to be involved?

SamWhited: because the server doesn't know if you are connecting with the same client or with a different one

SamWhited: things like push and per-device-offline-history and even parallel session management make more sense if the server can distinguish your client instances

*nods* I see. I generally think we should discourage anything that requires individual clients to be known (eg. per-device-offline-history seems like the wrong way to go about doing history), but I suspect I'll never convince anyone else of that.

SamWhited: I think that server-side tracking of individual clients makes much sense and can aid in synchronizing stuff faster.

not to mention killing off other streams when reconnecting without SM

SamWhited: the more the server knows about a client, the dumber we can make the client

I have a vague feeling (not a strong one yet) that it just leads to a more complicated protocol and hurts us, but I don't have any good reasoning for that. I don't think not having it would make any of the clients any less dumb.

It just means we have to design specs assuming that all clients get the same data and view of the world, which seems like a reasonable simplification to make.

SamWhited: yes. But we are not designing a new protocol from scratch, instead we are adding layers of cruft on a 1996 unreliable message dispatching system.

And with the combo of 0198, 0280, 0313 life is a huge mess for client developers.

also offline messages.

1996? ITYM 1998

I don't disagree with any of that, but I also don't think that means we have to keep designing things that way and can move towards simplifying the protocol.

SamWhited: I'm open to suggestions

I think offline messages quietly die.

With 'xmpp 2'.

I think that per-client offline messages would silently fix UX for legacy client users

I think 198 is a different layer, and not really a big deal for clients (at least for acks. I'm still not entirely sold on resume).

Kev already said what I was about to say :)

Ge0rG: Only if you assume a small disconnect. Once you get into hundreds of messages, it doesn't.

Kev: with hundreds of messages, MAM with RSM provides a better progress display

Although, the other thing I've already said: in my mind it's simpler if the client knows nothing about the resourcepart except that it was assigned one by the server. If the server doesn't necessarily know the difference between clients I think it simplifies what we'll do with the protocol.

only if you get <count/> :-)

SamWhited: again, only if we start from scratch

No, we could do that today

SamWhited: resource binding already has implications based on client identity.

Ge0rG: I don't think so. A server can assign resourceparts to everything already, and some do.

Well sure, I'm not suggesting every server change overnight

Or I've not understood.

But as Kev just said, it's perfectly backwards compatible to move towards a world where servers always assign a resourcepart.

Some of them already do it.

that’s not a good idea with SM-less clients though?

unless you take the resource proposed by the client as a hint on which connection to kill.

jonasw: with Carbons that doesn't matter™

Ge0rG, it does

Because you can just keep two dozens of zombie resources for your client, no problem.

Ge0rG, but the client would lose messages

The other person will not receive error bounces for messages that went into them.

Zombies are great.

sarcasm-detector fails

Let's grow them.

sarcasm-detectors?

sounds like a good idea

If they're a legacy client without carbons or SM they can already lose messages, so it seems like we can ignore that. If we really can't ignore that, then the server can still see what resource part the legacy client is detecting, use that internally for tracking, and then assign it a random one.

jonasw: no, zombies

SamWhited, I don't think you can make things *worse*.

I'm sure we can make things worse.

Ge0rG, Well, yes. s/can/should/

especially, I realize that the losing messages is independent of killing the old connection

I was confused, sorry

Dave: I didn't follow that; what makes things worse?

And I think that making random resources enforced by the server _will_ make things worse.

XMPP message delivery is already very fragile, and even with most modern clients you have issues of not receiving 0184 messages.

BTW, I've updated the Spreadsheet Of Doom™ with tomorrows items for a vote. There's a lot. https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0

holy smokes

what’s a CFE?

Call For Experience for moving to final?

so this is essentially a Final vs. Deprecate vote?

jonasw: right

okay

> Ett webbläsarfel har uppstått. Thanks supporting Firefox

who’s going to do all the editorwork :-P

jonasw, Exactly. But we vote to CFE, and if that succeeds, I'll drop the other one.

jonasw, Oh, I had a thought about that - would github issues be OK for tracking editor tasks?

Dave, I’d *love* that

So I grepped for 0020 usage today, and found only 0066 and 0155 that are not deferred

a bulk issue is fine with me

jonasw, OK, I'll *try* to do that.

especially if you use the '* [ ] foo' syntax

And 0020 is on the agenda as well

Eh, 0066

jonasw, Hmmm. I can try that, or just individual issues.

Dave, individual issues would work too, but that might in fact be more overhead because more pageloads for me.

Right.

I prefer: bluk issue with '* [ ] list' > bulk issue in whatever format > Spreadsheet of Doom ~ one issue per task

I’m not sure on the ordering of the last two

Yeah, the SoD is useful for tracking voting (at least for me).

But not so much for tracking editor actions.

if I had +w I could tick off editor actions tehre too. but what I need most is something which gets me an email in my inbox when something is to b e done

Issue tracker!

If the editors want to move to GitHub issues (and someone is willing to create the issues), let's close the Trello board to avoid confusion.

I’d be in favour of that

I never was able to use the trello thing productively. the email notifications are pretty useless to me

Zash: I'm missing so much context. That commit you linked is just a debug option for Guus to debug open fire. It deliberately not kicks you old resource

And I'm not getting the joined with a resource phone thing either. Like instead of a proper username or what?

That really shouldn't happen

daniel: It looked relevant to the topic at the time

SamWhited, It might be useful for people to note non-GH-ish things for the agenda.

Dave, for the editor agenda?

jonasw, Council.

I think sam was referring to the editor trello, but I might be wrong.

Dave: yah, I just meant the editor one. Let's not make editors use two tools.

Dave: Also, a request: can there be a tab on that spreadsheet that mirrors the main one but only gives you a view of the last two weeks?

(do spreadsheets have a name for that? Like a materialized view in a proper database?)

SamWhited, I have literally no idea. But you're looking for the pink ones.

29) Close

Yikes.

The pink ones are all in the future which I assume means I have no outstanding stuff? I am happy to make a new tab with just the view I care about if you give me access.

SamWhited, Well, yes, the pink ones aren't until tomorrow (I do the spreadsheet first, then the agenda from that).

SamWhited, But also, anything red in your column (except again I've updated that prior to the meeting - which I normally don't do).

But my column is in the middle, so I have to find it which makes me sad

Or rather, the current date it in the middle, so I have to scroll down and figure out which was the last meeting.

Dave: while we are here. I wanted to address the insufficient uniqueness of IDs in RFC 6120, but I have no idea what we can do about it, process-wise

Can't we align the member names to the spreadsheet column letters, so Kev would be in K, Sam would be in S and Daniel and Dave would be in D? :D

I'm mildly concerned by the idea of provably unique stanza identifiers. But saying they ought to be globally unique seems fair.

Is a 29 item 30minute agenda sensible, or would we be better off chunking this a little bit?

Ge0rG, If I knew how to make the spreadsheet keep Row 1 from scrolling I'd be happy.

is OUGHT in that rfc2119 follow-up?

Dave: there is a little dark bar under row 1, drag it down below row 1 and that becomes the title.

But I said column, I meant rows. It's the rows I'm trying to get to quicker.

*above row 1

Dave, suggestion: given that that’s going to be a long agenda, could council discuss the PRs (where people put work into getting things proposed) first?

jonasw: 👍

jonasw, That's the cherry on top of the agenda, though.

jonasw, It's the reward for getting through the other bits.

Kev, FWIW, this is really a 15 item agenda, with some items potentially having two votes. I think we'll overrun, but not badly.

I've not looked at it properly, I'm barely functioning today after a headache yesterday, but I saw it was long and got worried.

Dave, how about I ping you on github when marking an issue Needs Council?

does that anything good or do you get the mails anyways

Kev, Most votes are paired CFE/Deprecate, where we don't do the second if we've done the first.

jonasw, I do the agenda by looking at all the open pulls, actually, so while I do get the mails I don't use them for that.

Dave, okay, whatever works for you :)

reminds me, gotta send emails

SamWhited, Made it not-pink unless the items are between 0 and 14 days in the past.

I still have to scroll down and find it and I am lazy; can I please just get a second tab that I can make a view that only shows the last two weeks that are not in the future?

Or can we clear out the old stuff?

I think I still have to execute two ediotr actions from last meeting, maybe put those into something else first.

> Or can we clear out the old stuff? I'd like to keep history, even if only in a separate tab. It helps when looking for discussion agendas (our council agenda logs are inherently unsearchable by XEP #)

This would work:

=filter(Sheet1!A$2:A, Sheet1!$A$2:$A<TODAY(), Sheet1!$A$2:$A>(MAX(filter(Sheet1!$A$2:$A, Sheet1!$A$2:$A<TODAY()))-14))

There may be a simpler way of course

SamWhited, OK, you now have both a "Current" tab and a "Sam" tab. "Current" lists current votes, and "Sam" only lists current votes for which you haven't voted.

Of course, none of these list anything right now because there are no current votes.

oh individualized tabs; fancy! Thanks

"You need to be logged in as samwhited@gmail.com to view this tab." Bummer.

I don't know who samwhited@gmail.com is, but it's not me

I appear to be able to see all the tabs, but they all show up with no data in them

SamWhited, Right. Because there are no current votes.

SamWhited, I changed some of the dates to check it worked. :-)