say im sending a join presence to the room, and before the room sends me the roster i send a unavailable presence
lovetox
should the server still send the roster?
lovetox
can i leave a room when im not fully joined?
lovetox
is probably the question
lumihas joined
eevvoorhas joined
Holger
lovetox: You can of course send the unavailable presence before being "fully joined", but must expect traffic from the room until you got the unavailable response back.
lovetox
yeah i know that the server probably queues the presences before he receives my unavailable and can not remove presences from the queue in time
lovetox
but does ejabberd even try?
debaclehas joined
lovetox
i think about this, because when entering a room with a captcha
lovetox
server sends no roster until captcha is solved
lovetox
so it should respect my unavailable if i cancel the captcha challend✎
Holger
If I understand you correctly then the answer is no. ejabberd just receives requests and responds to them. You want it to double check whether there's another request before responding to the first one? That would seem wrong to me.
lovetox
so it should respect my unavailable if i cancel the captcha challenge ✏
Holger
Ahh, so the story is kinda different.
lovetox
ejabberd does not respect unavailable within a captcha flow, also not captcha canel message
lovetox
instead it has a 1 minute timer
lovetox
that sneds a presence error when the captcha is not solved in that time
lovetox
but i wonder if i should care ..
lovetox
i dont think it causes any problems ..
lumihas left
Holger
lovetox: Shouldn't the client abort the CAPTCHA thing as per XEP-0158, in that case?
Holger
> The sender's client MUST respond with a <not-acceptable/> error in any of the following cases: [...] if the sender declines the challenge
lovetox
i do this, but as i said above, it does not have any effect on ejabberd
Holger
Ah "also not captcha cancel message", overlooked that.
lovetox
what i would expect is, after cancel to get a presence error type=auth or something
Holger
Yeah that sounds wrong to me.
Holger
Yup.
Holger
Who does room CAPTCHAs anyway ;-)
lovetox
yeah so now i get the presence error 40 seconds later because it runs into the timeout
Holger
But yes maybe post an issue if you're motivated ...
lovetox
i dont see any problem getting it later though
lovetox
i dont see how that delayed error would cause any problem
zachhas left
zachhas joined
lovetox
its basically a nitpick at this point :)
Holger
Yup but I guess you're right.
murabitohas left
murabitohas joined
lumihas joined
igoosehas left
igoosehas joined
goffihas joined
Ge0rG
First I was thinking about the ugly workaround where you send a presence-unavailable _right before_ you join the MUC, to make the server realize that you acutally are joining it and not just updating your existing presence.
Holger
XMPP at its best.
Link Mauve
Holger, that’s been fixed, but some servers still don’t implement MUC 1.29. :(
Link Mauve
Damn, two years ago already.
Ge0rG
no servers implement Carbons 0.13
Kev
Well, in fact XEP-0045 was always written that way.
Ge0rG
Life is sad.
Kev
Just that 1.29 made it clearer.
Kev
Ge0rG: I have a server implementation, including the extra namespace.
Ge0rG
Kev: is it public?
Kev
No, it'll appear in a future M-Link release, it's not released yet.
Holger
Ge0rG: Oh I missed that. I'll add that to ejabberd.
Ge0rG
Kev: will that release be running on jabber.org? :D
Kev
Not unless Peter changes his mind :)
Ge0rG
Holger: would you come with pitchforks and torches if I also mandate forwarding of message errors?
Ge0rG
BTW, I'd like to make message errors non-ephemeral in general, so that they end up in MAM and in Carbons.
Ge0rG
are server developers going to kill me for that?
Holger
Right, I was going to mention that the rules for MAM + Carbons should be in sync for such things, otherwise I wouldn't quite see the point.
eevvoorhas left
Ge0rG
Holger: I've been asking that for years now
Holger
Other than that I tend to be on the "store everything" side of the fence, so I for one won't kill you. Plus you live too far away now anyway.
Holger
Ge0rG: I know. It's not like I objected ;-)
Ge0rG
> it is of type "error" and it was sent in response to a <message/> that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
Ge0rG
Holger: this part of the new 0280 rules was heavily objected
Holger
Ge0rG: I mean for some things there are probably better solutions than cluttering the DB. But cluttering is better than what we have now.
Ge0rG
It's generally not forbidden to CC _every_ message error, and I'm not even sure it would be harmful
goffihas left
zachhas left
zachhas joined
zachhas left
zachhas joined
Ge0rG
CCing message errors from a MUC might be interesting, though.
adityaborikarhas left
adityaborikarhas joined
rionhas left
rionhas joined
eevvoorhas joined
Holger
Indeed.
adityaborikarhas left
marc_has left
marc_has joined
sezuanhas left
sezuanhas joined
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
Chobbeshas joined
sezuanhas left
sezuanhas joined
sezuanhas left
sezuanhas joined
goffihas left
goffihas joined
alameyohas left
alameyohas joined
eevvoorhas left
stpeterhas joined
alameyohas left
Guushas left
stpeterhas left
evehas left
evehas joined
Guushas joined
alameyohas joined
zachhas left
adityaborikarhas joined
eevvoorhas joined
eevvoorhas left
Lancehas joined
Chobbeshas left
adityaborikarhas left
adityaborikarhas joined
ralphm
I'm on the road, but will try to follow the board meeting
stpeterhas joined
Lancehas left
MattJ
o/
Seve
Hi MattJ
MattJ
Guus?
Guus
here!
MattJ
Does someone else want to chair? I'd like to unvolunteer myself this week if that's ok
Guus
Seve, you want to have a go?
Guus
is @nyco not here?
MattJ
Apparently not
Guus
Seve?
Guusreaches for the gavel....
Seve
Sorry :)
Seve
I'm fully back now
Guus
please act as our chair if you want to. 🙂
Seve
Let's go
Seve
Welcome
MattJ
<3 Seve
Seve
I guess it's three of us, MattJ, Guus and me
goffihas left
Guus
with Ralph on the backburner.
Seve
Do you have something to add to the agenda?
Guus
I don't have anything to add ot the agenda.
Seve
1. Minute taker
Any volunteers? :)
Steve Killehas joined
MattJ
Nothing here (not sure if Peter's financials email is a worthy topic?)
MattJ
I can minute
Seve
That's awesome, thanks MattJ !
Seve
Nothing to discuss from me on that topic at least
Guus
I don't have anything to discuss on Peters email, other than "thank you Peter for the update."
Seve
Indeed
Guus
I'd be happy to discuss it if others feel there's soemthign to be discussed.
Guus
I sense that's not the case though? 🙂
Seve
Doesn't look like. If not, we can always take it again or via email
Seve
2. Commitments
Seve
"Follow-up on feedback & create poll for Compliance Suite Badges"
Seve
Being Nyco away, I guess we can skip this one for now
Steve Killehas left
MattJ
wfm
Nekithas left
Seve
"Review of Roadmap page"
Ralph mentioned he would send an e-mail to Council, but since he is also half/half, we will have to skip this one as well, as there are no any other news on this
Seve
as far as I know
peterhas joined
Guus
(Did you skip the 'topics for decisions' lane on purpose?)
Steve Killehas joined
Steve Killehas left
Seve
Yes, since they were both away :)
Seve
Now let's move onto
Seve
3. Topics for decisions
Guus
ah ok 🙂
Seve
"Vote on https://github.com/xsf/xmpp.org/pull/588"
The pull request was resolved, but we wanted to discuss about the "underlaying" issue, is that right, Guus? :)
Guus
right
Seve
There were some things to clarify, if I remember correctly. Or at least MattJ and me had some doubts about what were we going to vote on.
MattJ
Right :)
Seve
Do we want to clarify this and vote on the next meeting with the rest of the Board?
Guus
I'd prefer to do it now.
Guus
we have quorum, and we're not being very effective as-is.
Ge0rG
the question was, who should be responsible for evaluating non-maintainer updates to the lists
Ge0rG
Board or Editors.
Guus
I think we phrased that as "Should non-maintainers be allowed to ask for a project listing renewal?"
Ge0rG
Guus: this is a misleading question. Everyone can ask something.
Guus
Ge0rG - I thnk you're asking a different question.
pdurbinhas left
Ge0rG
Guus: the relevant question is what process happens if a non-maintainer asks.
MattJ
No, I think Ge0rG is asking a very slightly different but actually strongly-linked question which is the most relevant one here
Guus
I'd like to avoid having different processes, based on who authored the PR.
MattJ
I'm fine with that, it doesn't necessarily mean there have to be two processes
Ge0rG
Guus: in that case, the relevant question is, how is the process supposed to work if *anybody* asks for renewal
Ge0rG
the status quo is: editors reject if a non-maintainer asks, accept if a maintainer asks.
Guus
that's not the status quo
Ge0rG
or maybe: editors escalate to Board if a non-maintainer asks, accept if a maintainer asks.
peterhas left
Ge0rG
Guus: that was the status quo I tried to establish, I obviously can't know how it is lived by the Editors.
Guus
I'm not an editor, yet do much (most?) of the website PR merging.
Ge0rG
what is the right term then?
Guus
There's a lack of a specific role, other than "who-ever has been granted the power to merge" by a process that, as far as I know, non-existing.
waqashas joined
Ge0rG
"web team"?
Seve
If it is a matter of checking the projects being renewed or introduced, I don't mind volunteering for that.
MattJ
I don't know if we're entirely clear on what "checking" means, are we?
MattJ
which is part of the problem
Guus
The github team that appears to have that power is 'web', so 'web-team' works for me - although the term implies that this is a XSF workgroup, which I don't think it is
Seve
MattJ, exactly
Guus
I strongly feel that we're making to much of this.
Guus
I want to steer away of all of this complexity.
MattJ
I think we have three options: 1) accept all requests 2) accept requests based on some objective criteria we can assess 3) just decide on a case-by-case basis
MattJ
and I think everyone currently has different notions of what the ideal and the status quo are from this list
Guus
Agreed.
Guus
also: the definition of what is ideal is not something we'll agree upon, without much more discussion, I fear.
MattJ
we == Board, or we == community (Ge0rG)? :)
Seve
I would go for option 3, that gives us a way to keep understanding what to do :)
Guus
The more, the merrier 😃
jubalhhas joined
Guus
In option 3, who does the deciding?
jubalh
Cisco jabber = XMPP? Or were there changes ?
MattJ
Well, it's currently us, it seems
Seve
I would say Board until something is cleared out
Guus
(basically, the 'web-team' now does that, which effectively has the outcome of option 1)
jubalh
I'm getting a bugreport from a user using Cisco Jabber server. And wonder whether the server could actually be the reason
waqas
Do we have a well-defined purpose of the list (I'm just opening the page to see if we have something on top, but its taking forever for the server to respond)?
waqas
Ah, timed out with "504 Gateway Time-out"
Guus
jubalh mind postponing that until after the board meeting?
jubalh
oh so sorry
MattJ
jubalh, we are currently in a meeting which will end soon - maybe ask in jdev@conference.jabber.org or wait for a bit :)
jubalh
I'll wait
Guus
thanks
MattJ
waqas, I think we pretty much all agree that the old list was terrible by all metrics
Ge0rG
I'm for 2) with the objective criterion being "the PR author claims to be a maintainer of the project"
MattJ
So the goal we can all agree on was weeding out unmaintained software from the list
Guus
I'd not be to happy with board to have to decide on every change / renewal request.
Seve
What if we allow everybody to ask for renewal, and I contact maintainers of each project to ask for confirmation? If this helps us moving on :)
Guus
I'm not seeing with what the 'maintainer' requirement does for the quality of the list - other than prevent others from changing (mostly improving) it.
Seve
Although I would love maintainers care of it enough to appear on the list instead
MattJ
I'd love to just move to Link Mauve's magic DOAP project in the near future, when it's ready
MattJ
Which is something to consider - even manual validation may only be a short-term thing
Ge0rG
Guus: others "improving" the list leads to sub-par clients becoming visible
Guus
Ge0rG yes. Overall, it'd still be an improved list though.
Ge0rG
Guus: we've had pidgin, astrachat and empathy on that list
Ge0rG
Guus: not improved in comparison to the process that web-team isn't adhering to
Guus
"improved enough" for me though.
Guus
All other overhead is frankly not worth it, in my opinion.
MattJ
I propose the following: web team auto-accepts if maintainership can be verified, defers to Board if it can't
Ge0rG
Guus: Seve just volunteered to take over the overhead. I'd do so too.
Guus
I think we've sufficiently exchanged the same arguments for two weeks now though 🙂
MattJ
and long term, we replace it with an automatic solution
Ge0rG
Speaking of overhead: it _is_ a significant overhead for a user to install a sub-par client, and to only later realize that it's not working. Or even worse: not to realize it at all and blaming XMPP instead.
MattJ
As much as I'd like to trust in people being sensible, it only takes one person to submit a list from Wikipedia which includes obsolete clients such as Exodus and Coccinella
MattJ
If we accept everything without question, it's not really curating the list in the way that we need to keep it clean
Seve
Exactly my thoughts
Chobbeshas joined
Guus
The list will, eventually, curate itself mostly.
MattJ
As nice and simple as that would be
MattJ
My feeling is that the majority of requests will come from obvious maintainers and take no effort to verify and merge
MattJ
and occasionally we'll have problematic requests that warrant a little bit of discussion (but not the amount of discussion we're dedicating to this)
ralphmhas left
MattJ
I wouldn't have wanted to turn away the recent PR we had, which clearly had quite a bit of effort put into it, even though it was non-maintainer
MattJ
But I also don't want to automatically accept everything just because someone submitted a PR
MattJ
PR doesn't automatically equal improvement
Guus
let's vote on this already
MattJ
On what exactly?
Guus
we're continuing to exchange the same arguments
Seve
We need a question to vote on first :) Which I'm not sure how to define yet
MattJ
> I propose the following: web team auto-accepts if maintainership can be verified, defers to Board if it can't
stpeterhas left
MattJ
How is this for starters?
Seve
Do you agree voting on that, Guus?
Seve
I'm fine with it
Guus
'verified' might be a bit ambiguous.
Guus
but I don't have an immediate alternative wording.
Ge0rG
as I said, in my eyes it's sufficient to ask the PR author in the PR whether they are a project maintainer.
Guus
but I'm fine with the gist of it.
MattJ
If the web team struggles with implementing this policy, we can talk - I doubt they will :)
MattJ
Chair, call the vote!
MattJ
Why did I volunteer to minute this gnarly discussion?
Seve
Let's vote
Seve
"Web team will auto-accept client renewal requests if maintainership can be verified. Otherwise, the request will be redirected to Board."
MattJ
+1
Seve
+1
Guus
-1
MattJ
:eyeroll:
Ge0rG
🍿
Guus
"a vote of the majority of the Directors present at a meeting in which a quorum is present shall be the act of the Board of Directors."
Seve
That's a green light then. Vote passes.
Guus
I read that as 'motion passed"
Seve
Yes
Guus
excellent. Let's move on. 🙂
MattJ
Amen
Seve
Hah :)
Seve
Since we have used more time than usually, do you want to stop here? I may not have more time today, unfortunately.
Guus
If you're leaving, we loose quorum anyways
Guus
so, sure.
MattJ
sgtm
Seve
Ok then
Seve
4. AOB?
MattJ
None here
Guus
nope
Seve
5. Date of Next
Seve
Next week, same time? :)
Guus
wfm
MattJ
+1
Seve
6. Close
Guus
Thanks!
Seve
Thank you guys for this meeting
MattJ
Thanks Seve, you're a star :)
Seveblushes
evehas left
evehas joined
Seve
Great to see we have come to a solution on that one
Guus
Yes, indeed.
Guus
I'd love for us to find a way to have much of these discussions outside of the scope of the meetings though
Guus
as they're eating up much of the meeting time.
Guus
which I think hurts our productivity further.
Guus
I'm unsure what would be an improvement. More adhoc discussions over XMPP in preparation of the meeting? More mailinglist discussions?
Seve
Yes, been thinking about that for a long time, I would like to use meetings for making things official, rather than actually knowing what do you guys think.
MattJ
I agree that would be ideal
MattJ
The meeting however is a good way to allocate time and focus on specific issues, ensuring we are all present for a productive discussion
MattJ
So I'm not sure it is easily replaced by simple votes
Ge0rG
allocate a second slot for discussion, on Mondays
Lancehas joined
Chobbeshas left
Chobbeshas joined
Guushas left
alameyohas left
alameyohas joined
Guushas joined
jubalhhas left
pdurbinhas joined
Chobbeshas left
Chobbeshas joined
alameyohas left
Guushas left
Guushas joined
alameyohas joined
pdurbinhas left
Lancehas left
adityaborikarhas left
Lancehas joined
sezuanhas left
ralphmhas joined
adityaborikarhas joined
wojtekhas joined
murabitohas left
murabitohas joined
debaclehas left
Guus
jonas’: mind testing muclumbus on conference.igniterealtime.org ?
On a side note: Ignite should be using default settings for encryption, as provided by Java. I generally assume that those provide a good balance between security and interoperability.
jonas’
not anymore
jonas’
and, no
jonas’
Java is known for not dealing well with DH key sizes ;)
Zash
It's the other way around, things have been accepting 1024-bit DH groups for compat with Java, but no more
Zash
The future seems to be ECDHE-only tho
jonas’
is it openssl 1.1 or debian which requires 2048 bits now?
ralphm
Also I would check that Java indeed has reasonable defaults. Not an assumption I would make.
Guus
If we don't seem this acceptable any more, then xmpp.net scoring should be adjusted.
jonas’
probably
Zash
Guus: " Server uses Diffie-Hellman parameters of < 2048 bits. Grade capped to B. " wasn't enough? It's been there for years
jonas’
Zash, maybe it should be capped to E now?
Guus
B is a pretty good score
Zash
I think this is Debian, but IIRC the browser folks are in on it
Ge0rG
The good thing about Java defaults is that they depend on the JRE version you are running.
We do use Java 8, I think. So that might warrant an upgrade.
jonas’
hm, I should load that hack Zash has about fetching security info of s2s connections on the server and let muclumbus scrape that kind of stuff. then I would lower the requirements and show nasty warning signs next to rooms which are on insecure servers :>
Guus
Hehehe
Guus
This is sooooo different from a conversation I had with a customer not to long ago
Zash
jonas’: https://gist.github.com/Zash/5946686 ?
Guus
They insisted that the password being equal to the username was safe.
jonas’
Guus, oh my god.
marc_has left
jonas’
Zash, probably
Guus
I'll see if we can switch Ignite to Java 11. I'd be interested in finding out what that does to the encryption parameters.
Guus
I wonder if this accounts for the issue we've had with contacting the ChatSecure push service
adityaborikarhas left
adityaborikarhas joined
sezuanhas joined
waqashas left
waqashas joined
adityaborikarhas left
adityaborikarhas joined
jonas’
given the name, not impossible
sezuanhas left
adityaborikarhas left
waqashas left
davidhas left
davidhas joined
rionhas left
rionhas joined
UsLhas left
Guus
> (I could’ve sworn that igniterealtime was once indexed, so that’s why it dropped off the index)
Without Muclumbus support?
Guus
jonas’: ^
jonas’
Guus, uuuh
jonas’
you weren’t talking about scraping igniterealtime for public MUCs, but about using the client against it
jonas’
yeah, I can’t do that either with those dh keys, but at least now I know what you want from me :D
Guus
There aren't many rooms on that particular domainto, but I wanted to test the scraping implementation that was built.
murabitohas left
murabitohas joined
jonas’
right, so, scraping with muclumbus as in search.jabbercat.org does not require server support beyond XEP-0045.
jonas’
the client thing is a different matter, it scrolled of of my mind’s backlog that you were about to implement that :)
jonas’
I think I have an account on yax.im, maybe I can connect using that
eevvoorhas joined
wojtekhas left
jubalhhas joined
Guus
Ah, I thought muclumbus was the scraping protocol used by jabbercat
Guus
Oh well. 🙂
jonas’
Guus, do you have a search term for me?
jonas’
where I’ll find something for sure?
jonas’
the reply I got (a) is empty and (b) lacks an <rsm/> element which makes my test client crash :)
searching for "openfire" or "smack" should give you a result ✏
Guus
You'd expect an error instead?
jonas’
Guus, an empty result is fine, but with <rsm/> element
jonas’
searching for open brings me bad-request
jonas’
(without further error code)
jonas’
same for open_chat
jonas’
Guus, here’s the full interaction in scs format (no, that’s not the actual password in there):
https://paste.debian.net/hidden/01b30c03/
Guus
tx
Guus
Openfire does not like <set xmlns="http://jabber.org/protocol/rsm"/>
jonas’
hm
Guus
eek, my client formatted that weirdly.
jonas’
mine did not
Guus
Hmm... This might be a bug in Openfire
Guus
it expects _all_ fields.
jonas’
all in rsm?
jonas’
I can’t give you *that*
jonas’
at most I’d give you a <max/> ;)
Guus
code is somewhat hard to read
jonas’
but setting <max/> helps already!
jonas’
I get a reply
Guus
it does expect a positive max value
Guus
and it cannot have non-specified fields...
Guus
seems to be pretty strict.
jonas’
Guus, it doesn’t return a <max/> value
Guus
I think I wrote this when I was in college 🙂
jonas’
interestingly, no example in XEP-0059 shows a server returning max
jonas’
so why do I require that :)
Guus
it indeed does not re... yeah, what you said. 🙂
jubalh
so I assume the meeting is over? :)
jonas’
Guus, I use it as break condition to figure out when the result set is done and I expect the page size used by the server to be in there...
Guus
jubalh yup - thanks for your patience 🙂
jubalh
no problems, I wasn't aware of the meeting, just joined and typed. so i realized it too late.
Guus
jonas` isn't 'count' more appropriate for that?
jonas’
more or less
Guus
jubalh no worries, no harm done
jonas’
fixing my code ;)
Guus
you're not the only one.
jonas’
wee
jonas’
it works
Douglas Terabytehas left
jonas’
when I explicitly set <max/> in my initial request, I get a proper reply
jubalh
I got a bugreport and I wondered whether Cisco Jabber is (still) XMPP and is also 100% compatible? bug report is this, and I thought maybe the server could be the reason https://github.com/profanity-im/profanity/issues/1165
jonas’
Guus, here’s a successful exchange for reference: https://paste.debian.net/hidden/f4671816/
Guus
I have no firsthand knowledge, but from what i've heard, it is not.
Lancehas left
jonas’
Guus, ^5
Guus
jonas’ thanks - max does not seem to be required by the XEP (even though it's in all examples, that's probably what threw many-years-younger-me off)
Guus
I'll see if I can make that optional in Openfire.
jonas’
Guus, in my implementation, <max/> is defaulted by the thing handling the RSM-modified request
jonas’
i.e. it’s a service-specific default
pep.
jubalh: probably not 100% compatible no
Guus
we have a validity check that simply insists it _must_ be present. that seems to be to strict.
pep.
When they report, make sure you also get debug logs with what their server sends
Guus
Sadly, it's in an upstream library, so updating this will take some time.
jubalh
pep., do you think that this bugreport could be due to that reason?
pep.
jubalh: ask for XML logs?
jubalh
will do
pep.
Is there an XML console in profanity or sth?
jubalh
there is, yes
jubalh
I'll ask him
pep.
K
murabitohas left
murabitohas joined
Douglas Terabytehas joined
Yagizahas left
ralphm
I think there is no explicit rule that says you can't send (repeated) `<presence type="subscribed"/>`, but I can see how that's annoying.
ralphm
A client could check against local state to prevent annoying the user.
Guus
ralphm that's in reply to what? (Am I missing context?)
pep.
Guus: not you
ralphm
jubalh's message above about Cisco Jabber
Guus
I didn't see him talk about presence subscribed though
Guus
or is that in https://github.com/profanity-im/profanity/issues/1165 ?
Guus
right, sorry.
ralphm
Yes
Guus
I've been working on an issue where occasionally, messages were not being delivered to a MUC
Guus
so I'm now jumping at instances where I appear to be missing messages (which is hard to detect, visually)
jubalh
ralphm, so if locally I already have the user tracked as subscribed I should ignore the incoming message subsribed?
murabitohas left
murabitohas joined
rionhas left
rionhas joined
eevvoorhas left
murabitohas left
murabitohas joined
Guus
how does one interpret an RSM request that defines both an 'index' element, as well as an 'after'?
ralphm
jubalh: I would
waqashas joined
jubalh
so basically this means looping through roster and seeing who i have subscribed if i'm not mistaken
murabitohas left
murabitohas joined
Dele (Mobile)has joined
Dele (Mobile)has left
ralphm
Looping? I assume your client has some local state for each contact/roster item, indexed by JID
jubalh
right sorry
jubalh
got it :)
ralphm
No worries
zachhas joined
waqashas left
waqashas joined
murabitohas left
murabitohas joined
Dele (Mobile)has joined
Dele (Mobile)has left
Dele (Mobile)has joined
Dele (Mobile)has left
murabitohas left
murabitohas joined
jubalhhas left
jubalhhas joined
Lancehas joined
murabitohas left
murabitohas joined
goffihas joined
peterhas joined
zachhas left
zachhas joined
stpeterhas joined
Link Mauve
“15:59:32 MattJ> I'd love to just move to Link Mauve's magic DOAP project in the near future, when it's ready”, I’d say it’s ready for project maintainers to start using, and for the XSF to start accepting; we don’t have all of the tooling yet, or not as integrated as I’d like, but that can come with time.
Link Mauve
I could update #594 to not include any tooling, and instead let authors progressively fill their DOAP entry upon renewal.
jubalhhas left
Douglas Terabytehas left
andyhas left
edhelashas left
edhelashas joined
zachhas left
zachhas joined
debaclehas joined
andyhas joined
sezuanhas joined
Lancehas left
wurstsalathas left
peterhas left
wurstsalathas joined
Lancehas joined
jubalhhas joined
stpeterhas left
flow
Guus, what's the motivation for allowing both <after/> and <before/> in tinder's RSM implementation? I think it is right now underspecified what this exactly means, as <after/> is used to page forward, and <before/> is used to page backwards, and hence should be avoided until this is clarified
Zash
That is indeed highly ambigous.
andyhas left
Guus
flow: it's currently not allowed, although I'm playing with code that could allow it. I was actually looking for feedback.
lovetox
what was this again for?
lovetox
paging backwards but the page is also reversed
lovetox
i guess
Zash
Prosody with SQL backend does allow it but I'd call it undefined behavior.
flow
I tend to believe that RSM should just disallow using <after/> and <before/> together
Actually I think Prosodys MAM code will allow it always, but some backends will ignore one of them and good luck figuring out which.
lovetox
its not mentioned in the XEP, nobody reading the XEP would ever get the idea that this is even possible
lovetox
there is no way you can discover that the server supports that "hack"
lovetox
so i dont see any client actually using that
flow
lovetox, ambigouty and implementation dependent behavior is always harmful to an protocol
Nekithas joined
lovetox
but its nowhere documented that this is even possible, and as you say undefined
flow
it is also not specified that it is impossible
lovetox
so its basically a feature some dev knows and can play with
flow
sometimes it is better to be explict
lovetox
sorry, its also not defined what happens if add <after> twice
lovetox
or if i add a element thats not even mentioned in the XEP
flow
that, at least, is disallowed by the schema
Zash
Schema validators hate it!
Zash
Something something this weird trick
lovetox
does it not follow that everything not mentioned in the XEP is *not defined*
flow
adding optional extensions is a common pattern for most elements in xmpp, I don't think you can compare it using existing elements in an unspecified way
flow
…compare it *with*
Zash
In the case of Prosodys SQL backend, `after` and `before` gets turned into SQL like `WHERE id > after AND id < before` altho after page size limits it'll behave like only 'before' was there.
lovetox
great Zash, only a madman would use this though
lovetox
or someone writing clients that only operate with prosody
Zash
Mostly because internal details like that the presence of `before` means it sorts the results backwards.
Zash
(and then it flips them around before returning as MAM results)
Guus
It'd be good to explicitly define expected behaviour or restrictions in the XEP.
Zash
I think other storage backends will simply ignore `after` if `before` is present
Guus
Changes in behaviour caused by an invisible implementation detail seems undesirable.
Zash
Having both `after` and `before` is UB, so what you gonna do?
zachhas left
zachhas joined
Zash
We could explictly forbid it since it makes no sense
lovetox
you talk like this happens per accident
Zash
As in, return some error stanza
Guus
Sounds good
Zash
It happens because the query and the data flow through two layers with slightly different API and semantics.
jubalhhas left
Zash
Well. Three layers if you count SQL.
jcbrandhas left
sezuanhas left
goffihas left
jubalhhas joined
Lancehas left
marc_has joined
Dele (Mobile)has joined
zachhas left
zachhas joined
Chobbeshas left
Lancehas joined
jubalhhas left
goffihas joined
goffihas left
andrey.ghas left
marc_has left
Neustradamus
Java works with 4096 DH key: https://bugs.openjdk.java.net/browse/JDK-8172869
zachhas left
zachhas joined
Neustradamus
Kev: Have you planned to upgrade M-Link to last version on the new server?