Ge0rGDave: 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
Zashxep-0600 already?? :)
Ge0rGI think somebody volunteered to write XEP-0404
jonaswI also think s o
jonaswkev maybe
Ge0rGI think so too
dwdhas joined
Ge0rGPeople joining with /phone and /tablet JIDs. Somebody really needs to fix their implementation :>
danielhas left
dwdhas left
pep.You mean fix Conversations?
Zashhttps://hg.prosody.im/prosody-modules/file/6f34e51a23f0/mod_compact_resource/mod_compact_resource.lua
An `if event.resource == "phone" then event.resource = ...` in there?
pep.As account.getResource() doesn't seem to be used if set
Ge0rGrandom on every bind is similarly broken.
Ge0rGMattJ: you wanted to make public your horrible hack of per-client offline history
MattJI did
Ge0rGReally, if we have that, we can get rid of MAM.
MattJHeh
ZashGe0rG: Worksforme, and I dislike fixed resources like 'phone' enough to just randomize it always
ZashI only know Swift doing what I think is right
Ge0rGZash: I know some clients doing what I think is right.
Ge0rGAnd despite my opinion being clearly superior, most developers seem to ignore it and insist on dumb client and server behavior.
DaveFWIW, I explicitly try to make clients use fixed identifiable resources because it helps my debugging.
Ge0rGDave: could you please highlight the parts of your message that contain sarcasm?
DaveNone, in this instance.
Ge0rGDave: 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.
Ge0rGI'm still convinced that `/phone.########` with a random postfix created by the client on account setup is the most sane middleground.
SamWhitedIf 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?
Ge0rGSamWhited: because the server doesn't know if you are connecting with the same client or with a different one
Ge0rGSamWhited: 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.
Ge0rGSamWhited: I think that server-side tracking of individual clients makes much sense and can aid in synchronizing stuff faster.
jonaswnot to mention killing off other streams when reconnecting without SM
Ge0rGSamWhited: the more the server knows about a client, the dumber we can make the client
SamWhitedI 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.
SamWhitedIt 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
Ge0rGSamWhited: 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.
Ge0rGAnd with the combo of 0198, 0280, 0313 life is a huge mess for client developers.
Ge0rGalso offline messages.
Zash1996? ITYM 1998
SamWhitedI 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.
Ge0rGSamWhited: I'm open to suggestions
KevI think offline messages quietly die.
KevWith 'xmpp 2'.
Ge0rGI think that per-client offline messages would silently fix UX for legacy client users
KevI 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).
SamWhitedKev already said what I was about to say :)
KevGe0rG: Only if you assume a small disconnect. Once you get into hundreds of messages, it doesn't.
Ge0rGKev: with hundreds of messages, MAM with RSM provides a better progress display
SamWhitedAlthough, 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.
jonaswonly if you get <count/> :-)
Ge0rGSamWhited: again, only if we start from scratch
SamWhitedNo, we could do that today
Ge0rGSamWhited: resource binding already has implications based on client identity.
KevGe0rG: I don't think so. A server can assign resourceparts to everything already, and some do.
SamWhitedWell sure, I'm not suggesting every server change overnight
KevOr I've not understood.
SamWhitedBut as Kev just said, it's perfectly backwards compatible to move towards a world where servers always assign a resourcepart.
SamWhitedSome of them already do it.
jonaswthat’s not a good idea with SM-less clients though?
jonaswunless you take the resource proposed by the client as a hint on which connection to kill.
Ge0rGjonasw: with Carbons that doesn't matter™
jonaswGe0rG, it does
Ge0rGBecause you can just keep two dozens of zombie resources for your client, no problem.
jonaswGe0rG, but the client would lose messages
Ge0rGThe other person will not receive error bounces for messages that went into them.
Ge0rGZombies are great.
jonaswsarcasm-detector fails
Ge0rGLet's grow them.
jonaswsarcasm-detectors?
jonaswsounds like a good idea
SamWhitedIf 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.
Ge0rGjonasw: no, zombies
DaveSamWhited, I don't think you can make things *worse*.
Ge0rGI'm sure we can make things worse.
DaveGe0rG, Well, yes. s/can/should/
jonaswespecially, I realize that the losing messages is independent of killing the old connection
jonaswI was confused, sorry
SamWhitedDave: I didn't follow that; what makes things worse?
Ge0rGAnd I think that making random resources enforced by the server _will_ make things worse.
Zashhas left
Ge0rGXMPP message delivery is already very fragile, and even with most modern clients you have issues of not receiving 0184 messages.
DaveBTW, 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
jonaswholy smokes
jonaswwhat’s a CFE?
Zashhas left
Zashhas joined
jonaswCall For Experience for moving to final?
jonaswso this is essentially a Final vs. Deprecate vote?
Ge0rGjonasw: right
jonaswokay
Zash> Ett webbläsarfel har uppstått.
Thanks supporting Firefox
jonaswwho’s going to do all the editorwork :-P
Davejonasw, Exactly. But we vote to CFE, and if that succeeds, I'll drop the other one.
Davejonasw, Oh, I had a thought about that - would github issues be OK for tracking editor tasks?
jonaswDave, I’d *love* that
Ge0rGSo I grepped for 0020 usage today, and found only 0066 and 0155 that are not deferred
jonaswa bulk issue is fine with me
Davejonasw, OK, I'll *try* to do that.
jonaswespecially if you use the '* [ ] foo' syntax
Ge0rGAnd 0020 is on the agenda as well
Ge0rGEh, 0066
Davejonasw, Hmmm. I can try that, or just individual issues.
jonaswDave, individual issues would work too, but that might in fact be more overhead because more pageloads for me.
DaveRight.
jonaswI prefer: bluk issue with '* [ ] list' > bulk issue in whatever format > Spreadsheet of Doom ~ one issue per task
jonaswI’m not sure on the ordering of the last two
DaveYeah, the SoD is useful for tracking voting (at least for me).
DaveBut not so much for tracking editor actions.
jonaswif 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
ZashIssue tracker!
SamWhitedIf 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.
jonaswI’d be in favour of that
jonaswI never was able to use the trello thing productively. the email notifications are pretty useless to me
danielZash: 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
danielAnd I'm not getting the joined with a resource phone thing either. Like instead of a proper username or what?
danielThat really shouldn't happen
Zashdaniel: It looked relevant to the topic at the time
DaveSamWhited, It might be useful for people to note non-GH-ish things for the agenda.
jonaswDave, for the editor agenda?
Davejonasw, Council.
vanitasvitaehas left
jonaswI think sam was referring to the editor trello, but I might be wrong.
SamWhitedDave: yah, I just meant the editor one. Let's not make editors use two tools.
SamWhitedDave: 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?)
DaveSamWhited, I have literally no idea. But you're looking for the pink ones.
Dave
29) Close
DaveYikes.
SamWhitedThe 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.
DaveSamWhited, Well, yes, the pink ones aren't until tomorrow (I do the spreadsheet first, then the agenda from that).
DaveSamWhited, But also, anything red in your column (except again I've updated that prior to the meeting - which I normally don't do).
SamWhitedBut my column is in the middle, so I have to find it which makes me sad
SamWhitedOr rather, the current date it in the middle, so I have to scroll down and figure out which was the last meeting.
Ge0rGDave: 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
Ge0rGCan'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
DaveI'm mildly concerned by the idea of provably unique stanza identifiers. But saying they ought to be globally unique seems fair.
KevIs a 29 item 30minute agenda sensible, or would we be better off chunking this a little bit?
DaveGe0rG, If I knew how to make the spreadsheet keep Row 1 from scrolling I'd be happy.
Zashis OUGHT in that rfc2119 follow-up?
SamWhitedDave: there is a little dark bar under row 1, drag it down below row 1 and that becomes the title.
SamWhitedBut I said column, I meant rows. It's the rows I'm trying to get to quicker.
SamWhited*above row 1
jonaswDave, 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?
Ge0rGjonasw: 👍
Davejonasw, That's the cherry on top of the agenda, though.
Davejonasw, It's the reward for getting through the other bits.
DaveKev, 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
KevI've not looked at it properly, I'm barely functioning today after a headache yesterday, but I saw it was long and got worried.
jonaswDave, how about I ping you on github when marking an issue Needs Council?
jonaswdoes that anything good or do you get the mails anyways
DaveKev, Most votes are paired CFE/Deprecate, where we don't do the second if we've done the first.
Davejonasw, 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.
jonaswDave, okay, whatever works for you :)
jonaswreminds me, gotta send emails
DaveSamWhited, Made it not-pink unless the items are between 0 and 14 days in the past.
SamWhitedI 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?
SamWhitedOr can we clear out the old stuff?
Zashhas left
jonaswI 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 #)
DaveSamWhited, 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.
DaveOf course, none of these list anything right now because there are no current votes.
Zashhas left
SamWhitedoh individualized tabs; fancy! Thanks
Ge0rG"You need to be logged in as samwhited@gmail.com to view this tab." Bummer.
SamWhitedI don't know who samwhited@gmail.com is, but it's not me
SamWhitedI appear to be able to see all the tabs, but they all show up with no data in them
DaveSamWhited, Right. Because there are no current votes.
DaveSamWhited, I changed some of the dates to check it worked. :-)