lovetoxsay im sending a join presence to the room, and before the room sends me the roster i send a unavailable presence
lovetoxshould the server still send the roster?
lovetoxcan i leave a room when im not fully joined?
lovetoxis probably the question
lumihas joined
eevvoorhas joined
Holgerlovetox: 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.
lovetoxyeah i know that the server probably queues the presences before he receives my unavailable and can not remove presences from the queue in time
lovetoxbut does ejabberd even try?
debaclehas joined
lovetoxi think about this, because when entering a room with a captcha
lovetoxserver sends no roster until captcha is solved
lovetoxso it should respect my unavailable if i cancel the captcha challend
HolgerIf 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.
lovetoxso it should respect my unavailable if i cancel the captcha challenge
HolgerAhh, so the story is kinda different.
lovetoxejabberd does not respect unavailable within a captcha flow, also not captcha canel message
lovetoxinstead it has a 1 minute timer
lovetoxthat sneds a presence error when the captcha is not solved in that time
lovetoxbut i wonder if i should care ..
lovetoxi dont think it causes any problems ..
lumihas left
Holgerlovetox: 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
lovetoxi do this, but as i said above, it does not have any effect on ejabberd
HolgerAh "also not captcha cancel message", overlooked that.
lovetoxwhat i would expect is, after cancel to get a presence error type=auth or something
HolgerYeah that sounds wrong to me.
HolgerYup.
HolgerWho does room CAPTCHAs anyway ;-)
lovetoxyeah so now i get the presence error 40 seconds later because it runs into the timeout
HolgerBut yes maybe post an issue if you're motivated ...
lovetoxi dont see any problem getting it later though
lovetoxi dont see how that delayed error would cause any problem
zachhas left
zachhas joined
lovetoxits basically a nitpick at this point :)
HolgerYup but I guess you're right.
murabitohas left
murabitohas joined
lumihas joined
igoosehas left
igoosehas joined
goffihas joined
Ge0rGFirst 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.
HolgerXMPP at its best.
Link MauveHolger, that’s been fixed, but some servers still don’t implement MUC 1.29. :(
Link MauveDamn, two years ago already.
Ge0rGno servers implement Carbons 0.13
KevWell, in fact XEP-0045 was always written that way.
Ge0rGLife is sad.
KevJust that 1.29 made it clearer.
KevGe0rG: I have a server implementation, including the extra namespace.
Ge0rGKev: is it public?
KevNo, it'll appear in a future M-Link release, it's not released yet.
HolgerGe0rG: Oh I missed that. I'll add that to ejabberd.
Ge0rGKev: will that release be running on jabber.org? :D
KevNot unless Peter changes his mind :)
Ge0rGHolger: would you come with pitchforks and torches if I also mandate forwarding of message errors?
Ge0rGBTW, I'd like to make message errors non-ephemeral in general, so that they end up in MAM and in Carbons.
Ge0rGare server developers going to kill me for that?
HolgerRight, 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
Ge0rGHolger: I've been asking that for years now
HolgerOther 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.
HolgerGe0rG: 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).
Ge0rGHolger: this part of the new 0280 rules was heavily objected
HolgerGe0rG: I mean for some things there are probably better solutions than cluttering the DB. But cluttering is better than what we have now.
Ge0rGIt'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
Ge0rGCCing message errors from a MUC might be interesting, though.
adityaborikarhas left
adityaborikarhas joined
rionhas left
rionhas joined
eevvoorhas joined
HolgerIndeed.
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
ralphmI'm on the road, but will try to follow the board meeting
stpeterhas joined
Lancehas left
MattJo/
SeveHi MattJ
MattJGuus?
Guushere!
MattJDoes someone else want to chair? I'd like to unvolunteer myself this week if that's ok
GuusSeve, you want to have a go?
Guusis @nyco not here?
MattJApparently not
GuusSeve?
Guusreaches for the gavel....
SeveSorry :)
SeveI'm fully back now
Guusplease act as our chair if you want to. 🙂
SeveLet's go
SeveWelcome
MattJ<3 Seve
SeveI guess it's three of us, MattJ, Guus and me
goffihas left
Guuswith Ralph on the backburner.
SeveDo you have something to add to the agenda?
GuusI don't have anything to add ot the agenda.
Seve1. Minute taker
Any volunteers? :)
Steve Killehas joined
MattJNothing here (not sure if Peter's financials email is a worthy topic?)
MattJI can minute
SeveThat's awesome, thanks MattJ !
SeveNothing to discuss from me on that topic at least
GuusI don't have anything to discuss on Peters email, other than "thank you Peter for the update."
SeveIndeed
GuusI'd be happy to discuss it if others feel there's soemthign to be discussed.
GuusI sense that's not the case though? 🙂
SeveDoesn't look like. If not, we can always take it again or via email
Seve2. Commitments
Seve"Follow-up on feedback & create poll for Compliance Suite Badges"
SeveBeing Nyco away, I guess we can skip this one for now
Steve Killehas left
MattJwfm
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
Seveas far as I know
peterhas joined
Guus(Did you skip the 'topics for decisions' lane on purpose?)
Steve Killehas joined
Steve Killehas left
SeveYes, since they were both away :)
SeveNow let's move onto
Seve3. Topics for decisions
Guusah 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? :)
Guusright
SeveThere 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.
MattJRight :)
SeveDo we want to clarify this and vote on the next meeting with the rest of the Board?
GuusI'd prefer to do it now.
Guuswe have quorum, and we're not being very effective as-is.
Ge0rGthe question was, who should be responsible for evaluating non-maintainer updates to the lists
Ge0rGBoard or Editors.
GuusI think we phrased that as "Should non-maintainers be allowed to ask for a project listing renewal?"
Ge0rGGuus: this is a misleading question. Everyone can ask something.
GuusGe0rG - I thnk you're asking a different question.
pdurbinhas left
Ge0rGGuus: the relevant question is what process happens if a non-maintainer asks.
MattJNo, I think Ge0rG is asking a very slightly different but actually strongly-linked question which is the most relevant one here
GuusI'd like to avoid having different processes, based on who authored the PR.
MattJI'm fine with that, it doesn't necessarily mean there have to be two processes
Ge0rGGuus: in that case, the relevant question is, how is the process supposed to work if *anybody* asks for renewal
Ge0rGthe status quo is: editors reject if a non-maintainer asks, accept if a maintainer asks.
Guusthat's not the status quo
Ge0rGor maybe: editors escalate to Board if a non-maintainer asks, accept if a maintainer asks.
peterhas left
Ge0rGGuus: that was the status quo I tried to establish, I obviously can't know how it is lived by the Editors.
GuusI'm not an editor, yet do much (most?) of the website PR merging.
Ge0rGwhat is the right term then?
GuusThere'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"?
SeveIf it is a matter of checking the projects being renewed or introduced, I don't mind volunteering for that.
MattJI don't know if we're entirely clear on what "checking" means, are we?
MattJwhich is part of the problem
GuusThe 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
SeveMattJ, exactly
GuusI strongly feel that we're making to much of this.
GuusI want to steer away of all of this complexity.
MattJI 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
MattJand I think everyone currently has different notions of what the ideal and the status quo are from this list
GuusAgreed.
Guusalso: the definition of what is ideal is not something we'll agree upon, without much more discussion, I fear.
MattJwe == Board, or we == community (Ge0rG)? :)
SeveI would go for option 3, that gives us a way to keep understanding what to do :)
GuusThe more, the merrier 😃
jubalhhas joined
GuusIn option 3, who does the deciding?
jubalhCisco jabber = XMPP? Or were there changes ?
MattJWell, it's currently us, it seems
SeveI would say Board until something is cleared out
Guus(basically, the 'web-team' now does that, which effectively has the outcome of option 1)
jubalhI'm getting a bugreport from a user using Cisco Jabber server. And wonder whether the server could actually be the reason
waqasDo 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)?
waqasAh, timed out with "504 Gateway Time-out"
Guusjubalh mind postponing that until after the board meeting?
jubalhoh so sorry
MattJjubalh, we are currently in a meeting which will end soon - maybe ask in jdev@conference.jabber.org or wait for a bit :)
jubalhI'll wait
Guusthanks
MattJwaqas, I think we pretty much all agree that the old list was terrible by all metrics
Ge0rGI'm for 2) with the objective criterion being "the PR author claims to be a maintainer of the project"
MattJSo the goal we can all agree on was weeding out unmaintained software from the list
GuusI'd not be to happy with board to have to decide on every change / renewal request.
SeveWhat 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 :)
GuusI'm not seeing with what the 'maintainer' requirement does for the quality of the list - other than prevent others from changing (mostly improving) it.
SeveAlthough I would love maintainers care of it enough to appear on the list instead
MattJI'd love to just move to Link Mauve's magic DOAP project in the near future, when it's ready
MattJWhich is something to consider - even manual validation may only be a short-term thing
Ge0rGGuus: others "improving" the list leads to sub-par clients becoming visible
GuusGe0rG yes. Overall, it'd still be an improved list though.
Ge0rGGuus: we've had pidgin, astrachat and empathy on that list
Ge0rGGuus: not improved in comparison to the process that web-team isn't adhering to
Guus"improved enough" for me though.
GuusAll other overhead is frankly not worth it, in my opinion.
MattJI propose the following: web team auto-accepts if maintainership can be verified, defers to Board if it can't
Ge0rGGuus: Seve just volunteered to take over the overhead. I'd do so too.
GuusI think we've sufficiently exchanged the same arguments for two weeks now though 🙂
MattJand long term, we replace it with an automatic solution
Ge0rGSpeaking 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.
MattJAs 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
MattJIf we accept everything without question, it's not really curating the list in the way that we need to keep it clean
SeveExactly my thoughts
Chobbeshas joined
GuusThe list will, eventually, curate itself mostly.
MattJAs nice and simple as that would be
MattJMy feeling is that the majority of requests will come from obvious maintainers and take no effort to verify and merge
MattJand 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
MattJI 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
MattJBut I also don't want to automatically accept everything just because someone submitted a PR
MattJPR doesn't automatically equal improvement
Guuslet's vote on this already
MattJOn what exactly?
Guuswe're continuing to exchange the same arguments
SeveWe 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
MattJHow is this for starters?
SeveDo you agree voting on that, Guus?
SeveI'm fine with it
Guus'verified' might be a bit ambiguous.
Guusbut I don't have an immediate alternative wording.
Ge0rGas I said, in my eyes it's sufficient to ask the PR author in the PR whether they are a project maintainer.
Guusbut I'm fine with the gist of it.
MattJIf the web team struggles with implementing this policy, we can talk - I doubt they will :)
MattJChair, call the vote!
MattJWhy did I volunteer to minute this gnarly discussion?
SeveLet'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."
SeveThat's a green light then. Vote passes.
GuusI read that as 'motion passed"
SeveYes
Guusexcellent. Let's move on. 🙂
MattJAmen
SeveHah :)
SeveSince we have used more time than usually, do you want to stop here? I may not have more time today, unfortunately.
GuusIf you're leaving, we loose quorum anyways
Guusso, sure.
MattJsgtm
SeveOk then
Seve4. AOB?
MattJNone here
Guusnope
Seve5. Date of Next
SeveNext week, same time? :)
Guuswfm
MattJ+1
Seve6. Close
GuusThanks!
SeveThank you guys for this meeting
MattJThanks Seve, you're a star :)
Seveblushes
evehas left
evehas joined
SeveGreat to see we have come to a solution on that one
GuusYes, indeed.
GuusI'd love for us to find a way to have much of these discussions outside of the scope of the meetings though
Guusas they're eating up much of the meeting time.
Guuswhich I think hurts our productivity further.
GuusI'm unsure what would be an improvement. More adhoc discussions over XMPP in preparation of the meeting? More mailinglist discussions?
SeveYes, 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.
MattJI agree that would be ideal
MattJThe meeting however is a good way to allocate time and focus on specific issues, ensuring we are all present for a productive discussion
MattJSo I'm not sure it is easily replaced by simple votes
Ge0rGallocate 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
Guusjonas’: mind testing muclumbus on conference.igniterealtime.org ?
GuusOn 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 ;)
ZashIt's the other way around, things have been accepting 1024-bit DH groups for compat with Java, but no more
ZashThe future seems to be ECDHE-only tho
jonas’is it openssl 1.1 or debian which requires 2048 bits now?
ralphmAlso I would check that Java indeed has reasonable defaults. Not an assumption I would make.
GuusIf we don't seem this acceptable any more, then xmpp.net scoring should be adjusted.
jonas’probably
ZashGuus: " 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?
GuusB is a pretty good score
ZashI think this is Debian, but IIRC the browser folks are in on it
Ge0rGThe good thing about Java defaults is that they depend on the JRE version you are running.
GuusWe 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 :>
GuusHehehe
GuusThis is sooooo different from a conversation I had with a customer not to long ago
GuusThey insisted that the password being equal to the username was safe.
jonas’Guus, oh my god.
marc_has left
jonas’Zash, probably
GuusI'll see if we can switch Ignite to Java 11. I'd be interested in finding out what that does to the encryption parameters.
GuusI 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?
Guusjonas’: ^
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
GuusThere 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
GuusAh, I thought muclumbus was the scraping protocol used by jabbercat
GuusOh 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 :)
jonas’Guus, ^
Guusthe combination of both, or either?
Guusopen_chat is an existing muc name
Guussearching for
jonas’combination of both
Guussearching for "openfire" or "smack" should give you a result
GuusYou'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/
Guustx
GuusOpenfire does not like <set xmlns="http://jabber.org/protocol/rsm"/>
jonas’hm
Guuseek, my client formatted that weirdly.
jonas’mine did not
GuusHmm... This might be a bug in Openfire
Guusit expects _all_ fields.
jonas’all in rsm?
jonas’I can’t give you *that*
jonas’at most I’d give you a <max/> ;)
Guuscode is somewhat hard to read
jonas’but setting <max/> helps already!
jonas’I get a reply
Guusit does expect a positive max value
Guusand it cannot have non-specified fields...
Guusseems to be pretty strict.
jonas’Guus, it doesn’t return a <max/> value
GuusI 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 :)
Guusit indeed does not re... yeah, what you said. 🙂
jubalhso 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...
Guusjubalh yup - thanks for your patience 🙂
jubalhno problems, I wasn't aware of the meeting, just joined and typed. so i realized it too late.
Guusjonas` isn't 'count' more appropriate for that?
jonas’more or less
Guusjubalh no worries, no harm done
jonas’fixing my code ;)
Guusyou'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
jubalhI 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/
GuusI have no firsthand knowledge, but from what i've heard, it is not.
Lancehas left
jonas’Guus, ^5
Guusjonas’ 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)
GuusI'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
Guuswe 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
GuusSadly, it's in an upstream library, so updating this will take some time.
jubalhpep., do you think that this bugreport could be due to that reason?
pep.jubalh: ask for XML logs?
jubalhwill do
pep.Is there an XML console in profanity or sth?
jubalhthere is, yes
jubalhI'll ask him
pep.K
murabitohas left
murabitohas joined
Douglas Terabytehas joined
Yagizahas left
ralphmI think there is no explicit rule that says you can't send (repeated) `<presence type="subscribed"/>`, but I can see how that's annoying.
ralphmA client could check against local state to prevent annoying the user.
Guusralphm that's in reply to what? (Am I missing context?)
pep.Guus: not you
ralphmjubalh's message above about Cisco Jabber
GuusI didn't see him talk about presence subscribed though
Guusor is that in https://github.com/profanity-im/profanity/issues/1165 ?
Guusright, sorry.
ralphmYes
GuusI've been working on an issue where occasionally, messages were not being delivered to a MUC
Guusso I'm now jumping at instances where I appear to be missing messages (which is hard to detect, visually)
jubalhralphm, 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
Guushow does one interpret an RSM request that defines both an 'index' element, as well as an 'after'?
ralphmjubalh: I would
waqashas joined
jubalhso 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
ralphmLooping? I assume your client has some local state for each contact/roster item, indexed by JID
jubalhright sorry
jubalhgot it :)
ralphmNo 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 MauveI 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
flowGuus, 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
ZashThat is indeed highly ambigous.
andyhas left
Guusflow: it's currently not allowed, although I'm playing with code that could allow it. I was actually looking for feedback.
lovetoxwhat was this again for?
lovetoxpaging backwards but the page is also reversed
lovetoxi guess
ZashProsody with SQL backend does allow it but I'd call it undefined behavior.
flowI tend to believe that RSM should just disallow using <after/> and <before/> together
lovetoxit makes not much sense
lovetoxthough were is the harm flow?
lovetoxthough where is the harm flow?
ZashActually I think Prosodys MAM code will allow it always, but some backends will ignore one of them and good luck figuring out which.
lovetoxits not mentioned in the XEP, nobody reading the XEP would ever get the idea that this is even possible
lovetoxthere is no way you can discover that the server supports that "hack"
lovetoxso i dont see any client actually using that
flowlovetox, ambigouty and implementation dependent behavior is always harmful to an protocol
Nekithas joined
lovetoxbut its nowhere documented that this is even possible, and as you say undefined
flowit is also not specified that it is impossible
lovetoxso its basically a feature some dev knows and can play with
flowsometimes it is better to be explict
lovetoxsorry, its also not defined what happens if add <after> twice
lovetoxor if i add a element thats not even mentioned in the XEP
flowthat, at least, is disallowed by the schema
ZashSchema validators hate it!
ZashSomething something this weird trick
lovetoxdoes it not follow that everything not mentioned in the XEP is *not defined*
flowadding 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*
ZashIn 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.
lovetoxgreat Zash, only a madman would use this though
lovetoxor someone writing clients that only operate with prosody
ZashMostly 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)
GuusIt'd be good to explicitly define expected behaviour or restrictions in the XEP.
ZashI think other storage backends will simply ignore `after` if `before` is present
GuusChanges in behaviour caused by an invisible implementation detail seems undesirable.
ZashHaving both `after` and `before` is UB, so what you gonna do?
zachhas left
zachhas joined
ZashWe could explictly forbid it since it makes no sense
lovetoxyou talk like this happens per accident
ZashAs in, return some error stanza
GuusSounds good
ZashIt happens because the query and the data flow through two layers with slightly different API and semantics.
jubalhhas left
ZashWell. 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
NeustradamusJava works with 4096 DH key: https://bugs.openjdk.java.net/browse/JDK-8172869
zachhas left
zachhas joined
NeustradamusKev: Have you planned to upgrade M-Link to last version on the new server?
XSF Discussion - 2019-08-01