XSF Discussion - 2021-08-25

'ello! I have a question about a XEP which I guess exists. What XEP defines how a 'raw' (?) text message should look like and what metadata it contains for the clients to interpret and display it right to the user? I'd like to see how it's built for a second, later question.

me9: welcome! The body of messages is actually defined by the core RFCs, not in an XEP. However, that's just text (no special formatting or anything). Metadata and formatting is defined by many different XEPs depending on the feature you want.

(the IETF maintains the core of XMPP in a handful of RFCs, the XSF maintains any extensions to the core protocol in XEPs)

Is there something specific you're looking to learn how to do? Maybe I can point you at a more concrete document

I'm looking for what metadata there is for time and date.

me9 like https://xmpp.org/extensions/xep-0203.html ?

Uuuhhh.

I don't understand what it does. But I can tell/show you what I was thinking about.

Sure, that might help

me9: As the XEP title suggests, the idea is to only add <delay/> timestamps in case the message was actually delayed for some reason (sender was offline while the message was written, message was stored in MAM/offline spool, ...). The idea is that you can assume instant delivery if no such timestamp is included. (But of course there's no _guarantee_).

XMPP's original standard operation was _instant_ messaging ... :-)

Holger: Aha ok. Well I just meant how date and time look universally before the client shows it right.

> Holger wrote: > XMPP's original standard operation was _instant_ messaging ... :-) Yeah I get it. That's also interesting.

XEPs that add timestamps usually refer to this format: https://xmpp.org/extensions/xep-0082.html

me9, https://xmpp.org/extensions/xep-0082.html maybe?

Holger <-> flow 1:0

Mhm. Seems right.

XD

Seems the XEP is talking about the problem someone and me found.

A bit.

me9, feel free to elaborate on the problem

Wait a bit, I want to look at that XEP. It's always so long.. :))

But maybe you can think about my idea while I'm reading. This is also about the formatting of quotes. There's an issue on one XMPP client (Blabber.im). Blabber normally does this when you quote woth the ontegrated function of quoting: ```[nick] wrote: > [quoted text]``` But the issue wanted to add a date to that. But we figured that only a client adding a date wouldn't be internationally friendly, as when you have people from.different countries and rimezones meeting, they write and display date and time (very) differently. So what we'd need for a date to be added would probably be some kind of XEP which let's the cleitn translate the date and time into the persons local format. Here's what I wrote at the end: https://codeberg.org/kriztan/blabber.im/issues/499#issuecomment-249559

So this is actually about the text before a quote, which more than one client would have to use for it to be useful and not confusing.

Maybe the idea is just too fiddly and not useful for many people, I don't know... Just wanted to give a readäson to close that issue, really. ✏

Maybe the idea is just too fiddly and not useful for many people, I don't know... Just wanted to give a reason to close that issue, really. ✏

Quotes are currently just plain text prefixed by `>`. There's a XEP or two for referencing earlier messages by id, which would likely make things easier in the long run

me9 to takle this problem, you'd need message references/fastening

tackle, that is

> Zash wrote: > Quotes are currently just plain text prefixed by `>`. There's a XEP or two for referencing earlier messages by id, which would likely make things easier in the long run IDs would be very useful, that's true.

wurstsalat: Is that what Zash meant?

yep, didn't see that message

Okay.

https://xmpp.org/extensions/xep-0082.html at point 6. Security Considerations: > [...] if it's set to the local time of a user, and thus concerns users' *privcacy*. To avoid this issue developers are advised to [...] :D ✏

me9, feel free to PR :) -> https://github.com/xsf/xeps/

jonas’: A PR for removing one character in that giant text? Okay.

That should make review easy

me9, what else? :)

can't give you +w on the repository and I can't do it myself right now

Dunno. There was also that editor JID for errata. But I'll try.

editor ... JID?

editor@xmpp.org

I think there is only a editor mail address

that's no JID

what flow says

Uh. Okay. :D

it would end up with me making a PR though ;)

(or the equivalent of...)

Okay I'll do it jonas’ xD

One freaky character.

Heh.

maybe you can find something else to fix in that document, too :)

an improvement is an improvement, no matter how small it is

true

many people probably just skimmed past that and possibly thought "ugh, they can't even edit their documents properly!!kk"

Hmm.

So my quote-date-stuff idea wasn't very good, I guess?

if only we had proper markup instead of magic characters stuffed in <body/>

Do you always use 'an' before 'X...' words? Or just when the long version begins with a vowel?

me9: You use it when 'X' is the first letter of an abbreviation, because it's about pronounciation, not spelling. "An (e)XMPP client."

an exx emm pee pee

Holger <-> jonas’ 1:0

Ah, because one says ex for x?

me9, yes

Holger, :P

Holger: You already have two points. What now? You won?

I'd say so, waiting for presents now.

<presents type="unavailable"/>

thanks for the giggles (again)

Ha! I found one more inconsistency in 0082. XD

Did somebody already point out the following little UI issues, which seems to appear with every single XEP? (Or is it just my browser being weird?)

