XSF Discussion - 2019-04-02

Can I have a quick show of hands for people who plan to go to CCCamp this year?

(ftr, not https://www.cccamp.org/)

As that's in the US, you might want to re-ask when the locals have had time to wake up. 😉

What is in the us?

confusion!:)

oh, sorry

CCCamp is in Germany

_not_ the link that you provided.

If I see a link, I click on it.

Guus, that’s a vulnerability

I know.

I'm vulnerable.

https://www.flickr.com/groups/cccamp2015/pool/page1 fwiw :)

jonas’, when it's not your client doing it automatically..

Yeah, now I'm not gonna click anything anymore, obviously! 😃

*cough* http upload *cough*

Message Attaching comes to mind

SIMS?

SIMS is for more file transfer like things

Ah, I was thinking Dele Olajide was referring to my mention of http upload

Which is very much file transfer :)

Dele Olajide, I started to think about stuff like that, and how to possibly outsource that task to the server while at it

I haven’t gotten much beyond the stage of thinking though

Not httpfileupload. Just the ability to support the open graph protocol server-side and then send the preview data inbound on the XMPP conversation

https://github.com/jabbercat/jabbercat/issues/102

Dele Olajide, ^

Dele Olajide: You'd do that with references.

So you can send the first message through ok, then the server could do the opengraph lookup, and send a reference with the OG data. I/someone should probabyl spec that.

And also spec how to use local-IDs in references, while we wait for a sensible solution to global ids.

Or a bot. Or the sending client could do it.

Zash: Yes, any entity could send the additional data.

the question here is not so much how to attach the info to the message, but how to transfer the info, I think

P >Kev: someone should probabyl spec that. That is the XEP I am looking for 🙂

XHTML-IM!

So this needs a References payload containing OG data, basically?

Kev, basically, if "og data" was in general a sensible representation of that type of data.

.

— ✏

jonas’: Is it not?

Kev, whenever I try to extract og data, I find a new way how they represent e.g. an associated image

Is that people not using OG literally, or a problem within OG?

I’m not sure

(Genuine question, I've not played with Og in any significant way)

I’d have to go back to look at things

also, OG is often not as complete as one would wish it to be, because the site typically wants people to click through

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

I once joked about needing to repeat HTML metadata 5 times for open graph and similar things.

that sounds realistic

I apparently didn't exagerate enough :(

I think I found a couple more ways after that :(

Fundamentally, 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.

The 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).

Open graph, schema.org, twitter cards, dublin core, ... actual standard html <meta> tags

Kev, agreed, also to the "may be yes" for (2)

If we hadn't deprecated 71 you could have built whatever description thing with that

You still can ;)

OOB style desc+image might be fine tho

I don't think 71 is remotely sensible for this.

My belief that we shouldn't deprecate 71 aside :)

+1 Kev

the server should not handle formatting of the preview, that’s client side

I think just starting with title, URL and image preview would be sufficient for the majority of cases.

(Which I think was what Zash was also saying, although I might have misunderstood)

Something in that direction

Kev: 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.

So 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'> <preview><title>XSF</title><image>http://xmpp.org/preview.png</image></preview> </reference> or thereabouts

(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)

Ge0rG: 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.

Indeed.

<reference uri='http://example.com/'><oob><desc>Example site</desc><uri>an image here<////>

Zash: you want to literally use xep66 you mean?

Only with URI coerced into being a preview, rather than the data itself.

"want" is a bit strong, mostly I'm thinking out loud.

Kev: hi have moment

I'm semi-here.

Kev: 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...

in my friend ivan he has only omemo and openpg... when ivan try comment message omemo it comment he use old or unsupported server... ?

I'm completely unrelated to ejabberd, not sure why you picked me.

Kev: 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.

This is also not the place for ejabberd support

https://www.ejabberd.im/support/index.html

There's no place for ejabberd support 😜

neshtaxmpp: xmpp:ejabberd@conference.process-one.net?join

neshtaxmpp: Maybe you could try to describe the problem in a concise manner (we did $x, expected $y to happen, but got error message $z instead) in that room.

Welcome

no you

pep., hey man

I am from russia

Ok?

It's fine if you are from russia

Not many people speak russian here though

Yes, very good

I am not speac english

Don't know english language, ok?

Speak*

In jabber have bot translater for me?

Not in this room

This chat is about XMPP standards.

Oh

What were you looking for?

This room speak english language

Maybe and I lern speak english language *DONT KNOW*

This cool, yes?

Where are your from?

I'd say this chat speaks "standards" language and nothing else. well maybe except yesterday.

fire: you could join xmpp:offtopic@chat.disroot.org?join for casual chat in english ;)

vanitasvitae, thanks

:)

