what does an extend MAM metadata response look like for empty archives?
Daniel
and is it different from disabled archived?
projjalmhas joined
MattJ
It's on my specs to-do to clarify this: https://logs.xmpp.org/jdev/2023-01-16?p=h#2023-01-16-3eedf318e3ba95f6
Zash
MUST? Prosody violates this then.
MattJ
In which cases?
Zash
Empty archive
MattJ
Right
archas left
Zash
It would return just <metadata/>
MattJ
I think we just need to clarify "if the archive is not empty"
Daniel
empty metadata sounds good to me though
MattJ
I'll write that email now
MattJ
or... just get back into XEP mode and write a PR
Daniel
I think it should also spec that specific case too. instead of returning an error or so
Zash
one could possibly argue for item-not-found as well
Daniel
not merly allow empty metadata but say thats how it's supposed to be i mean
MattJ
As I noted in the above chat, I prefer empty to error, partly because <metadata> is also used in bind2
jcbrandhas left
jcbrandhas joined
Daniel
yes. and we should make it distinct from archive is broken or not enabled
MattJ
Right, what does it mean for an archive to be "disabled"?
MattJ
Wouldn't you just have service-unavailable then?
MattJ
and no disco feature
MattJ
and no <metadata> in bind2
Daniel
mhhh I don’t know. server supports it but user has it disabled
Zash
broken? internal-server-error?
Daniel
that would probably still have the feature?
Zash
disabled in user preferences?
MattJ
internal-server-error is wrong if it's intentional (internal-server-error could imply that trying again might work)
Daniel
anyway. i haven’t full thought through all the edge cases yet. but I think we already concluded that empty element is the right way to go; independently of how corner cases are handled
Zash
> archive is broken or not enabled
clarify what those terms mean here?
Daniel
but I was just thinking that on empty metadata will start my MAM-id tracking on the client side. and any sort of error would lead me to try again on the next login
Daniel
yes i mean disabled by user preference
MattJ
I think it should just be missing from disco features then
Otherwise I'm not sure what the difference is (or how to signal) between "not supported so it doesn't work" or "disabled so it doesn't work"
MattJ
or why that distinction is useful to have
Zash
Buuut doesn't disabled just mean no _new_ messages are added to the archive, but there still could be some that you could query for?
Zash
I don't think we defined that disabling archiving would wipe it (yet)
MattJ
I don't think we want to go down that road
MattJ
We could, but I don't see a use-case for it
MattJ
Removing disco features when MAM is disabled is reasonable and backwards-compatible
MattJ
Because claiming to support MAM when actually no MAM operations will succeed is silly
Zash
So disabled := default==never AND always:empty() AND never:empty() ?
MattJ
Maybe
MattJ
I don't like that options protocol though, and I'd like to retire it
Zash
in XEP-0441 terms
SteveFhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
nicomuchas left
SteveFhas left
Martinhas joined
nobodyhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
Titihas joined
archas joined
SteveFhas left
goldbeardphas left
SteveFhas joined
SteveFhas left
SteveFhas joined
pep.
if disco is removed from my account, how do I know I can reenable it? Because it's supported by the server?✎
pep.
if disco is removed from my account, how do I know I can reenable it? Because it's enabled on the server? ✏
SteveFhas left
marc0shas left
Skull Fuckerhas left
marc0shas joined
archas left
atomicwatchhas left
MattJ
You re-enable it through whatever protocol you disabled it
SteveFhas joined
SteveFhas left
Mikaelahas joined
pep.
who is "you"
MattJ
the account owner
archas joined
MattJ
The same "my" from your message
marc0shas left
marc0shas joined
pep.
I mean which client. How does the client know
marc0shas left
marc0shas joined
MattJ
The same way it knew how to disable it
pep.
Ok I'm missing something that seems obvious to you. The disco feature is different?
Zash
But if that way goes away if you disable it, how does it know it's still there?
my-namehas left
my-namehas joined
MattJ
What goes away?
MattJ
The configuration protocol?
pep.
The disco feature
MattJ
Only the MAM disco feature would go away
pep.
https://xmpp.org/extensions/xep-0441.html there doesn't seem to be a disco feature here
MattJ
Oh, XEP-0441
MattJ
Two things:
MattJ
1)
> I don't like that options protocol though, and I'd like to retire it
SteveFhas joined
MattJ
2) It's not clear that setting it to 'Never' and having nobody in your 'always' list is the same as actually disabling MAM entirely
MattJ
Nothing has changed in that regard
pep.
But that doesn't conflict with what I'm asking :p
MattJ
I don't think you can fully "disable MAM" via XEP-0441, I don't think it can/should remove the disco feature (because then yes, you lose the ability to configure MAM)
pep.
Ok
MattJ
I don't think XEP-0441 should continue to exist, and I intend to remove it from Prosody in the future
pep.
So what is the "configuration protocol" you're talking about
MattJ
It doesn't yet exist
pep.
Ok
MattJ
Prosody doesn't allow you to disable MAM on a per-account basis, or remove the disco feature
pep.
No wonder I was configured
MattJ
As far as I'm concerned, all this is hypothetical
SteveFhas left
SteveFhas joined
Andrzejhas joined
SteveFhas left
MattJ
Rather than the options XEP-0441 gives you, I'd rather switch to something that allows someone to control the retention settings, and remove support for the per-JID stuff (which has the ability to break things in unexpected ways)
MattJ
We also need to add an in-band way for someone to purge their archive
Zash
Also might let you do funky things like include MUC PMs in MAM :D
SteveFhas joined
SteveFhas left
SteveFhas joined
SteveFhas left
SteveFhas joined
marc0shas left
marc0shas joined
Half-Shothas left
Matthewhas left
homebeachhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
goldbeardphas joined
marc0shas left
marc0shas joined
Mikaelahas left
Mikaelahas joined
stphas joined
edhelashas joined
Dele Olajidehas joined
marchas left
marchas joined
marchas left
marchas joined
con3has joined
*IM*has left
tbm16has left
my-namehas left
*IM*has joined
Dele Olajidehas left
con3has left
my-namehas joined
my-namehas left
my-namehas joined
stphas left
my-namehas left
my-namehas joined
my-namehas left
my-namehas joined
Mikaelahas left
Mikaelahas joined
con3has joined
konstantinoshas left
con3has left
Hugohas joined
stphas joined
Vaulorhas left
Vaulorhas joined
my-namehas left
my-namehas joined
SteveFhas left
my-namehas left
my-namehas joined
flowhas left
flowhas joined
antranigvhas left
Mikaelahas left
Vidakhas left
my-namehas left
my-namehas joined
Andrzejhas left
larmahas joined
antranigvhas joined
my-namehas left
my-namehas joined
my-namehas left
my-namehas joined
con3has joined
marc0shas left
marc0shas joined
Andrzejhas joined
con3has left
marc0shas left
marc0shas joined
catchyhas joined
SteveFhas joined
raucaohas left
raucaohas joined
tbm16has joined
my-namehas left
my-namehas joined
my-namehas left
my-namehas joined
lskdjfhas joined
marc0shas left
marc0shas joined
konstantinoshas joined
Andrzejhas left
Vidakhas joined
tbm16has left
singpolymahas left
singpolymahas joined
BASSGODhas left
raucaohas left
raucaohas joined
SteveFhas left
Andrzejhas joined
stphas left
singpolymahas left
singpolymahas joined
BASSGODhas joined
SteveFhas joined
Calvinhas joined
my-namehas left
my-namehas joined
my-namehas left
my-namehas joined
my-namehas left
my-namehas joined
my-namehas left
my-namehas joined
archas left
archas joined
neshtaxmpphas left
neshtaxmpphas joined
singpolymahas left
singpolymahas joined
qyhas left
my-namehas left
my-namehas joined
Mikaelahas joined
tbm16has joined
jcbrandhas left
jcbrandhas joined
singpolymahas left
deimoshas left
deimoshas joined
qyhas joined
tbm16has left
tbm16has joined
singpolymahas joined
Andrzejhas left
my-namehas left
Dele Olajidehas joined
qyhas left
qyhas joined
my-namehas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
millesimushas left
SteveFhas left
my-namehas left
my-namehas joined
SteveFhas joined
marc0shas left
marc0shas joined
goldbeardphas left
Fishbowlerhas left
Fishbowlerhas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Wojtekhas joined
Steve Killehas left
Daniel
MattJ, just for my understanding, mam’s before-id and after-id are inclusive (the stanza referenced as after-id is included in the results) buf rsm after/before are exclusive, no?
marc0shas left
marc0shas joined
Zash
What?
Zash
I thought before-id and after-id was a trick to let you have both after and before in RSM
Zash
Thus same semantics
Zash
Except for the ordering implications of before
Daniel
the XEP says they are (in some scenarios) interchangable
Daniel
but what i'm trying to get at is that i'm suspecting they maybe aren’t
Daniel
after-id: A stanza ID indicating the first message in the query results.
Daniel
this means inclusive, no?
Steve Killehas joined
MattJ
Umm, I think that is wrong
Daniel
i mean they kinda have to be inclusive. because when I retrieve a metadata and then do a query for after-id=metadata.start and before-id=metadata.end I want start and end in the result
Daniel
obviously
Zash
How did you come to that kind of reasoning?
Daniel
but rsm because it is a paging thing needs to be exclusive or otherwise page A and page b would have overlapping entries
MattJ
To fetch everything you don't specify any before/after
Fishbowlerhas left
Fishbowlerhas joined
Daniel
so the intent is that they are exclusive?
MattJ
Yes
Dele Olajidehas left
asterixhas left
asterixhas joined
Daniel
ok; suppose I’m catching up. I know my last local MAM id is `23`. I retrieve the metadata (or get it via band2) and learn the the current end is `42`. then I’m doing a query for anything between 23-42
Daniel
i want the 42 to be included, no?
MattJ
You do. You run a query for after-id=23
MattJ
You don't include before-id
sebastianhas left
Daniel
what does that metadata thing do then?
Zash
But then you may run into live messages?
sebastianhas joined
millesimushas joined
MattJ
The metadata thing is informational, for example it can be used to determine when there are gaps
Zash
Can it?
MattJ
Since start/end are implicit in any query, you don't need to actually insert those things into filters
Zash
Due to being away for a long time, so the server expired previous overlap?
MattJ
Yes
Daniel
ok... I thought it could be used to put an upper bound to my catch-up query
MattJ
You would use your last local id for that, no?
Daniel
that’s the lower bound
Zash
So, If the <start> is *not* in your local database, then you have a gap. Probably.
tmolitor
Daniel is ordering the bounds by timestamp in ascending order ;)
Zash
That is *wrong*. Don't do that.
Zash
Timestamps are bad, mkay!
MattJ
I think it was a comment on Daniel's use of "upper" and "lower" in this conversation (which is logical), hopefully not on database schema
Daniel
ok forget upper and lower. but I thought i could limit it on both sides
tmolitor
yes, like MattJ said :)
Zash
You could query with after-id=your last local message, <{rsm}before/> and page backwards until you don't want to anymore
Zash
That would get you the latest new messages first
Zash
Except thanks to OMEMO, that's totally useless, innit?
Daniel
my question isn’t about the order of messages
resolihas joined
yushyinhas left
Zash
Daniel, upper bound on number of messages to retrieve? that's what I answered. query backwards from most recent. Then you can bound the result at any point by stopping.
MattJ
No, that's also not what Daniel is asking for
Zash
Then I have no idea what anyone is talking about
yushyinhas joined
Zash
And I probably won't understand without a whiteboard
MattJ
It's just that there is no way to form a MAM query that says "get me the archive contents as they were when you sent me the <metadata>"
yushyinhas left
Zash
No inclusive id fields no
Zash
except ids
MattJ
You have to have an open-ended query, and as you put it earlier, deal with the possibility that you might "run into live messages"
yushyinhas joined
yushyinhas left
MattJ
But you can just stop querying after you find the message with the id
MattJ
The end id, I mean
yushyinhas joined
Zash
or do a query based on the meta, then ids={start, end}
adiaholichas left
Andrzejhas joined
tbm16has left
resolihas left
MattJ
Yes, that's one way :)
MattJ
Pity we didn't define 'ids' to be additive
MattJ
That would solve this relatively cleanly
singpolyma
Sortable uuids!!
MattJ
and it doesn't generally make sense to combine it with other filters
Zash
singpolyma, orthogonal, but nice
MattJ
Yes, if designing from scratch I probably would have mandated sortable ids
lskdjfhas left
Tobiashas left
lskdjfhas joined
goldbeardphas joined
Tobiashas joined
Dele Olajidehas joined
lskdjfhas left
lskdjfhas joined
singpolymahas left
singpolymahas joined
Tobiashas left
Tobihas left
goldbeardphas left
Tobihas joined
Tobiashas joined
petrescatraianhas left
inkyhas left
resolihas joined
djorzhas left
petrescatraianhas joined
inkyhas joined
snowhas joined
adiaholichas joined
catchyhas left
catchyhas joined
snowhas left
asterixhas left
asterixhas joined
flashcorehas left
antranigvhas left
konstantinoshas left
neshtaxmpphas left
neshtaxmpphas joined
asterixhas left
asterixhas joined
miruxhas left
miruxhas joined
resolihas left
qyhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
snowhas joined
atomicwatchhas joined
atomicwatchhas left
qyhas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
singpolymahas left
singpolymahas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
marc0shas left
marc0shas joined
atomicwatchhas joined
atomicwatchhas left
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
atomicwatchhas joined
Tobiashas joined
atomicwatchhas left
Tobiashas left
Tobiashas joined
con3has joined
Tobiashas left
Tobiashas joined
con3has left
Guus
https://xmpp.org/schemas/ does not appear to hold a schema that defines the http://jabber.org/protocol/compress/exi namespace, although https://xmpp.org/extensions/xep-0322.html links to http://xmpp.org/schemas/exi.xsd (and even has a byte size and hash for that file). Does anyone know where that file disappeared to?
Tobiashas left
Tobiashas joined
Guus
I have a project that contains a XEP-0322-01.xsd, but that's clearly outdated.
singpolymahas left
sonnyhas left
singpolymahas joined
Ge0rG
something something xmpp protocol registry
atomicwatchhas joined
atomicwatchhas left
Guus
wut?
BASSGODhas left
Tobiashas left
antranigvhas joined
Tobiashas joined
Tobiashas left
Tobiashas joined
sonnyhas joined
snowhas left
bhavyhas left
my-namehas left
bhavyhas joined
my-namehas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
my-namehas left
my-namehas joined
marc0shas left
marc0shas joined
Dele Olajidehas left
Tobiashas left
Tobiashas joined
lskdjfhas left
antranigvhas left
Guus
https://github.com/joachimlindborg/XMPP-EXI/blob/master/exi.xsd seems more up to date - but I'm not sure if it is the most recent version
Tobiashas left
atomicwatchhas joined
atomicwatchhas left
Tobiashas joined
Guus
It's not of a size that's equal to what's listed in the XEP. :/
catchyhas left
catchyhas joined
atomicwatchhas joined
atomicwatchhas left
antranigvhas joined
antranigvhas left
flashcorehas joined
atomicwatchhas joined
atomicwatchhas left
antranigvhas joined
marc0shas left
marc0shas joined
antranigvhas left
lbocquethas left
lbocquethas joined
antranigvhas joined
atomicwatchhas joined
atomicwatchhas left
antranigvhas left
antranigvhas joined
antranigvhas left
Tobiashas left
goldbeardphas joined
antranigvhas joined
wladmishas left
wladmishas joined
atomicwatchhas joined
atomicwatchhas left
singpolymahas left
singpolymahas joined
lbocquethas left
lbocquethas joined
atomicwatchhas joined
atomicwatchhas left
Tobiashas joined
L29Ahhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
Tobiashas left
Tobiashas joined
Peter Waher
The contents of the file would be what is available in section 7 of the XEP.
Peter Waher
Perhaps white-space might be different however
Dele Olajidehas joined
atomicwatchhas joined
Tobiashas left
atomicwatchhas left
Tobiashas joined
antranigvhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
antranigvhas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
Kevhas left
goldbeardphas left
Guus
Thanks Peter. Sucky for hashing, but at least i've got the namespace and element names right this time ... :)
Wojtekhas left
atomicwatchhas joined
atomicwatchhas left
Guus
Peter Waher: am I right to assume that https://xmpp.org/extensions/xep-0322.html#defaultSchema should not be referencing 'xep-0322-01.xsd' but 'exi.xsd' instead (as that's the name used in the XSD listing)?
atomicwatchhas joined
atomicwatchhas left
djorzhas joined
atomicwatchhas joined
atomicwatchhas left
lskdjfhas joined
antranigvhas left
antranigvhas joined
SteveFhas left
Andrzejhas left
neshtaxmpphas left
Andrzejhas joined
nicolahas left
neshtaxmpphas joined
antranigvhas left
larmahas left
larmahas joined
nicolahas joined
marc0shas left
marc0shas joined
atomicwatchhas joined
konstantinoshas joined
lbocquethas left
atomicwatchhas left
antranigvhas joined
antranigvhas left
antranigvhas joined
stphas joined
antranigvhas left
antranigvhas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
Yagizahas left
Joininghas joined
Joininghas left
mentos124has joined
Axel R.has joined
atomicwatchhas joined
atomicwatchhas left
Alex
sorry guys I was stuck in traffic, will start the member meeting shortly
Alex
just need to update the agenda quickly
Rebeldhas joined
arcxihas left
atomicwatchhas joined
atomicwatchhas left
singpolymahas left
atomicwatchhas joined
atomicwatchhas left
Trunghas left
Trunghas joined
Alex
okay, anyone ready?
singpolymahas joined
Guus
ack
neoxis here '-'
nicola
Here I am
Alex
okay
Andreas H.has joined
Alexbangs the gavel
Alex
here is our agenda for today:
https://wiki.xmpp.org/web/Meeting-Minutes-2023-03-09
Alex
1) Call for Quorum
atomicwatchhas joined
atomicwatchhas left
Alex
as you can see 41 members voted via memberbot. So we have a quorum
Peter Waher
Guus: It should reference a snapshot directory with agreed-upon default versions of schemas. In the current version, the -01.xsd corresponds to the exi.xsd file. The extension takes into consideration the gradual evolution of extensions and corresponding schemas. But you’re correct: We can remove the -01 from the file name in the schemaLocation specification.
Alex
2) Items Subject to a Vote
antranigvhas left
atomicwatchhas joined
atomicwatchhas left
Alex
new and returning members, you can see all the applications here:
https://wiki.xmpp.org/web/Membership_Applications_Q1_2023
Alex
3) Opportunity for XSF Members to Vote in the Meeting
Alex
any XSF member here who has not voted yet and wants to do so now?
Alex
Memberbot is still online
Axelhas left
Alex
looks like there is none
atomicwatchhas joined
atomicwatchhas left
Alex
then I will shutdown memberbot and start counting
atomicwatchhas joined
atomicwatchhas left
Vidakhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
antranigvhas joined
atomicwatchhas joined
atomicwatchhas left
antranigvhas left
Alex
still counting ...
antranigvhas joined
antranigvhas left
con3has joined
nicomuchas joined
Zash
🥁️
con3has left
neox
👀
antranigvhas joined
antranigvhas left
Alex
getting there, final check ;-)
Arne
yea🎉
Alex
4) Announcement of Voting Results
atomicwatchhas joined
atomicwatchhas left
Alex
when you reload the page at:
https://wiki.xmpp.org/web/Meeting-Minutes-2023-03-09
you can see the results
Alex
except of 1 candidate everyone got accepted
djorzhas left
Alex
congrats to everyone, big list of candidates this quarter
Seve
Congratulations, I count on you when my reapplication time comes! Thank you Alex!