XSF Discussion - 2021-06-09

hello, this is my first XMPP message.

Hi, welcome

this is a very cool technology, I wish more people were on here.

is there anything I should know about XMPP? are there any stupid mistakes to avoid? or should I just learn as I go.

as a developer or as a user?

Just as a user for now.

just learn, dont share private confidential information and enjoy.

Heartly welcome :-) inez

Perhaps you wanna explore the group chats. ✏

Is this the right forum to ask questions about XEPs?

I've been reading XEP-0045, and either there's an error, or I've misunderstood

Yes, this is a good place to ask.

https://xmpp.org/extensions/xep-0045.html#example-61 shows the one-to-one messages exchanged between two users prior to converting to a MUC

https://xmpp.org/extensions/xep-0045.html#example-63 shows the owner of the new muc emitting the one-to-one conversation history into the muc

Is the 2nd message in the 2nd example incorrect? It doesn't contain any context of the original author of the message (wiccarocks@...)

thank you eevvoor

Dan C, hi! Yes, this is a good place.

Dan C, the text under talks about the delayed delivery stamp indicating that, but you are right in that the example seems to be wrong.

How can I contribute fixes?

The question is complicated though. I don’t know if any client actually implements that. You’re right to point out that the information is missing, but I’m hesitant to call the example wrong; I don’t think there is any protocol which could be used instead.

Zash, the delayed delivery does not indicate the original sedner.

and the delayed delivery havign from="original sender" would be wrong, because the original sender wasn’t the entity delaying

this would be more of a case for Stanza Forwarding, but that didn’t exist yet

Dan C, in general, fixes can be contributed on github (https://github.com/xsf/xeps).

For XEPs which are Draft or later (see the graphic at the top of the document), the fixes need to be approved by the XMPP Council (to avoid unintended breaking changes)

we are also currently trialing a thing where changes must be brought to the standards@ mailing list first

Welcome inez

Anybody else know their first XMPP message?

-> https://mail.jabber.org/mailman/listinfo/standards

Dan C, and changing what you pointed out... definitley needs to have broader discussion, as it wouldn’t be immediately clear to me (and probably many others) what the *right* fix would be

Thanks, John. How do you do that colored text thing? Is it just when someone mentions your name automatically? (Maybe something my client does? I'm using Gajim)

On it. Thanks Jonas!

inez: yes because I mentioned your nickname

Dan C: the challenge is how to add 1:1 messages into a room in a secure fashion

Oh, okay, cool! Thank you for explaining that. :)

Dan C, so the concrete way forward would be either: - Propose a patch on github and bring it up for discussion on standards@ - Bring the issue up on standards@ first and look for consensus for a fix there

A specific patch is generally good because it gives something to discuss about, so if it’s not too much hassle to you, I suggest the first option.

Perfect! Thanks!

I would suggest using https://xmpp.org/extensions/xep-0297.html and some useful client-side indication that history might be fake.

+1 for stanza forwarding, because it’ll render blank on unsupporting clients :)

though I don’t want to imagine what <forwarded/> inside type="groupchat" does to stupid '280 implementations

also it allows proper attribution

jonas’: I hope we have sorted them all out

you could also have some weird in-body quote style

Not just ``` <delay xmlns='urn:xmpp:delay' - from='crone1@shakespeare.lit/desktop' + from='wiccarocks@shakespeare.lit/laptop' ``` on the second message in example 63?

That was my initial thought, Zash, to simply fix the current example.

inez: also the text can be colored with XHTML

which seems to be supported by > Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime [...], as well as the JID of the original sender of each message (via the 'from' attribute);

<p style="color: fuchsia"> I've never used XHTML before, I don't think I'll do it right the first time.</p>