https://bgzashtita.es/upload/2648c95f187eff879a53c9890338a1a8d74210e6/GndMPwCWHRRIymalDzKbIhcDZIFM2p5FcsQ5BNsx/Screenshot_20190402-162851.jpg

neshtaxmpp: get lost

oli: ?

go away

What's going on?

What's going on?

What's going on?

What's going on?

And I say, hey, hey, hey, hey

oli: yo try tag me, now commemt what is going on ? ✏

Zash, hey man, stop this

wat

Could we keep it civil, please? This is not Parliament.

oli... peoples are waiting... why you try insult me. ✏

what... hey i send private picture... is every body see it ?

fire: Болгария

It seems you inadvertently sent a picture to the room instead of in a direct message.

intosi: so the bug... is not fixed... i send photo in private message but it still persist the bug... when someone send private picture it send it too in public room.

neshtaxmpp, that’s a Conversations bug though

Maybe this room isn't the venue to discuss that bug.

jonas’: unknown... in the past someone say other comment. see you... bussy right now.

intosi, "парламент - не место для дискуссий", // parliament is no place for discussions, as one of Putin's cronies famously said.

Andrew Nenakhov I think the UK parlement said to that guy: "hold my beer."

Lol

;)

Guus, Oh, come now. The UK Parliament wouldn't agree to that.

Guus, Mostly because it can't agree on anything.

they mostly agreed to disagree.

speeking of agreement. dwd, I'm still missing your vote on 0412

nice, Ge0rG

Guus, They didn't agree to that either.

Ge0rG, Subtle, that.

They disagreed to agree?

dwd: it's four months overdue, so every hour counts!

also I need it to promote the badges!

nice, peter wahers email on stanza encryption crashed my mail client

it's appropriately encrypted

Kev, If I correct a message that has no '84 request iwth a correction that does have a '84 request, which id does the receipt assert is received?

dwd, you do want to see the world burn, don’t you?

dwd, I think the intent of LMC prohibits that

dwd: speaking of 0184?

> 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

I'm increasingly thinking I should write a 308 replacement, using references and forwarding, to avoid this sort of ambiguity.

because '84 is about pubsub

Kev, If I correct a message that has no '184 request iwth a correction that does have a '184 request, which id does the receipt assert is received?

I think we discussed this in passing at the Summit, even.

Oh. And correction didn't in this case. What ho.

dwd: I wrote a long-ish analysis of 0184 LMC on standards@

highlighting all(?) the corner cases

Ge0rG, The thread Kev is responding to? Or a different one?

dwd: https://mail.jabber.org/pipermail/standards/2019-April/036025.html

dwd: responding to Kev's response to my thread from last year

Oh, I'd not caught up as much as I'd thought.

So 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?

Oh, new XEP.

Because I think we're at the point that we need to break things.

that sounds like overkill

my gut feeling is also "overkill"

But also: Does anyone *want* to use XEP-0308 for anything but correcting the <body/>?

but then again I'm the one with multiple pages of arguing about the meaning of 0308.

dwd: Depends if we're in a world where markup is its own element, I think.

dwd: revoking your 👍 reaction?

I mean, adding a receipt or chat marker seems... Well, a bit rubbish at least.

Kev: "forwarding" as in XEP-0297?

Zash, Retraction is a different thing. Perhaps?

dwd: correcting body would also change associated xhtml-im, references, etc?

Lance: Yes.

dwd: changing it to 👎 then?

Lance, If I'd known this was the way to summon you, I'd have done this ages ago.

Zash: correcting a reaction is different from reacting to a correction.

Ge0rG: Yes, as in 297. Or any other wrapper that distinguishes between replacement payloads and 'my' payloads, but 297 seems the logical.

Ge0rG: Brains

Kev: much overkill.

But also the only way I can immediately see to resolve the issues you've raised about receipts.

the biggest benefit I see with 0297 is that it mandates delay timestamps.

Well, no, that's not true.

It'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'.

yeah, not being allowed to add a receipt is perfectly fine. the problem remains nevertheless.

I'm currently thinking about tracking both the *first* id and the *last* id of a set of original-corrections

so that I can apply corrections from both 'right' and 'wrong' senders.

As long as you don't do the Wrong thing with ids, there's no issue, AFAICS.

but that obviously doesn't solve the receipts problem.

(Combined with the above rule)

Kev: but when wrong is right, then right is wrong.

What about "You cannot add or remove elements, just replace"?

and where wrong is right, -1 is +1

dwd: I think that's stated in 0308 already, somewhere.

As long as ids persist, and you send a receipt for any stanza that asks for one, you're good, I think.

Ge0rG, dwd: > 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

Ge0rG: The intention is, but it doesn't use exactly those words.

is the _nature_ of a stanza the same as its XML skeleton?

Right, it's the fluffier test jonas’ pasted.

I 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.

Even though I dislike the concurrect corrections from multiple clients causing a random outcome situation.

