Dave: https://github.com/xsf/xeps/pull/600 - "XEP-0045: Implement stable IDs on Reflection" ✏
Davehas left
dwdhas left
jonaswputs an hooray emoji both for 600th PR and for the thing itself
Zash
xep-0600 already?? :)
Ge0rG
I think somebody volunteered to write XEP-0404
jonasw
I also think s o
jonasw
kev maybe
Ge0rG
I think so too
dwdhas joined
Ge0rG
People joining with /phone and /tablet JIDs. Somebody really needs to fix their implementation :>
danielhas left
dwdhas left
pep.
You mean fix Conversations?
Zash
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?
As account.getResource() doesn't seem to be used if set
Ge0rG
random on every bind is similarly broken.
Ge0rG
MattJ: you wanted to make public your horrible hack of per-client offline history
MattJ
I did
Ge0rG
Really, if we have that, we can get rid of MAM.
MattJ
Heh
Zash
Ge0rG: Worksforme, and I dislike fixed resources like 'phone' enough to just randomize it always
Zash
I only know Swift doing what I think is right
Ge0rG
Zash: I know some clients doing what I think is right.
Ge0rG
And despite my opinion being clearly superior, most developers seem to ignore it and insist on dumb client and server behavior.
Dave
FWIW, I explicitly try to make clients use fixed identifiable resources because it helps my debugging.
Ge0rG
Dave: could you please highlight the parts of your message that contain sarcasm?
Dave
None, in this instance.
Ge0rG
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.
Ge0rG
I'm still convinced that `/phone.########` with a random postfix created by the client on account setup is the most sane middleground.
SamWhited
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?
Ge0rG
SamWhited: because the server doesn't know if you are connecting with the same client or with a different one
Ge0rG
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
SamWhited
*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.
Ge0rG
SamWhited: I think that server-side tracking of individual clients makes much sense and can aid in synchronizing stuff faster.
jonasw
not to mention killing off other streams when reconnecting without SM
Ge0rG
SamWhited: the more the server knows about a client, the dumber we can make the client
SamWhited
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.
SamWhited
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.
Zashhas left
Ge0rG
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.
Ge0rG
And with the combo of 0198, 0280, 0313 life is a huge mess for client developers.
Ge0rG
also offline messages.
Zash
1996? ITYM 1998
SamWhited
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.
Ge0rG
SamWhited: I'm open to suggestions
Kev
I think offline messages quietly die.
Kev
With 'xmpp 2'.
Ge0rG
I think that per-client offline messages would silently fix UX for legacy client users
Kev
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).
SamWhited
Kev already said what I was about to say :)
Kev
Ge0rG: Only if you assume a small disconnect. Once you get into hundreds of messages, it doesn't.
Ge0rG
Kev: with hundreds of messages, MAM with RSM provides a better progress display
SamWhited
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.
jonasw
only if you get <count/> :-)
Ge0rG
SamWhited: again, only if we start from scratch
SamWhited
No, we could do that today
Ge0rG
SamWhited: resource binding already has implications based on client identity.
Kev
Ge0rG: I don't think so. A server can assign resourceparts to everything already, and some do.
SamWhited
Well sure, I'm not suggesting every server change overnight
Kev
Or I've not understood.
SamWhited
But as Kev just said, it's perfectly backwards compatible to move towards a world where servers always assign a resourcepart.
SamWhited
Some of them already do it.
jonasw
that’s not a good idea with SM-less clients though?
jonasw
unless you take the resource proposed by the client as a hint on which connection to kill.
Ge0rG
jonasw: with Carbons that doesn't matter™
jonasw
Ge0rG, it does
Ge0rG
Because you can just keep two dozens of zombie resources for your client, no problem.
jonasw
Ge0rG, but the client would lose messages
Ge0rG
The other person will not receive error bounces for messages that went into them.
Ge0rG
Zombies are great.
jonasw
sarcasm-detector fails
Ge0rG
Let's grow them.
jonasw
sarcasm-detectors?
jonasw
sounds like a good idea
SamWhited
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.
Ge0rG
jonasw: no, zombies
Dave
SamWhited, I don't think you can make things *worse*.
Ge0rG
I'm sure we can make things worse.
Dave
Ge0rG, Well, yes. s/can/should/
jonasw
especially, I realize that the losing messages is independent of killing the old connection
jonasw
I was confused, sorry
SamWhited
Dave: I didn't follow that; what makes things worse?
Ge0rG
And I think that making random resources enforced by the server _will_ make things worse.
Zashhas left
Ge0rG
XMPP message delivery is already very fragile, and even with most modern clients you have issues of not receiving 0184 messages.
Dave
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
jonasw
holy smokes
jonasw
what’s a CFE?
Zashhas left
Zashhas joined
jonasw
Call For Experience for moving to final?
jonasw
so this is essentially a Final vs. Deprecate vote?
Ge0rG
jonasw: right
jonasw
okay
Zash
> Ett webbläsarfel har uppstått.
Thanks supporting Firefox
jonasw
who’s going to do all the editorwork :-P
Dave
jonasw, Exactly. But we vote to CFE, and if that succeeds, I'll drop the other one.
Dave
jonasw, Oh, I had a thought about that - would github issues be OK for tracking editor tasks?
jonasw
Dave, I’d *love* that
Ge0rG
So I grepped for 0020 usage today, and found only 0066 and 0155 that are not deferred
jonasw
a bulk issue is fine with me
Dave
jonasw, OK, I'll *try* to do that.
jonasw
especially if you use the '* [ ] foo' syntax
Ge0rG
And 0020 is on the agenda as well
Ge0rG
Eh, 0066
Dave
jonasw, Hmmm. I can try that, or just individual issues.
jonasw
Dave, individual issues would work too, but that might in fact be more overhead because more pageloads for me.
Dave
Right.
jonasw
I prefer: bluk issue with '* [ ] list' > bulk issue in whatever format > Spreadsheet of Doom ~ one issue per task
jonasw
I’m not sure on the ordering of the last two
Dave
Yeah, the SoD is useful for tracking voting (at least for me).
Dave
But not so much for tracking editor actions.
jonasw
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
Zash
Issue tracker!
SamWhited
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.
jonasw
I’d be in favour of that
jonasw
I never was able to use the trello thing productively. the email notifications are pretty useless to me
daniel
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
daniel
And I'm not getting the joined with a resource phone thing either. Like instead of a proper username or what?
daniel
That really shouldn't happen
Zash
daniel: It looked relevant to the topic at the time
Dave
SamWhited, It might be useful for people to note non-GH-ish things for the agenda.
jonasw
Dave, for the editor agenda?
Dave
jonasw, Council.
vanitasvitaehas left
jonasw
I think sam was referring to the editor trello, but I might be wrong.
SamWhited
Dave: yah, I just meant the editor one. Let's not make editors use two tools.
SamWhited
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?
SamWhited
(do spreadsheets have a name for that? Like a materialized view in a proper database?)
Dave
SamWhited, I have literally no idea. But you're looking for the pink ones.
Dave
29) Close
Dave
Yikes.
SamWhited
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.
Dave
SamWhited, Well, yes, the pink ones aren't until tomorrow (I do the spreadsheet first, then the agenda from that).
Dave
SamWhited, But also, anything red in your column (except again I've updated that prior to the meeting - which I normally don't do).
SamWhited
But my column is in the middle, so I have to find it which makes me sad
SamWhited
Or rather, the current date it in the middle, so I have to scroll down and figure out which was the last meeting.
Ge0rG
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
Ge0rG
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
Dave
I'm mildly concerned by the idea of provably unique stanza identifiers. But saying they ought to be globally unique seems fair.
Kev
Is a 29 item 30minute agenda sensible, or would we be better off chunking this a little bit?
Dave
Ge0rG, If I knew how to make the spreadsheet keep Row 1 from scrolling I'd be happy.
Zash
is OUGHT in that rfc2119 follow-up?
SamWhited
Dave: there is a little dark bar under row 1, drag it down below row 1 and that becomes the title.
SamWhited
But I said column, I meant rows. It's the rows I'm trying to get to quicker.
SamWhited
*above row 1
jonasw
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?
Ge0rG
jonasw: 👍
Dave
jonasw, That's the cherry on top of the agenda, though.
Dave
jonasw, It's the reward for getting through the other bits.
Dave
Kev, FWIW, this is really a 15 item agenda, with some items potentially having two votes. I think we'll overrun, but not badly.
danielhas left
Kev
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.
jonasw
Dave, how about I ping you on github when marking an issue Needs Council?
jonasw
does that anything good or do you get the mails anyways
Dave
Kev, Most votes are paired CFE/Deprecate, where we don't do the second if we've done the first.
Dave
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.
jonasw
Dave, okay, whatever works for you :)
jonasw
reminds me, gotta send emails
Dave
SamWhited, Made it not-pink unless the items are between 0 and 14 days in the past.
SamWhited
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?
SamWhited
Or can we clear out the old stuff?
Zashhas left
jonasw
I think I still have to execute two ediotr actions from last meeting, maybe put those into something else first.
Ge0rG
> 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 #)
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.
Dave
Of course, none of these list anything right now because there are no current votes.
Zashhas left
SamWhited
oh individualized tabs; fancy! Thanks
Ge0rG
"You need to be logged in as samwhited@gmail.com to view this tab." Bummer.
SamWhited
I don't know who samwhited@gmail.com is, but it's not me
SamWhited
I appear to be able to see all the tabs, but they all show up with no data in them
Dave
SamWhited, Right. Because there are no current votes.
Dave
SamWhited, I changed some of the dates to check it worked. :-)