But certainly the security considerations are worrying. The idea of someone choosing to put "our" private conversation into a potentially public MUC without consent is worrying. The XEP says "Sends history of the one-to-one chat to the room (this is purely discretionary; however, because it might cause information leakage, the client ought to warn the user before doing so)" but this is a note, not a requirement. There's nothing I, as a user, could do to restrict that loss of privacy. Enforcing that it's a members-only MUC might alleviate that specific example?

wait no tha's CSS

Zash, no, because wiccarocks is not who delayed it.

> The Jabber ID of the entity that originally sent the XML stanza or that delayed the delivery of the stanza (e.g., the address of a multi-user chat room).

*sigh*

of course it’s unclear what @from means

well, then that could do

😃

Oh great

Wait does that mean I'm wrong about needing an origin-timestamp xep?

inez, LIKE TISH

Is there a use case where it would be useful to have crone1 in that field?

Dan C, well, the privacy stuff isn’t something you can fix in a standard. A client (or user) can always take a screeshot of your conversation and post it to facebook :)

I can see the color, but I can't see how you did it :/

inez, your client does not fully support it

oh, what client do you use?

eyeCU

Dan C: in practice, anybody can forward any private messages to any public room. It's just a matter of clients doing it by default / automatically / without user consent

Maybe I will try out other clients. I've only used Gajim and Pidgin.

Thanks Zash, jonas’, Ge0rG ❤️

> https://www.w3schools.com/js/js_json_xml.asp What about

Imo XMPP better 😂

şişio, I think they intentionally used that XML example to show JSON shorter

> John wrote: > şişio, I think they intentionally used that XML example to show JSON shorter Maybe

I will stay on the XMPP ✏

şişio: A humble opinion: XML / JSON don't really matter at all. XMPP is much more than XML and could also be JSON one day. It's the modular approach of the protocol (can be extremely simple or lots of funtionalities) and federation that makes its strength.

Exactly

or EXI

or ASN.1

or s-expressions

CSV or bust

HL7

Is there an ASN.1 serialization format for s-expressions?

or CBOR

I seem to remember there as an XEP (perhaps one with no number assigned) that proposed a binary encoding for C2S stanzas, for devices where XML encoding and decoding was too resource-intensive?

EXI?

Hmmmm yeah that seems about right (though I remembered one of the authors with an @nokia.com email, for some reason). I guess there's no real need for such complexity these days, when an ESP32 can run circles around most mobile CPUs from 20 years ago.

I hear it's good for IoT devices and stuff.

deuill: consuming the least required power is always a good thing in tight scenarios

I'd be surprised if EXI consumed a measurable amount of power less than XML

Maybe its measurable if you have millions of messages per day. But then other micro optimizations would also be a big chance.

moparisthebest: power (and bandwidth!) for data transfer aswell

The #1 power draw in my laptop is the wifi chip :p

tell me about it

I am deep down in the XML parsing/processing optimization rabbithole :)

I'd be surprised if EXI consumed a measurable amount of bandwidth less than compressed XML

Compressed XML is a security risk

Also the benefit I see with EXI is that you can filter stanzas unknown to the client on the server side

As implemented currently yes, doesn't have to be

moparisthebest: the problem is known for how long now? Eight years?

Also what evidence do you have that EXI isn't a security risk, I think last time we discussed it we determined it had the same security problem

How was it, EXI has optional zlib or such?

I always wonderd why we don't use compression anymore with an updated method. Also that security risk sounds highly theoretical in the first place..

The compression fix has been known for that long too iirc?

Just no one has written a spec or implemented it

moparisthebest, EXI knows more about the stream, so my base assumption (from experience of benchmarking different compression algorithms on small subsets of data against a specialized one) would be that it’s better than generic compression

and that without the risk of generic compression ✏

because it knows more about the stream :)

one major use case would be for instance to tell it about base64 things

you get the base64 overhead completely reverted, with zero risk of generic compression schemes

Mmmmm

and of course put the stream-level element name in a single byte, because they fit in that (with 0xff for "unexpected thing, localname/nsuri pair follows" for instance) instead of N bytes.

