-
jonas’
1) Roll Call
- jonas’ is present
- Zash 2
-
daniel
Hi
-
Ge0rG
Hi
-
jonas’
no dwd yet, but we can start bashing the agenda already
-
jonas’
2) Agenda Bashing
-
jonas’
anyhting?
-
jonas’
assuming no
-
jonas’
3) Editor’s Update - Published Content Rating Labels as XEP-0456
-
jonas’
4) Items for voting
-
jonas’
4a) Deprecate XEP-0013: Flexible Offline Message Retrieval Abstract: This specification defines an XMPP protocol extension for flexible, POP3-like handling of offline messages. The protocol enables a connecting client to retrieve its offline messages on login in a controlled fashion, without receiving a flood of messages. Messages can also be left on the server for later retrieval. URL: https://xmpp.org/extensions/xep-0013.html
-
jonas’
Sam has asked for this being deprecated because of the overlap with the (preferable) MAM.
-
Ge0rG
I never really liked the 0013 workaround for the MAM use case
-
Ge0rG
But we don't have any alternative
-
Zash
We already deprecated XEP-0136?!
-
daniel
i think I might be one of the few people who actually implment this
-
daniel
(very partially)
-
Ge0rG
I still think we can deprecate 0013, apparently there is not so much business need to replace it
-
Ge0rG
daniel: only the one feature to drop history?
-
daniel
yes
-
daniel
but as Holger (for example) pointed out we currently don’t have a mechanism to replace this
-
Zash
With the real underlying problem being that it's unspecified how offline messages and MAM are supposed to work together?
-
Ge0rG
Can we come up with something that's better than 0013 but not as cool as bind2 for this?
-
daniel
that being said i'm still in favor of deprecating it
-
jonas’
we could pull the "clear" protocol from '13 into '313
-
jonas’
and then deprecate '13
-
Ge0rG
What about "a client that does anything with MAM on connect will get its history dropped"?
-
daniel
i don’t think that having or not having a replacement is a strict requirement to deprecate something
-
Sam
Or go ahead and deprecate '13 today since it won't break anything to do so, then move the protocol whenever someone wants so we don't have to drag this along forever.
-
Sam
Deprecating may even encourage someone to do the work (in fact, I will volunteer, I made some modifications to 313 recently and can probably find time to do more)
-
Kev
Or Bind2! What could go wrong? :)
-
daniel
moving the clear protocol into 313 sounds like a good intermediate solution
-
Ge0rG
It's a horrible non-solution.
-
Sam
*nods* or bind2. That may need further discussion.
-
daniel
because i don’t have a lot of hope for bind2 to happen any time soon
-
jonas’
me neither
-
Ge0rG
We already have enough racy corner cases in 313 without the "delete all history *now*"
-
daniel
you keep saying this. but i don’t find MAM to be all that terrible
-
Kev
I’m hoping to implement it later in the year, but yeah. I just want to note it’s not true to say we have no replacement, as Bind2 covers that case (and, indeed, this ‘how to deal with history and startup sync and stuff) is why it exists.
-
daniel
even when used with a drop history now command
-
Ge0rG
daniel: it's only not terrible if you execute the steps in the magically right but not documented order
-
Sam
Sounds like feedback for the 313 last call?
-
Ge0rG
in a perfect world, a server implementation should store MAM and offline history in the same database, and keep a (per client) marker from where to send offline history
-
daniel
are we in agreement that we do want to have a 'drop history' feature that isn’t bind2?
-
daniel
should we check with the MAM authors if they are ok with adding that before we deprecate 13?
-
Ge0rG
I'm ambivalent regarding that feature
-
Zash
Ge0rG, yeah, turning offline messages into an implicit MAM query for non-supporting clients would be interesting. Like what Prosody does with MUC (legacy) history
-
Ge0rG
Sam: I think I wrote that to the ML as feedback to the initial 313 submission some many years ago. Does that count?
-
Zash
Does it need to go in 313?
-
Sam
Ge0rG: no, absolutely not, because this is another LC and finding things beyond a day ago in a mailing list is impossible :)
-
Zash
Once we're away from offline messages entirely, is such a feature needed?
-
daniel
well there are benefits of putting it into 313
-
daniel
because Conversations currently needs to check mam preference before executing 13 delete
-
Zash
daniel, but mam prefs aren't in 313 anymore
-
daniel
having that command in 313 would actually make that easier
-
daniel
details…
-
Zash
Put it in a new XEP or whatever 🤷️
-
Zash
That way it can be deprecated if we figure out a better way
-
Ge0rG
What about "do not deliver offline messages to a MAM client" and "expire old messages from offline history if full instead of rejecting new ones"?
-
Ge0rG
daniel: would there be harm in adding the former statement into 0313?
-
Kev
I disagree with Ge0rG’s perfect world, incidentally, because I don’t believe there’s any need for a per-client offline store. Users are unlikely to care which clients have and haven’t received messages, they just want their messages.
-
Kev
The perfect world has no offline messages at all :)
-
Ge0rG
Kev: users want their messages on all their clients and not on a random subset. And from that, you can easily derive my proposal ;)
-
Zash
`module:unload"offline"` there, I fixed it
-
jonas’
ok, so, where are we at with Deprecating '13?
-
Ge0rG
Imagine we could fix the perceived XMPP reliability for all the victims of pidgin, at a very low cost?
-
Kev
I’d also not be inclined to shove offline message stuff in 313 as a temporary holding, unless we don’t intend advancing 313. Just shove it in something new until we solve bind2 in whatever way we solve it.
-
jonas’
I see that there are arguments about how MAM catchup may be improved, but those are only tangentially related to the '13 deprecation.
-
Zash
jonas’, +1 then
-
Kev
What is the proposal, other than using bind2 or something akin to bind2, to tell your server that you’re a mam client and not to send offline messages?
-
Ge0rG
+1 for deprecating 0013
-
daniel
+1
-
jonas’
+1
-
jonas’
ok, then we’ve got that sorted and everything else can go in the '313 LC thread which is *still active* or in a separate bind2 design discussion on-list
-
jonas’
thanks
-
Ge0rG
Kev: my proposal is just to not send offline messages to any MAM capable client
-
Kev
Yes. How does the server tell it’s a MAM capable client?
-
daniel
I actually have a bunch of setups where we very deliberatly don’t do MAM in favor of offline messages
-
jonas’
I’d like to move on with the meeting and defer any further discussion to xsf@
-
daniel
but we don’t need 13 for these setups
-
jonas’
5) Pending Votes - none from before this meeting
-
jonas’
6) Date of Next
-
jonas’
+1w wfm
-
daniel
m2
-
Sam
Wasn't there a vote missing? I presume they're on list then?
-
Ge0rG
+1W WFM
-
jonas’
Sam, dwd is AFK, so yeah.
-
Zash
+7d wfm
-
jonas’
great!
-
jonas’
7) AOB
-
jonas’
I’ve got one from just now
-
jonas’
do we want to move Council meetings to xsf@?
-
Zash
I'm not opposed
-
jonas’
I see that we often start discussions here which are then hard to carry over to xsf@
-
Zash
Always did seem weird to have board meetings there but not council meetings
-
Kev
I see no reason to do it, and (probably not hugely important) reasons not to.
-
jonas’
and we might get more input during the meeting (which may also incur more noise, mind)
-
Ge0rG
Wasn't the Council meeting moved out of xsf@ to make it less noisy?
-
Zash
We could try, easy enough to move back.
-
Kev
I don’t recall Council ever being in xsf@, but I might just have blocked that out of my memory.
-
jonas’
Do we just want to give it a shot for next week and see where it leads us?
-
Kev
One significant advantage of leaving it here is filtering.
-
Kev
xsf@ is noisy and I frequently ignore it for the best part of a day, but once I see stuff happening in council@ I realise it’s council time and I try to pay some attention.
-
daniel
i actually don’t really like board meetings to be in xsf@
-
Kev
And if I want to read what happened in council because I missed it, it’s easily delineated by being here.
-
daniel
and i'd prefer to keep council meetings in here
-
Zash
Maybe the real issue is that there's no exact equivalent to the standards@ ML
-
Ge0rG
also a weak preference for staying here
-
jonas’
okay
-
jonas’
let’s stay here then :)
-
daniel
not for council's or board's sake but for the sake of the people in there who might have a different discussion going on at the time
-
jonas’
daniel, yes, another good reason to stay here
-
jonas’
alright, AO-AOB?
-
Zash
It /is/ easier to set this room as higher priority (notification-wise) than figure out some time based rules for xsf@
-
Zash
(I've got no ao²b)
-
Kev
Jonas - just noting that while I understand your desire to stay on time and curtail discussion, I think it would have been of value for Council to give guidance on what to do instead at the same time as deprecating 13 (with which I vaguely agree).
-
jonas’
alright then
-
jonas’
Kev, oh---
-
jonas’
Kev, instead of what, mind?
-
Kev
Instead of using 13 as the MAM cludge.
-
jonas’
... use MAM?
-
Ge0rG
> This Last Call begins today and shall end at the close of business on 2021-03-30. I'm too late :(
-
Zash
Note when the client uses MAM (prefs?) before <presence/>, ???, PROFIT!
-
jonas’
Ge0rG, oh, missed than when I prepped the agenda :(
-
Ge0rG
What Zash said.
-
Sam
Or maybe deprecate 13 then the guidance is "start implementing bind2" and this is what puts pressure on people to actually use it?
-
Kev
jonas’ use MAM on its own doesn’t solve the duplication issue that people are using 13 for.
-
Ge0rG
When a client queries MAM or MAM prefs, let the server omit offline history on presence
-
Ge0rG
Kev: which issue?
-
jonas’
Kev, I mean, personally I’d guide people to continue to use that single bit of the deprecated '13
-
jonas’
this does make sufficient sense to me
-
Kev
Ge0rG: That you log in and request history, but you also get sent offline messages that duplicate what’s in the history. Or have I completely misunderstood?
-
Sam
or what jonas’ said.
-
jonas’
(just like you still have to do RFC 3920 session stuff with some servers; even though it’s deprecated, you might need bits and pieces to work with deprecated servers)
-
Ge0rG
Kev: see Zash's and my proposals above?
-
Kev
Ge0rG: I saw you propose not to send offline to MAM clients (which is right), but I don’t think you replied to my question on how (short of bind2) the server should determine it’s a mam-capable client before sending the offline messages.
-
Kev
The options I can think of add roundtrips, which make them pretty much non-options.
-
Kev
(Like doing disco on the client)
-
Zash
Kev, a MAM-capable client would be asking for MAM prefs probably?
-
Ge0rG
Kev: that's what Zash proposed above, keep a flag on the c2s session that's set to "MAM" when the client does any MAM activity
-
Zash
Prosody has a "smart enable" setting for MAM that gets enabled when the client does something MAM-related
-
Ge0rG
Kev: because of MAM race condition weirdness, a client must essentially ask for the last MAM stored ID before sending initial presence
-
Zash
Could extend that logic to stop offline broadcast
-
Ge0rG
The MAM race condition weirdness that nobody but me is obsessed about.
-
Kev
Ge0rG: That would be the ‘add a roundtrip’ that I’m proposing isn’t much of an option.
-
Zash
You would have to do so before the initial p resence✎ -
Zash
You would have to do so before the initial presence ✏
-
Kev
Actually, you don’t have to wait for reply, you can pipeline it.
-
Ge0rG
Kev: the client can pipeline MAM prefs / MAM query / presence.
-
Kev
The client doesn’t need to do MAM prefs does it?
-
daniel
Conversations uses MAM prefs to decide if it wants to purge
-
Kev
So we’re saying essentially send an empty MAM query (or limit 1) before sending initial presence is the fix?
-
daniel
but obviously not pipelined
-
Ge0rG
Kev: it's not the fix but a pragmatic solution suggestion
-
Zash
XEP wishlist: "How to deal with offline messages in the presence of MAM"
-
Ge0rG
I'm very much interested in the side effects.
-
Ge0rG
Kev: does your implementation not send a MAM query prior to initial presence?
-
Kev
So we need a new XEP that says “If a client requests MAM prior to offline messages being sent, dump the offline store. As a client, request MAM before initial presence”?
-
Kev
Ge0rG: My current implementation only requests MAM when you open a chat, for some context to fill it with.
-
Zash
Kev, ^C^V that into a xep, title it "How to deal with offline messages in the presence of MAM", call it a day? 🙂
-
daniel
> So we need a new XEP that says “If a client requests MAM prior to offline messages being sent, dump the offline store. As a client, request MAM before initial presence”? either that or a conditional purge
-
Zash
Kev, does your implementation *not* want offline messages in this case?
-
Kev
Zash: I don’t think that’s a bad option. I might even do that now, as my migraine hangover means I can’t do much else of value today.
-
daniel
a purge if i have mam enabled command
-
daniel
that can be send right before initial presence
-
Ge0rG
Kev: you could send initial presence with a negative priority and enable carbons.
-
Kev
Zash: My implementation basically wants bind2, and everything that comes with that (currently specified and not yet specified).
-
Kev
Because I don’t want to do full-sync, I want to do current-state-sync (inbox stylee)
-
jonas’
I do appreciate the discussion and I see that it’s of value to provide more guidance.
-
Zash
Type that sentence into the wiki in the section for hacks to do until we get bind2?
-
jonas’
My current view is that the trivial solution is to simply use the clearing bits of '13 as needed
-
jonas’
anything more complex should go to the list, either in the form of a thread or as a protoxep submission
-
jonas’
any objections to me closing the meeting with that conclusion?
-
Zash
sgtm
-
Kev
No. Thanks for letting us reach some sort of conclusion.
-
jonas’
alright then
-
jonas’
8) Ite Meeting Est
-
jonas’
Thanks Tedd, Thanks Kev (for reminding me about the discussion I cut off earlier), Thanks everyone!
-
Zash
Thanks all
-
Sam
Thanks fo rthe interesting discussion. I'll create a thread on list right now (unless someone else would prefer to do it)
-
Zash
Thanks Sam, please do 🙂
-
jonas’
Yes, please go ahead
- Ge0rG is commenting on the 313 LC
-
Ge0rG
but that might not cover all points.
-
Kev
I need to read 313 properly (or at least a diff since I last understood it) before replying to the LC. I’ve just not found the time yet.
-
Zash
That sounds like a thing I should have done too
-
Ge0rG
Zash: it's not too late.
-
Zash
Didn't I reply already?
-
Ge0rG
Zash: sure, but you can reply to yourself
-
Zash
:O
-
Sam
Sent.
-
Kev
Might it make sense to simply write a new XEP containing that one iq from 13?
-
Kev
Anyway, moved beyond Council now, I’ll take it to list.
-
Ge0rG
Kev: ...and call it 0013.
-
Zash
XEP-1300
-
Kev
Stripping a small part of a spec out into another spec is not without precedent.
-
Ge0rG
Why not removing all the unneeded parts of 0013?
-
Sam
That does seem like an easy temporary solution until bind2 or whatever is a thing. Probably worth discussion others first though in case there's a good permanent solution that can be done now-ish.
-
Sam
Removing other parts of 0013 feels wrong to me, but I can't really think why. It's sort of a Ship of Theseus problem I guess: when is it a new XEP and therefore should have a new number?
-
Sam
But I don't really care either way.
-
jonas’
my argument against removing '13 is how indiscoverable old XEP versions are
-
jonas’
someone who has to deal with an implementation based on '13 would have a hard time figuring out what the heck is going on
-
daniel
If we externalize it I'd really like to include the conditional part
-
Sam
jonas’ if we mark 13 as superseded by whatever the new thing is, wouldn't that add a link and make it easier?
-
Kev
daniel: “the conditional part”?
-
daniel
Purge only if mam preference is set to always
-
Zash
jonas’, for the general version discovery problem, could the xep xslt be tweaked to link to the attic?
-
daniel
Or at least not to never
-
daniel
Then I don't have to do the conditional part on the client side
-
daniel
This would allow me to properly pipe line it
-
Ge0rG
daniel: that's an excellent suggestion, except when offline history goes longer than MAM
-
Ge0rG
So my one day too late feedback for MAM has become a very long email in which I try to solve World Peace, it seems.
-
daniel
> daniel: that's an excellent suggestion, except when offline history goes longer than MAM fair but i still take that over a blind purge
-
Kev
World Peace is why I’m in no particular rush to advance MAM, FWIW, but am in a rush to get implementation experience of Bind2 and MIX and the like. Because although I appreciate the dangers of second system, so many things are subtly (or sometimes not) broken around what we currently have that we keep having bits that never fit together for a jigsaw.
-
Ge0rG
Kev: yeah, we are kludging workarounds for workaround for designs from twenty years ago
-
Kev
I am not for a moment suggesting we bin everything and start again. But I am suggesting at some point there’s value in fixing stuff.
-
Sam
Maybe I'll add a "Towards XMPP 2.0" roundtable discussions to office hours for the week afte rnext
-
Ge0rG
Office hours collides with private appointments for me, but the alternative slots collided with business appointments, so I didn't even submit the form.
-
Sam
Ge0rG: it's not a strict time, just a "default" time (since I think there's some value at it mostly being consistent every week). If you want to present or something feel free to add a different time in the signup sheet.
-
Ge0rG
Sam: I'm spending my days with a headset and I'm really glad to be able to go and do some garden work after that
-
Sam
Ge0rG: I know the feeling. Despite the fact that this season I haven't even started my garden and now I desperately need to run to the Feed & Seed and try to get something established before it's too hot
-
Ge0rG
Also I'm not sure what I'd present, except for my "what's wrong with xmpp in 2017" talk with very minor changes.
- Zash looks out over the remaining snow
-
Sam
Ge0rG: a demo of yax.im (or new features in yax.im or whatever) might be good
- Ge0rG is standing in the queue at the ice dealer
-
Ge0rG
...wearing a t-shirt
-
Sam
But also that what's wrong with xmpp talk would be a good one
-
Ge0rG
I'd probably break out in tears because so little changed since 2017
-
Sam
That would make a great presentation! You could win an Oscar!
-
Ge0rG
Well, MattJ has done much better work on easy invitations than what I pioneered in yaxim back then
-
Sam
That would still be a great thing to demo, even if you didn't write it.
-
daniel
> Maybe I'll add a "Towards XMPP 2.0" roundtable discussions to office hours for the week afte rnext I'd join that discussion
-
daniel
I have thoughts