https://upload.wiuwiu.de/share.php/2cf0b044-64d8-4976-b1e7-8cf60a1aac90/20210825_134516681_b421.jpg

Looks fine here

probably an edge-case with that very narrow screen

feel free to open an issue with that screenshot, I think there can be something done about it

Looked fine on every screen width I tried

Ctrl-Shift-M in Firefox and then resized the viewport, could not reproduce that overlap issue.

Looks even good on mobile with fennec here.

> probably an edge-case with that very narrow screen But at the JabberID the width is more than enough. Maybe some browser doing weird things withs padding or how it was called again.

> jonas’ wrote: > probably an edge-case with that very narrow screen I zoomed in and cut off something, it looks different.

The photo is from Ungoogled Chromium on my phone but with the desktop view. Both desktop and mobile view do it in Ungoogled Chromium. But with Fennec, it's perfectly fine.

Edge case it is then

wurstsalat, no they said Chromium, not Edge *scnr*

Touché

Hehe.

My little PR should be good and deployed now by the way.

me9, next editor work window is next tuesday, so don't hold your breath :)

jonas’: Fine 👍

Do I have to do that CLA thing?

MattJ, jonas’, do you have plans/ideas on how to proceed with https://github.com/xsf/xmpp.org/pull/953 ? should I rebase it peridically? anything I can do to help reviewing?

me9, I don't think that this contribution is really copyrightable, so it would've been OK without I guess

jonas’: I did it anyway. It remembers that for the rest, right? ✏

it does

Good.

I am writing up a list of open questions about ad-hoc commands because this entire XEP is confusing to me. I will submit a patch to try and clarify any of them at a later date, please consider adding your own questions to the document. Thanks. https://pad.disroot.org/p/adhocquestions

better don't look at what "execute" means.

Oh yah, that's one I should add. All it had to say was "also there's a default action" and it would make sense, but instead it's got tons of text about when "execute" means something else or means itself and what?

no, no, noooooo

I said you should *not* look at it :P

Anyways, I'm sick of reading and re-reading this and having dozens of bugs due to misreading the spec (no idea if it's me or others misreading the spec, but I'm doing whatever I see other things doing) so I'm going to at least try to put together a PR if I can get it all straight in my head. First step is listing the questions.

Sam you may want to look at (and add to) https://wiki.xmpp.org/web/XEP-Remarks/XEP-0050:Ad-Hoc_Commands

good to know; thanks

wurstsalat, next steps - I just want to give it a quick review, merge and deploy. My usual time allocated to XSF infrastructure was yesterday, but it got taken over by other stuff. I'll get to it soon!

MattJ: thanks :) I'll rebase next monday then

It has come to my attention that XEP-0363 (http upload) requires a particular kind of transport security (TLS), with seemingly no regard for things like .onion domains. This makes onion-service admins either to jump through hoops to enable a redundant and useless (no cert verification performed by clients) security layer, or to go against the spec, allowing http://abcdef.onion up-/download. Would it be too late to change the xep to require some unspecified transport security form, only referring to TLS and onion services in a note?

I should add that, in my observation, many onion services go against the spec here

Related observation: Things that do the aesgcm:// thing, they can't deal with http://

:nod:

Luckily that's not a XEP so not our problem! YOLO GLHF /me hides

Hm? It's been a xep since december, if I'm not mistaken :p

Has it?

Let me look up the number

Oh, historical

454

`/correct s/XEP/Standards Track XEP/` then

Okay then :) ✏

I hope for future orthogonalization of file encryption (aes gcm) and transport protocols (http over tls, http over onion...)

Something something reference to earlier talk about things being rushed into production ahead of standardization and causing awkwardness.

Something like `omemo:http://abcdef.onion/path/to/file#foo`

I've seen e.g. git+https:// elsewhere. Some MIME thing could also have worked

`application/some-encrypted-container` 🤷️

Yeah, `aesgcm+https` scheme would have worked too ✏

inb4 `aesgcm+tftp://`

We're getting dangerously bikesheddy

Nah, I'm just sprinting ahead on tangents

Right

Going back to 0363, clients generally seem to allow plain http upload too, with a notable exception of Gajim (if I'm reading the code correctly). But, e.g., this <https://github.com/dino/dino/pull/1098> Dino PR, if accepted as is, would break the, admittedly non-standard, functionality

There was a question somewhere earlier about whether file transfer used UDP or TCP. Recently there's been deployment of TURN UDP proxies. Soooo could you do say TFTP over TURN? That'd be funny.

Maybe the whole thing will break down and everyone will move towards Jingle File Transfer? (plz do)

Would it be possible to ditch http and jingle it to the server and the server transfers it over jingle to other clients requesting the file?

JFT can use HTTP Upload for transport per some XEP somewhere, and OMEMO for security, so in theory it should be possible to combine those properties and not have to use the assgcm:// hack

Nah, SIMS FTW

mdosch, why not? "over jingle" can mean a lot of things tho

mjk, SIMS being something of a combination of Jingle File Transfer and Jingle Message Initialization...

Ok nevermind me

And then there's XEP-0447 and 448...

Jm2c regarding 0363

A/B fight plz