jonas’Kev, whenever I try to extract og data, I find a new way how they represent e.g. an associated image
KevIs that people not using OG literally, or a problem within OG?
jonas’I’m not sure
Kev(Genuine question, I've not played with Og in any significant way)
jonas’I’d have to go back to look at things
jonas’also, OG is often not as complete as one would wish it to be, because the site typically wants people to click through
jonas’which is why foorl (my URL resolver bot) has special code for some pages (twitter) where it overrides the OG readout with screen scraping of the twitter HTML to make it more useful
ZashI once joked about needing to repeat HTML metadata 5 times for open graph and similar things.
jonas’that sounds realistic
ZashI apparently didn't exagerate enough :(
ZashI think I found a couple more ways after that :(
KevFundamentally, there's two questions, I think. One is whether OG is reliable for extracting stuff from pages, and the other is whether it's a sensible mapping to use in XMPP for sending these type of data.
KevThe answer to (1) might be no, but still (2) be yes. (or potentially vice versa, although I don't immediately see how - no to both seems more likely than that).
ZashOpen graph, schema.org, twitter cards, dublin core, ... actual standard html <meta> tags
jonas’Kev, agreed, also to the "may be yes" for (2)
ZashIf we hadn't deprecated 71 you could have built whatever description thing with that
Ge0rGYou still can ;)
ZashOOB style desc+image might be fine tho
KevI don't think 71 is remotely sensible for this.
KevMy belief that we shouldn't deprecate 71 aside :)
jonas’the server should not handle formatting of the preview, that’s client side
KevI think just starting with title, URL and image preview would be sufficient for the majority of cases.
Kev(Which I think was what Zash was also saying, although I might have misunderstood)
ZashSomething in that direction
Ge0rGKev: that might not affect you any more, but with the new EU copyright directive, quoting of the title and image requires royalty payments to the respective publisher.
KevSo I think you end up instead of
<reference xmlns='urn:xmpp:reference:0' type='data' uri='http://xmpp.org'/>
with something like
<reference xmlns='urn:xmpp:reference:0' type='data' uri='http://xmpp.org'>
Ge0rG(it will make for an interesting precedent in court if you try to argue that it's the app that's loading the preview and not the server, with both being provided by the same party)
KevGe0rG: I think that's probably a detail, rather than a protocol consideration. This'd be very useful deployed internally and just polling our Jira and Confluence instances, for example, even without hitting The Internet.
KevZash: you want to literally use xep66 you mean?
KevOnly with URI coerced into being a preview, rather than the data itself.
Zash"want" is a bit strong, mostly I'm thinking out loud.
neshtaxmppKev: hi have moment
neshtaxmppKev: my friend ivan has compiled latest ejabberd from github... but he dont know if he installed completly to have everything like encryption and etc. in ejabberd. i find my friend ivan manual, to download latest erlang binary from official and he follow manual that comment: alternatively, you can do the complete erlang instalattion. it uncludes the erlang/otp platform and all of its applications... question is install esl-erlang... if this is complete erlang then why it is not erlang-base...
neshtaxmppin my friend ivan he has only omemo and openpg... when ivan try comment message omemo it comment he use old or unsupported server... ?
KevI'm completely unrelated to ejabberd, not sure why you picked me.
neshtaxmppKev: ejabberd xmpp is no working... and ivan send more than 2 emails in ejabberd support and no comment. when everyting is completly configured with everything... my other friend will make completly true manual. becouse in internet there is mis-configured manuals, fake manuals... and ivan has been with more than 1 month with broken ejabberd server... and when today i found him how to install official latest erlang it dont comment him error. but it is unknown if it is completly. if you know how to or if you know someone comment. thanks.
ZashThis is also not the place for ejabberd support
Ge0rGdwd: responding to Kev's response to my thread from last year
dwdOh, I'd not caught up as much as I'd thought.
KevSo I guess the question is - if I rewrite 308 with forwards so there's no ambiguity between the payloads to be replaced, and the payloads that may be belonging to the correction stanza itself, a) would Council support it and b) would that be better as a breaking 308 update, or as a new XEP?
dwdOh, new XEP.
KevBecause I think we're at the point that we need to break things.
jonas’that sounds like overkill
Ge0rGmy gut feeling is also "overkill"
dwdBut also: Does anyone *want* to use XEP-0308 for anything but correcting the <body/>?
Ge0rGbut then again I'm the one with multiple pages of arguing about the meaning of 0308.
Kevdwd: Depends if we're in a world where markup is its own element, I think.
Zashdwd: revoking your 👍 reaction?
dwdI mean, adding a receipt or chat marker seems... Well, a bit rubbish at least.
Ge0rGKev: "forwarding" as in XEP-0297?
dwdZash, Retraction is a different thing. Perhaps?
Lancedwd: correcting body would also change associated xhtml-im, references, etc?
Zashdwd: changing it to 👎 then?
dwdLance, If I'd known this was the way to summon you, I'd have done this ages ago.
Ge0rGZash: correcting a reaction is different from reacting to a correction.
KevGe0rG: Yes, as in 297. Or any other wrapper that distinguishes between replacement payloads and 'my' payloads, but 297 seems the logical.
Ge0rGKev: much overkill.
KevBut also the only way I can immediately see to resolve the issues you've raised about receipts.
Ge0rGthe biggest benefit I see with 0297 is that it mandates delay timestamps.
KevWell, no, that's not true.
KevIt's fine to just say 'you can't add a receipt. If you have a receipt in the original, reply to it. If you have a receipt in a correction, reply to that'.
Ge0rGyeah, not being allowed to add a receipt is perfectly fine. the problem remains nevertheless.
Ge0rGI'm currently thinking about tracking both the *first* id and the *last* id of a set of original-corrections
Ge0rGso that I can apply corrections from both 'right' and 'wrong' senders.
KevAs long as you don't do the Wrong thing with ids, there's no issue, AFAICS.
Ge0rGbut that obviously doesn't solve the receipts problem.
Kev(Combined with the above rule)
Ge0rGKev: but when wrong is right, then right is wrong.
dwdWhat about "You cannot add or remove elements, just replace"?
Ge0rGand where wrong is right, -1 is +1
Ge0rGdwd: I think that's stated in 0308 already, somewhere.
KevAs long as ids persist, and you send a receipt for any stanza that asks for one, you're good, I think.
> Correction MUST only be used to change the details of a stanza (e.g. the message body) and not to change the nature of the stanza
KevGe0rG: The intention is, but it doesn't use exactly those words.
Ge0rGis the _nature_ of a stanza the same as its XML skeleton?
KevRight, it's the fluffier test jonas’ pasted.
Ge0rGI suppose the "have a common ID for all related messsages in the DB" argument is very strong. If you mandate that MAM IDs and receipt IDs are explicitly excluded from the correction-body and instead are considered correction-metadata, I will unblock the PR.
Ge0rGEven though I dislike the concurrect corrections from multiple clients causing a random outcome situation.
Ge0rG(I also dislike DAGs, but I consider them appropriate in this situation)
jonas’mandating the ACK-sender to send a correction to their previous ACK is in violation of '184 and also quite meh
Ge0rGjonas’: the correction-of-ack part was the least serious analogy of my post
KevYou end up with race conditions when you're correcting from multiple clients whatever happens, I think, if you try hard enough.
jonas’aaaah the races, they’re everywhere
Ge0rGKev: yes, but with the DAG, you end up with multiple leaf messages
dwdWe *can* correct from multiple devices?
Ge0rGdwd: we are not allowed to.
jonas’are we not?
Ge0rGexcept in a MUC
Ge0rGdid anybody actually _read_ my message?
jonas’I’m sorry, not yet :)
jonas’I was halfway through
jonas’and then I got distracted
> A correction MUST only be allowed when both the original message and correction are received from the same full-JID.
> in direct-messaging siutaitons, this is violating the full-JID-MUST-match business rule in 0308, which I disagree with for practical reasons. In a MUC, ...
dwdGe0rG, I have a 2K screen in portrait with your email on and it doesn't fit without scrolling.
jonas’dwd, turn down your fontsize, obviously
Ge0rGwhat jonas’ said.
Ge0rGnext time I'll send HTML email that will auto-expand to your full screen width.
dwdjonas’, Seriously, it's not a large fontsize to begin with.
Ge0rGdwd: just tell me to shut up and to die on another hill.
jonas’dwd, anything larger than 5 px wide `m` is too large!!
Ge0rGI'll vote -0 and you can pass 0308.
Ge0rGor ~coerce~ ~bribe~ convince me with your offer to vote 0412 +1
KevI note that I didn't block 412, despite not agreeing with the compliance suites ;)
Ge0rGKev: you missed out on a great trade deal opportunity!
Ge0rGBut you still have a day to change your vote.
KevThere's still time until tomorrow afternoon :)
KevOr is it next week for 412? I forget.
dwdNot if I vote now.
Ge0rGLooking at the author churn that Compliance Suites has accomplished in the past, I'm still undecided whether it was a very smart or a very dumb idea to take it over.
Ge0rGSo far, I still feel motivated and have a feeling that my skin is sufficiently thick to counter the nay sayers.
KevI would very very much like us to not have a 2020 Compliance Suite. I think it's long overdue for a rethink of how we do them.
Ge0rGKev: let's have that discussion after dwd voted +1 or the vote expires.
KevI'm still thinking that the idea of having two 'living' XEPs, one for 'core XEPs' and one for 'direction of travel XEPs' and talking about versions of those, instead of years of compliance suites.
dwdOh, that';s an interesting thought.
KevI think that makes it less contentious, because then you don't have people sliding in things that they want the state to be, but isn't yet, or missing out things that are the state buy they wish weren't.
KevYou can still update yearly, but without the "Oh no, it's 2019 and we don't have a 2019 suite, the sky is falling" associated with the current suites.
Ge0rGKev: yes, that's a great idea. However, it will make versioning and version referencing a pain.
KevI think the resultant guidance would be more useful for devs, and because there isn't a mix of now and future, also more useful for the hypothetical marketing people using these things as badges.
KevGe0rG: I'm not sure it's that much harder, is it? You just talk about 'state 1.0', 'state 3.2' instead of 'compliance 2018', 'compliance 2019'.
Ge0rGKev: I agree in principle, but both our process and our tooling is severely lacking to pull this off.
dwdNew XEP-0308 question - if I correct a message, the effect is that the message's payload is replaced by the correction, and as such, the corrected message now has the updated semantics, right?
KevGe0rG: I don't immediately see why, but I might be being enthusiastically naive.
Ge0rGKev: congratulations, you just replaced an obvious versioning scheme with an opaque one.
dwdKev, Well, for one thing, we don't have an effective way to reference versions.
Kevdwd: Other than that you shouldn't be changing semantics.
KevGe0rG: Well, if XEP numbers are better, we can still keep doing what we were already doing, and including versions in the titles and replacing the whole XEP. I don't think it's ideal, but it's feasible.
dwdKev, RIght, but if a message has a <body/>, the corrected message has an updated body, and whatever the client did with the original body is replaced by the new one, right?
Kevdwd: I think it's up to the client how they render it, but logically yes.
dwdKev, So if the corrected message is a correction, then by correcting the correction you are correcting the original message indirectly, yes?
KevYou can't be, no.
dwdKev, Why not?
KevBecause you'd be replacing the bit that tells you what you're correcting.
dwdSo the LMC element is also copied to the corrected stanza?
KevNo, it'd be removed from the interim correction, because you replace all payloads.
Ge0rGThe process problem is that the new Compliance Suite is either bound to be Eternally Experimental, or have heavy council battles on each minor change in Draft. And obviously, Final is a no go
KevThereby changing the meaning of the interim correction, which isn't allowed.
dwdKev, But was the LMC element copied to the original message by the first correction?
KevGe0rG: It wouldn't be standards-track, presumably, would go to Active instead, but possibly.
Kevdwd: And that's one of the reasons I'm pondering shoving it in a forward.
KevBecause obviously not, no, but if you take it literally ...
dwdKev, Right, what I'm trying to figure out is whether correcting the original or correcting the correction makes any semantic difference.
dwdKev, I think it's nice if we pick one, mind. Just not sure it actually matters which.
Ge0rGForwarded will come with a nice evil can of security worms for implementations to jump over.
dwdSecurity worms are the worst kind.
Kevdwd: I think there's two possible responses to that
One is that it does matter, and having a single identifier makes more sense.
Two is that we already picked one, the current discussion is whether to change it.
KevGe0rG: I was pondering that. So instead of 297, the new payloads are a child of the correction element? That has its own issues, but fewer.
dwdKev, But why does it matter, and have we actually picked one? (My impression was that existing clients do both)
Ge0rGdwd: Kev picked one but failed to write it down unambiguously, so at least three developers picked the other one.
KevWell, Ge0rG agreed in the thread that the original intend of the XEP seemed to be what I claimed it to be, and this was a request to change it. So I think the XEP gives one - that clients are implemented both ways is a different (but related) issue.✎
KevWell, Ge0rG agreed in the thread that the original intent of the XEP seemed to be what I claimed it to be, and this was a request to change it. So I think the XEP gives one - that clients are implemented both ways is a different (but related) issue. ✏
Ge0rGDamn, I shouldn't have made that concession.
dwdTo put it another way, if you received a correction to a correction, what could it possibly mean except to update the correction (and thereby correct the original message again)
KevSounds like the right time for me to check out for the day :)
Ge0rGKev: with what dwd said above, I'd say that "correct a correction" would be a legitimate way to interpret the XEP
404.city Supporthas joined
Ge0rGKev: you have another week left to make me change my mind...
404.city Supporthas left
Steve Killehas left
404.city Supporthas joined
404.city Supporthas left
Steve Killehas joined
Dele Olajidehas left
Steve Killehas left
Dele Olajidehas joined
firstname.lastname@example.org not connect
Steve Killehas joined
fireCasual english conference for me, ok?
Dele Olajidehas left
fireNot fear :-D
fireThis many people
fireI am look
fireWhat is fucking shit?
MattJfire, hey, this room is for discussion of XMPP standards. It is not a general chat, and you have been given the address of a general chat: email@example.com
fireMattJ, general chat not found for me
MattJCheck you typed the address correctly
MattJDepending on your client, this link may work: xmpp:firstname.lastname@example.org?join