I find Ge0rGs argument about concurrent ACKs actually quite compelling :/

(I also dislike DAGs, but I consider them appropriate in this situation)

mandating the ACK-sender to send a correction to their previous ACK is in violation of '184 and also quite meh

jonas’: the correction-of-ack part was the least serious analogy of my post

You end up with race conditions when you're correcting from multiple clients whatever happens, I think, if you try hard enough.

aaaah the races, they’re everywhere

Kev: yes, but with the DAG, you end up with multiple leaf messages

We *can* correct from multiple devices?

dwd: we are not allowed to.

are we not?

except in a MUC

did anybody actually _read_ my message?

I’m sorry, not yet :)

I was halfway through

and then I got distracted

XEP: > A correction MUST only be allowed when both the original message and correction are received from the same full-JID. My mail: > 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, ...

Ge0rG, I have a 2K screen in portrait with your email on and it doesn't fit without scrolling.

dwd, turn down your fontsize, obviously

what jonas’ said.

next time I'll send HTML email that will auto-expand to your full screen width.

jonas’, Seriously, it's not a large fontsize to begin with.

dwd: just tell me to shut up and to die on another hill.

dwd, anything larger than 5 px wide `m` is too large!!

I'll vote -0 and you can pass 0308.

or ~coerce~ ~bribe~ convince me with your offer to vote 0412 +1

I note that I didn't block 412, despite not agreeing with the compliance suites ;)

Kev: you missed out on a great trade deal opportunity!

But you still have a day to change your vote.

There's still time until tomorrow afternoon :)

Or is it next week for 412? I forget.

Not if I vote now.

Tomorrow.

Looking 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.

So far, I still feel motivated and have a feeling that my skin is sufficiently thick to counter the nay sayers.

I 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.

Kev: let's have that discussion after dwd voted +1 or the vote expires.

I'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.

Oh, that';s an interesting thought.

I 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.

You 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.

Kev: yes, that's a great idea. However, it will make versioning and version referencing a pain.

I 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.

Ge0rG: 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'.

Kev: I agree in principle, but both our process and our tooling is severely lacking to pull this off.

New 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?

Ge0rG: I don't immediately see why, but I might be being enthusiastically naive.

Kev: congratulations, you just replaced an obvious versioning scheme with an opaque one.

Kev, Well, for one thing, we don't have an effective way to reference versions.

dwd: Other than that you shouldn't be changing semantics.

Ge0rG: 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.

Kev, 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?

dwd: I think it's up to the client how they render it, but logically yes.

Kev, So if the corrected message is a correction, then by correcting the correction you are correcting the original message indirectly, yes?

You can't be, no.

Kev, Why not?

Because you'd be replacing the bit that tells you what you're correcting.

So the LMC element is also copied to the corrected stanza?

No, it'd be removed from the interim correction, because you replace all payloads.

The 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

Thereby changing the meaning of the interim correction, which isn't allowed.

Kev, But was the LMC element copied to the original message by the first correction?

Ge0rG: It wouldn't be standards-track, presumably, would go to Active instead, but possibly.

dwd: And that's one of the reasons I'm pondering shoving it in a forward.

Because obviously not, no, but if you take it literally ...

Kev, Right, what I'm trying to figure out is whether correcting the original or correcting the correction makes any semantic difference.

Kev, I think it's nice if we pick one, mind. Just not sure it actually matters which.

Forwarded will come with a nice evil can of security worms for implementations to jump over.

Security worms are the worst kind.

dwd: 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.

Ge0rG: 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.

Kev, But why does it matter, and have we actually picked one? (My impression was that existing clients do both)

dwd: Kev picked one but failed to write it down unambiguously, so at least three developers picked the other one.

Well, 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. ✏

Damn, I shouldn't have made that concession.

To 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)

Sounds like the right time for me to check out for the day :)

Kev: with what dwd said above, I'd say that "correct a correction" would be a legitimate way to interpret the XEP

Kev: you have another week left to make me change my mind...

Hey man

Don't sleep

Russia online

offtopic@chat.disroot.org not connect

Casual english conference for me, ok?

Not fear :-D

This many people

I am look

What is fucking shit?

fire, 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: offtopic@chat.disroot.org

MattJ, general chat not found for me

MattJ, why?

Check you typed the address correctly

Depending on your client, this link may work: xmpp:offtopic@chat.disroot.org?join

Ok

Write error 400 jid malformed

The JID is offtopic@chat.disroot.org

It is work, bat not connect for me

This private group maybe?

It is not private, it works for me

Why I am not going group

MattJ, I'm fire, ok?

Yes?

MattJ, you like fire?

This is not a general off-topic chat

MattJ, yes

General off-topic chat RIP

What will be doing this

My english language level zero

lovetox, hey, what doing?

Runing