(disclaimer: I only briefly looked at EXI and talked to Arc about it a bit, but my understanding is that this is essentially how it works)

next, generic compression is memory intensive (IIRC that was also a good reason not to have it enabled server side?); EXI would probably not be that, or at least you can more easily share the state across streams

EXI has dictionaries and such too which could make it vulnerable to CRIME style attacks

<hat:server-implementer>Yes, compression uses a ton of extra memory per connection. Happy without that</>

moparisthebest, only if the dictionaries can be influenced by an attacker

and yes, you are right of course that specialized compression can be better, but it's an issue of how much better, and if it's worth actually doing it

vs throwing XML at zstd or whatever

Using a fixed dictionary likely falls in between generic zlib and EXI

> moparisthebest wrote: > HL7 *screams*

a fellow healthcare ~~sufferer~~worker I see

> > <@wuuko:matrix.org> But I still don't understand how XMPP is central. > XMPP as a whole isn't; your user account exists on the server you choose, and all the servers talk to each other, so it's federated (a form of decentralization) just like Matrix in that sense. but when you create a MUC, it exists on the server that it's created on, and that server is responsible for it - if the server goes down, the room is down too

What about?

But ı think public chats are not important. And XMPP has got default e2e

https://upload.blabber.im/3c9f8e644cf7bee0/009a46f716dd96f2.jpg

But rvick doc files e2e is partial

moparisthebest; i only worked there temporarily

that was enough...

qy: the brain damage is permanent though

What's the hell happened?

E2EE in XMPP is not partial. It's perfectly secure, just like Signal.

> robertooo wrote: > E2EE in XMPP is not partial. It's perfectly secure, just like Signal. Yes default

I shared the picture

I between the XMPP and Matrix. Which and why is better? My goal is security and privacy.

robertooo, has it been audited at all. That's the only thing that concerns me.

qrpnxz, https://conversations.im/omemo/audit.pdf

danke

For my talk today (with some fun in mind) I defined the XMPP Bermuda triangle 😉 😊️

https://jabbers.one:5281/upload/RcbN5ekuxgkcBm7k/3a23afd2-fba9-4020-a1c5-4dcb0dffbadc.png

> I between the XMPP and Matrix. Which and why is better? > My goal is security and privacy. I'd go for xmpp, but what answer did you expect in an xmpp MUC?

If your goal is most privacy/security neither xmpp nor matrix are what you want.

> mdosch wrote: > If your goal is most privacy/security neither xmpp nor matrix are what you want. What do I need?

No idea, maybe tox or briar?

Maybe a cabin in the woods?

^ yep, need to just turn off all electronics and live in a cave

> Maybe a cabin in the woods? And potatoe fields!

but if you want tech, XMPP is the best

of course you aren't going to get a fair comparison here, people here have generally already evaluated options and chosen XMPP

> mdosch wrote: > No idea, maybe tox or briar? Briar is best but only Android

And Briar hasnt got offline message

Bucause there is no server

So the remaining xmpp and matrix

But true, Briar is best.

> And Briar hasnt got offline message > Bucause there is no server You want maximum security or comfort? Offline messages need a server to be stored on. A server storing stuff is not 100% security (if such a thing even exists).

> And potatoe fields! And furnace to craft some primitive XEPs

mdosch: you technically don't need a "server" for offline messages, but to handle that in a p2p network you need to replicate it across several nodes to maximize the probability of getting it delivered, and now since nodes store things for the others that opens a whole new can of worms

> mdosch wrote: > You want maximum security or comfort? Offline messages need a server to be stored on. A server storing stuff is not 100% security (if such a thing even exists). So how does your own server compare to Briar?

What's the threat model? Who do you wish to be secure *from*?

I remember you asked the same questions some days ago already. What is bothering you that you are again and again uneasy with xmpp, and in between post "❤️xmpp " and stuff? Maybe think about what you don't like about xmpp that you can't settle