XSF Discussion - 2019-09-09

> any of our france friends here in contact with the person? Flow, the person that took over the project got in touch with us, to get it listed at the website again.

https://github.com/xsf/xmpp.org/pull/592

This is frightening.

Admittedly, the README is not the first place to change when resurrecting a new project.

What is that the left overs of that Google thing?

Wave

Daniel, it’s an xmppd

https://ralphm.net/blog/2019/09/09/fastening

Discuss.

fasten your seatbelts

Indeed

It is a long piece based on recent discussions and took me more time than I anticipated. Plenty examples!

+1 for examples

:parrot:

ralphm: thank you for taking the time to write this up (also +1 for :parrot:)

wurstsalat: you're welcome!

It's funny because I was taking part in a discussion this morning about XMPP in general on a Japanese channel, and they were saying it's not easy to get people off LINE (which is the defacto whatsapp-like app there), whereas here in our european (XSF?) circles, most of the time I hear about Slack, twitter etc.

Reading your article made me think of that

Sure. Another example is WeChat, but I think most of my audience is from the so-called Western world.

I also forgot to mention Facebook Templates.

<mention jid="room@muc.this.example/ralphm"/> btw, what about occupant-id?

You mean making it more explicit what kind of jid is referred to?

no I mean https://xmpp.org/extensions/xep-0421.html

It'd be nice if that was also allowed in there

Not especially mandated

I know some people will oppose the de-pseudonymisation

Also what do people have with this "@" :x

Quite annoying to see this on the wire everywhere

I'm not sure, I haven't read that in detail.

Also curious how it'd be different in MIX

pep., that's why the "proxy JIDs for MUC" idea would be slightly better, since it's a drop-in replacement for a real JID

pep.: I don't see a problem with @. It would be something people type and a client could choose to strip it with references.

MattJ, yeah.. I see that

Nobody (generally) has to know what kind of JID it is, it's just a JID

MattJ: right, and for the rest there is disco

ralphm, I see a problem with @, why would we even bother to have a <reference/><mention/> tag otherwise? Why not just put @ralphm in there and let the receiving client deal with it

Client SHOULD NOT include any marker in the body for this

There is no point

On the wire, that is

It could, but the thing prefixed by @ can be interpreted by a server. Maybe it has a nick registration service and allows for referencing non-accupants.

Maybe then the service can also read <reference/> instead

I'm going to start including @s everywhere just to make fun of that service

My examples show that the original didn't have a reference

It's about the same crap idea as 393.

Let's agree to disagree on this point.

You agree that this is a character that carries meaning, no?

I mean essentially that's the goal

By the way, the @ might also serve as an explicit marker to notify whoever is mentioned, as apposed to unprefixed strings that happen to also be a nick. Like someone having a nick 'nick'.

That can be done in the input format yes

Doesn't have to be on the wire, again.

My vantage point is a thin(ner) client

And not touching what the user typed

What about them? They shouldn't have to care about semantics and throw everything in body because?

Why do we even bother with <reference>, somebody remind me please

Or XMPP

Or XMPP

Let's not take Slack as an exemple, it's an implementation not a protocol, and it doesn't try to be compatible with anything else

I think it is useful, you may disagree, and the post shoes how it could be done.

Of course references are useful. I was saying that because of your loose use of "@"

I do take Slack as an example, as it is done well and we can learn from it.

So @pep. if you don't like @'s, I am not sure what to do about it.

.

I don't like the meaning you attach to it

On the wire

I didn't. It is something somebody typed and the MUC service then interpreted it as a mention. Has nothing to do with the wire protocol.

"Here the MUC service marks up the original messages with an explicit link reference." wait

Yes I just read that

That's even more awful than I thought

So yes you did

ugh

I'm sorry I broke your world. I'm a terrible person.

I'm actually amazed you are seriously considering this

To put it as an exemple

Seriously, this is exactly how existing services do things. It is not something*I* invented.

services like? Slack?

It's not even an example ralphm wrote, it came from my gist. I think getting caught up on what hypothetical service the example shows isn't the right thing here.

Kev, it's just that I see this coming back often

ralphm, I’ll dump a bunch of random thoughts on your article on-list

I can’t follow xsf@ right now

@pep: Because it's something easy to understand for examples.

Also Twitter, as mentioned at the top of my post.

I think WeChat, as well. WhatsApp, Facebook, etc.

ralphm, yes and as I said, they're not interoperable protocols, they don't care. they don't especially have to account for let's say, offline users that the MUC doesn't know about anymore (how would it know it has to have a reference there?) etc.

Or for me using @ in a totally different way

The UX in these products is particularly annoying when you just want to use @ and not highlight anybody ✏

But I guess that's a UI issue anyway, for this last message

They still could do that and not include it on the wire

Kev, also my nick is "pep." :)

But I guess you can't autocomplete anymore with the @ in front :p

Well, MUC's model is rather dated, and I think we need to move on from it. I think MIX solves a bunch of that, and I always try to look ahead, while learning from others. For this I don't care about how Evil those other entities or solutions are. Something like an @-mention is near ubiquitous outside our little bubble and I think the least-surprise angle works in its favour.

I'm going to repeat myself: That doesn't mean it has to be on the wire.

That's my only concern

Really, it is just something somebody typed.

IT'S AN EXAMPLE IN A BLOG POST.

With an associated meaning to it

No it's not just an example.

It's definitely not the first time I see it. I even mentioned it last time when there was this references discussion.

If you don't want your service to interpret @ signs, hack it to oblivion.

Of course I don't, why would I. My service could interpret <references> very well though

Great

Do you have any other insights?

.

whatever

sent my feedback on the list

Cool. Thanks!

Also, I am a bit done with negative attitudes.

So, sorry if I was a bit harsh, pep.

I’m gonna re-state it publicly: Thanks for taking the time for the blog post, I think it’s very valuable. My mail on-list is concise and short to save everyones time, but there needs to be time for praise for work done, ralphm.

☺️

ralphm: thanks for taking the time and moving things forward!

fwiw I have not much to say about references in the article, that looks good.

👍

I know some people were not particularly fond of the mandatory <reference> for SIMS, but in this case it makes sense to me. I guess having SIMS being used instead of oob as it currently is could not require it, though?

Yeah, my thing with oob is that it is very unspecific.

Sure. I'm talking about SIMS specifically, I'm not fond of the current practice

(with oob)

Using a jingle file allows for thumbnails and hash references and titles and descriptions, etc.

I suppose you could also have a naked one, without body and without the references wrapper

If you just wanted to send a picture

Yeah, that's a concern I've heard multiple times

ralphm: this is a major use case

Re Jingle, there's no URI format atm right?

Or is there?

ralphm, do you by any chance have a source format for that post publicly anywhere?

Zash: not automatically, no. But I uploaded the source for this post here: https://ralphm.net/~ralphm/tmp/2019-09.xml. I hope you can appreciate it.

let's bikeshed about the use of XML as a source format!

Not just any XML format. It is actually very much derived from DocBook XML

In this case it doesn't reduce the effort in turning it into epub

DocBook enough that pandoc can read it?

It does. You can use pandoc with docbook as input format

But you'd have to fix the custom additions

ralphm, hi, someone friendly has linked me your post on @mentions. i remember a certain discussion in the gajim chatroom >10 years ago. gajim at the time was highlighting the user if any part of a message contained the user's nickname (iirc). so if someone had a nickname of "kate", someone typing "skateboarding" would trip the highlight. gajim changed that to match a fixed word (iirc it was '\bkate\b'), and then people started complaining that declension happens (e.g. "kate's"). do you think you could make @mentions somehow work with that?

what the

oh, hi jonas!

jonas’, indeed

jonas’: you scared from my log source?

what are you, a RTL modifier?

؜, noone will read what you wrote. your nickname is empty, that baffles everyone

that would be impolite… 😛

jonas’: looks like it's actually http://www.fileformat.info/info/unicode/char/00061C/index.htm

I don't see anything, nor do our logs? http://logs.xmpp.org/xsf/2019-09-09

Yeah, conversations also seem to ignore it :)

ralphm, https://sotecware.net/images/dont-puush-me/NUWuPgMbAgbvAn1d8N7yi2ohr4zvDuzpIFANrw5I8_I.png

؜, look at this, they can’t even read what you’re writing

jonas’, I'd want to say "our tools are broken"? :x

oh. i should have seen that coming

https://upload.yax.im/upload/y7oYvc1Z5wrQX5tg/Screenshot_20190909-181529_yaxim.jpg

They should be refused by the muc

they should

jonas’: nice how your text is RTL formatted :P

if only we had our stuff pinned to a single version of Unicode everyone agrees on ✏

nice

pasting cropped yaxim screenshots into yaxim makes my head spin

hah

Yup, Conversations gives up on this. Nameless RTL person, I read your message through the screenshot above, but your unique setup triggers bugs in several clients and will make discussion very hard. If you can it might be good to write a reply on the standards@xmpp.org mailing list.

ralphm: triggering bugs in implementations is actually a Good Thing™

Zash, so logs ignore it but MUC lets it pass?

how come

?

Well yes, it is surely a nice test case

pep.: I've actually copy&pasted it from the http log

pep., it's in the logs

oh

pep.: it's just.... _invisible_!

Sorry I was reading ralphm above who said it wasn't

I see

Though it might not look that way, since there is no nick rendered

Ah, I see now

I can read it in the logs just fine.

linkmauve: you can read it?

Nice way to make the logs look like someone said something they didn't

\o/

my job here is done, i guess

Nameless RTL person: haha

Nameless RTL person: please meet my friend, 🤖

Ge0rG, yes, it’s present in the logs.

linkmauve: that's not what you said

I can read it there.

i remember pasting 4MB of text into a status message and crashing all the psi clients out there. that was fun

linkmauve: how can you read it if it's invisible?

Ge0rG, it isn’t though.

linkmauve: I'm speechless.

xmpp:xlwj4vdisilfdp2r@anon.xmpp.org nice

https://upload.jabberfr.org/Oy8Ag6u4EJUndIbG/wayland-screenshot-2019-09-09_18-24-24.png

Ge0rG, ↑

linkmauve: so you can read *them*, not *it*.

Nameless RTL person: in any case, there's differing opinions on whether a MUC service should do such interpretation. I do think that an explicit marker in front of the mention, whether processed at the client or by a service, helps disambiguation.

i assume it's not an important matter whether the @marker works for some unusual nicknames, either?

Why doesn't resourceprep normalize eat it, whatever it is?

yeah

Nameless RTL person: like RTL markers?

yep.

or, let's make it simpler, spaces in nicknames

or one of my favorites: combining characters vs. precombined characters, typed by different people in different way

Pretty sure those are normalized at least

within message bodies too?

Zash: not if you let the muc server do the mention

Which is the point Nameless RTL person is trying to make I guess

Myeah I don't believe in that

However I see ralphm blog post only as an example for references

I assume existing implementationa just do prefix matching as main heuristic. And give up with"weird" stuff like RTL markers.

Not as a general recommendation that all mentions should be server side

No, indeed

Having followed Slack for quite a while, I believe they initially did server side mentions (only) and then added client side support.

Converse.js does something

Indeed. It uses <references type='mention'/> and strips the "@"

My mail to standards@ shows the alternative (for links, but would work for mentions just as well).

I still think that typing an @, v.s. not, has an implicit request for notifying the mentioned individual. I wonder if that should trigger explicit server side notification, rather than client side highlighting, esp. with offline mobile clients and Push.

ralphm, note that I never disagreed on this ^

ralphm: your muc push could also parse the reference (instead of jumping on the @)

tbh, i'd feel uneasy if someone used my nickname and i wasn't highlighed, whether there was an @ character before my nickname or not

it would feel as if someone talked behind my back

Nickname registration in MUC is a thing

Oh, nm

Daniel: I mean that if you have a client side generated mention, the server could explicitly notify / wake up the recipient. Maybe with a special out-of-band message.

By the way, example 2019-09-02-3 shows client side mention.

Nameless RTL person: services like Slack let you get notified for user defined keywords.

I usually set that up with my nick, name, and 'xmpp'.

Nameless RTL person, your client could very well get over this and _also_ highlight you if you so chose, by parsing body. But that's a choice of the receiving client, and I'm fine with that

so do xmpp clients. but in the xmpp world you may have different nicknames in different chatrooms, etc.

so the client must be smart enough to allow different hl words for different chatrooms

and then the pain is on user to manually configure it

And that's why we can't have nice things

Mwoh

I like that in MIX, much like Slack, is decoupled from the (proxy) JID.

is this place using mix?

I think that especially for group services like those hosted by the XSF, service wide nick registration would be a good thing.

Nameless RTL person: no

still, thanks to federation, even with registration, the nicknames can be different within a single client's opened chat windows

Yes, for sure

But highlighting $current_nick should be easy.

And separate from that server-assisted notification would be a thing that could be implemented.

yeah. so if the receiver client's already implementing it, why bother with the server doing it too?

Your client might be offline (Doze mode or iOS equivalent). Having server support for this allows for waking up such clients.

but if it's a custom highlight word, it won't

inconsistency

Especially in the context of MIX, where you are always in the room, even though you have no active resources.

Nameless RTL person: you could register custom highlights with your server.

And finally, if you get mentioned in rooms you're not in.

ok, that would be nice if there was a subprotocol for that

Nameless RTL person: let's say I've thought about this stuff for a while

i guessed so, this blog post is quite thoughtful

in essence, you'd like to move more of muc complexity onto the server. that's something i can empathize with

however, having the api between the thin client and the server be a plaintext api, as opposed to xml, feels wrong in the context of xmpp…

Well, not just for MUCs. In fact, I think we've come to a point where we need a lot more server involvement to match functionally in other services. That's why I believe something like MIX is better equipped for that world. Another topic is voice/video calls.

moreover, a plaintext api which the user types themselves, making it more difficult to provide a different type of ux than just a text field, if it's desirable within the client's requirements

Nameless RTL person: sure, having clients mark up stuff is very useful

But the example of link references shows the two extremes. When mentioning a URL, do you want your client to go and fetch the page, scan for meta tags, craft a format for representaion, and only then send it (or maybe later as self-fastening) or let the server do that for you?

even more, a plaintext api which is not discoverable by the client. or are you going to make it discoverable whether mix/muc adds annotations automatically or not?

I would definitely, yes. With opt-in/out for your own messages.

maybe. if i know that the mix/muc itself can't access the site i link, and my thick client can, then i would do so

Nameless RTL person: yes, you could still, or course. It is not an exclusive choice.

Configurability everywhere!

But having worked on a (closed) XMPP platform, putting it in the server makes it a lot easier.

If you then have thick clients, you see them already having marked up things and leave it alone.

If your options don't have options, you're doing it wrong!

to me it slowly starts looking like privacy lists, but i'm fine with that

Nameless RTL person: privacy lists were hard because it made routing expensive. I think this kind of thing is different.

so, let say, my thick client, when connecting to a mix/muc, could say "i can do references alone, please don't mess with my messages", and my thin client could say "help me, mix/muc, you're my only hope". a per-session setting would look nice, i guess

I'd probably use a disco feature for it.

who'd disco whom?

The room/service would disco you

It does so anyway

the only worry at this point would be the observable inconsistencies in behavior between messages from different clients. but xmpp users should all be used to that anyway, i guess

i see

I switch between desktop and mobile all the time

ok. would that work in 1-1 chats too?

the job of implementing the annotations would have to be shared between the mix/muc implementation and the, i don't know how it's called… core server?

I don't see why your own server couldn't mark up stuff for you

would the recipient's server mark things up if the sender's server didn't?

(if you want that)

I'm not sure. In MUC, there is a separate entity in the conversation, from which annotations could come.

In 1-on-1, you don't have that, so I'd expect only my own server touching my messages and sending them from my bare JID.

Validations the source jid for references won't be a requirement?

(btw)

Though MUCs can also impersonate you if they want to..

right, this third-party annotator service would have to be trusted

pep.: access control is definitely a thing, and feature dependent

*validating

E.g. reactions can come from anyone. Edits not so much.

An alternative is not actually having one-on-ones, but all your conversations as rooms. I think BuddyCloud did this, as does Slack.

This also allows for smart bots that suggest movie times when you mention The Lion King.

And yes this is invasive, but there's a value proposition there.

i guess i wouldn't mind. my primary client does that anyway, mostly

Sure. I think there's a limit to what you want to stuff in your server, though.

But maybe a model where everyone runs their own server is compelling in the long run.

serverless messaging isn't used anyway, i think

the last time i tried doing so, i got enough spam to leave the xmpp world for close to ten years

Heh

The thing is, if you don't trust your server, there are suddenly a lot of things you can't do.

i want to trust the server in the capacity of routing messages correctly, not much more than that

U+061C ARABIC LETTER MARK wha

hi Zash!

Take those emoji reactions. If all the exchanges have e2ee, you can't do summaries efficiently.

(in MAM)

my perfect setup would be a server whose only job is to route messages within a federated network, a thick "xmpp client" set up on my private always-on account somewhere, and a thin non-xmpp client connecting to that thick client and only do UX

Hm. I'd probably shift the thick bits to the server and just use thin clients.

a bit like irc server/irc bouncer/irc client setup used to be popular

Even for annotations, by server could intercept outgoing messages and send extra stanzas.

the bouncer part would implement the hard bits of the client, like maybe encryption, annotation, etc. and would run either on my local machine, or somewhere in the cloud under my control.

I have at some played with the idea of bare-account-jid-components

Which is mostly that

and if we could deal away with JIDs used as personalities, that'd be perfect. they're good for routing, but not much more than that in my opinion

A special client connection that doesn't bind a resource and can manipulate traffic.

but at that point it wouldn't be xmpp anymore

Why?

I don't have a very strict concept of what can be called XMPP.

not interoperable enough with clients implementing 3920/3921

In fact, you can totally do XMPP Core only.

There are situations where you'd only do s2s, not c2s, e.g. to federate an existing system with XMPP.

From the other side, you wouldn't be able to tell.

oh. then i'm happy to be informed that icq was an xmpp client thanks to transports

I've implemented and run services with an XMPP PubSub interface that didn't support the publishing and node creation bits of the protocol. Nodes magically existed as a function of business logic.

i see.

Nameless RTL person: well sure, the transports were basically IRC etc. clients that magically made other IRC users have a JID.

then i used wrong name.

I am a strong believer in the protocols. I don't care much about the things behind the scenes.

"then it wouldn't be xmpp instant messaging anymore"

Nameless RTL person: if you create an identity model that's not based on xmpp JIDs, suddenly many xmpp features stop making sense.

Ge0rG, exactly what i meant by that sentence

If you want decentralized identities, you end up with public keys being user identifiers, and then every message must be a signed (+ encrypted) blob and routing follows some overlay structure.

And then xmpp is only a hindrance

Ge0rG: yup, I agree with that. But there's no reason why you couldn't have a thing that sits with the bare JID and manipulate incoming and outgoing traffic to assist regular clients.

You could of course use the xmpp message format inside the encrypted blob, so that you can have all the client side XEPs

ralphm: but the bare JID is owned by your server, not by you!

And the server is mostly trusted

If my server allows for a special API, e.g. with a kind of client-component, to act on behalf of my bare JID, why not?

i'd be fine with user-visible JIDs, as long as there was a metaprotocol stating that those several JIDs are all me, other people can discover these other JIDs easily, and normal users could be made oblivious to their existence

ralphm: what would that give you that can't be given by the server directly?

Always on scriptability, and other stuff you want to have, your server might not provide, and offloads clients.

But annotations could be one example.

Nameless RTL person: so you want to use xmpp as the routing layer for a p2p protocol based on a cryptographic identity?

a simplest solution would be a simple discovery protocol of "how can i contact you in other ways" + crypto signing of auth requests

and keep all the rest of xmpp intact

Nameless RTL person: then it's just a very sophisticated mechanism to exchange encrypted blobs.

No benefit on top of protobuf over DTLS with TURN

not reinventing all the things? If you can use client XEPs for example

in this sense, xmpp itself is just a very sophisticated mechanism to exchange xml on top of tcp

Oh, if you want Jingle-negotiated p2p XML Streams, why not?

i've never written anywhere i want p2p or jingle

Much like Local Link Messaging

Nameless RTL person: true

pep.: yes, but you need to map your cryptographic identity scheme to faux JIDs to make most client XEPs work

Ge0rG, something like <fp>@domain? That you could change at will

Nameless RTL person: p2p is just the consequence of decoupling your identity from your JID

pep.: `0xdeadbeef@onion/yaxim`

except by having actual xmpp servers, i don't need to do routing, offline storage, etc.

Ge0rG, that :)

With onion being the verbatim name of the used cryptographic identity protocol

Nameless RTL person: which server would keep your offline messages if you have three different JIDs?

all of them.

depending on which one received a given message ✏

As if deduplication wasn't hard enough already

Nameless RTL person: so if one of them fails, you only receive two thirds of your backlog?

yep.

(which is already the case anyway)

(I mean, if your server fails, you receive 0/1 of your backlog)

⅔ > 0

Congratulations! You've created a protocol that combines the drawbacks of xmpp with the drawbacks of p2p!

thank you, i'm very happy

it's still better than not having any means to move accounts between servers in case of problems, or in case of, let say, just being disappointed with the server operator

Nameless RTL person: ask pep. about Moved.

True, that helps with <moved/>. And that's kind of where changes on that XEP are leading anyway..

Well for what it is worth, running my own server, e2ee is overrated at best and a pain at worst.

ralphm, lots of people in this room specifically agree with you. Not so many outside of it :)

ralphm: welcome to the club of OMEMO rejects.

i talked to pep. about it, yes. i don't find it a good solution

besides, what's wrong with just stating my other JIDs? i can make a contact in my smartphone having multiple phone numbers and it works

pep.: Is moved more than https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-gone with forwarding address?

pep.: yes I am aware

Nameless RTL person: your contacts are managed by you. Your "friend's" alternative JIDs are managed by them

pep.: I also have issues with crypto-currencies.

yeah, and we're in an era where computers are supposed to help managing things up

ralphm, yes it's more than <gone/>. We discussed it a few times, I could grep through the logs, I don't remember much off-hand

ralphm: the biggest issue with Moved is that all mechanisms it provides are ephemeral

pep.: yeah, I vaguely remember. Happy to pick that back up at some point.

What Ge0rG says

You can very well make it so the current <moved/> is changed minimally and serves some part of the requirements

But there's a demand for more and that would likely require crypto identities

Ge0rG: I added node delete + forwarding address notification, to cover that case with nodes-as-things, and implement moving 'things' between websites, habing all subscribers rewrite their references

But you'd need pep to persist the tombstone

ralphm: yes

Ah yes the tombstone. That you should keep on the old server and that your contacts should keep on their servers as well..

see ya!

Anyway. "Not today!"

ralphm: when I first looked at Moved, I was under the impression that all it needs are two or three minor changes to work in today's environment. But it turned out to be a bottomless pit

Do I have to send presence to a muc before I create/configure it over iq?

"has left the room due to an error (Kicked: jid malformed)" oops?

another testcase for the jid corpus \o/

Zash, which ones of your clients got kicked btw?

Huh?

Zash has left the room due to an error (Kicked: jid malformed)

Got an exact timestamp?

Or aproximate

03:39:29+09:00

... got it in UTC+2?

Dude

21:39

what, my vps is in Japan, still..

That's in the future :|

If Zash can't do substractions, why are we letting him write code?

wait, 20:39

Or pep.

It's late and I'm tired

I got confused by tmux showing me the current datetime

*time

ralphm, you know how brains are really terrible at basic math, while pretty good at extremely complicated tasks like walking without falling over?

https://ppjet.bouah.net/tmux-time.png

(Yes that's a nested tmux)

Zash: I'm not sure if that's true at all.

It is likely dependent on how often you it.

Hush, I read it on the Internet, it must be true. And then it's totally sensible that I'd be terrible at math while being good at telling computers to do math.

Also, I'm lazy and tired.

And it's late.

Zash: no worries

pep., http://paste.debian.net/1099725/

``` 00000000: 6672 6f6d 3d27 7873 6640 6d75 632e 786d from='xsf@muc.xm 00000010: 7070 2e6f 7267 2fd8 9c27 pp.org/..' ```

Zash: what's /x?

.

Zash, yes, that's U+061C and x

Where did my paste go

Zash: your server complained about the X, not about the RTL

Huh

less wins over lnav Sep 09 20:39:28 stanzarouter warn Received stanza with invalid source JID: xsf@muc.xmpp.org/<U+061C>x

less is more

So a modifier by itself is ok, but modifying x is not?

LATIN SMALL LETTER X isn't arabic, so I guess

Can you tell what rule fails?

I'm not behind a machine to check right now

Looks like this behaves differently between libidn and ICU

ICU rejects, libidn accepts

Yay for consistency

Robot face bug again

Zash: why is your server enforcing it on incoming s2s?

I'm using ICU, libidn is usually the default.

Isn't rejecting invalid stuff at your edge perfectly fine?

So we don't have specs saying what's actually valid?

pep., we do. three of them.

Great

ralphm: is getting kicked from a MUC because somebody sent junk perfectly fine?

Ge0rG, at least it should be fine with robot face now

ralphm: some servers will even tear down s2s

Well, yeah, that sucks

Zash: don't challenge me

Ge0rG: I'd say the MUC should kick them

The two libraries differ in how they treat unassigned code points. ICU rejects by default, libidn accepts by default.

pep.: yes, but it doesn't. What now?

That's why you got robot face bug in the past, getting ICU-users kicked.

we do have specs which do checks against RTL-weirdness, specifically stringprep

RFC 6122 has wording on that

But prosody if built with ICU now (in trunk) will tell ICU to behave like libidn.

https://tools.ietf.org/html/rfc6122#appendix-A.6 https://tools.ietf.org/html/rfc3454#section-6

2) If a string contains any RandALCat character, the string MUST NOT contain any LCat character. 3) If a string contains any RandALCat character, a RandALCat character MUST be the first character of the string, and a RandALCat character MUST be the last character of the string.

And the MUC here uses libidn

pep., ^

jonas’, TL;DR rejecting is correct?

Zash, probably, I’d have to check the categories of the involved characters

U+061C ARABIC LETTER MARK U+0078 LATIN SMALL LETTER X

u+061c is invalid because it’s unassigned to my validator

Hm, is that going to bypass the rule forbidding empty nicknames;

Zash, but yes, if we used a newer unicode version: U+061C is AL, thus RandALCat as per StringPrep, U+0078 is bidi category L, which is LCat, which MUST NOT occur in a string with RandALCat

One of the issues might be that resourceprep is defined using Unicode 3.2 and this codepoint is 6.3.

fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell

ralphm, yeah, that’s what I meant when I said "u+061c is invalid because it’s unassigned to my validator"

Zash, so, yes, rejecting is valid, but only if you also reject U+061C on its own

otherwise you’re rejecting based on the wrong reasons, at least if you’re using resourceprep from RFC 6122 as basis

(if you’re using PRECIS, I don’t know)

Probably something is using newer tables for normalization.

Not using PRECIS

Neither of the two libraries I can currently choose between has PRECIS

Zash, then something is wrong on your end if it allows U+061C, but not U+061C U+0078

So the logical consequence is to reject strictly on c2s and less strictly on s2s?

Also no 🥓 or 🦒 in resources

Ge0rG, I think that’s the only sane way forward

So you can't get kicked because of somebody else

"Ge0rG> pep.: yes, but it doesn't. What now?" You also validate and reject it (send message errors)

Ge0rG: why wouldn't a server reject incoming invalid JIDs on s2s?

That other server is clearly not checking properly

Problem: Allowing unassigned code points has been the default (probably unintentionally) too long. Everything will be painful.

ralphm: because what happened to Zash in this MUC today

So xmpp.org is at fault

It apparently accepted the bad jid and then also sent it on?

In turn because libidn and relaxed defaults.

ralphm, yes

> jonas’> fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell Isn't this only true if we accept unassigned codepoints?

Postulate that we do.

flow, jonas’ stated that there may be things that normalize to different things between versions

unicode standard versions?

Yes

Potentially yes, but I'd expect that to be very rare. Could be wrong though

flow, also, as I mentioned earlier, accepting unassigned codepoints is the default in libidn and thus prosody for some reason

and probably other users of libidn

Something else ftw

Just reading ralphm blog post. So 2019-09-02-14 attaches to 2019-09-02-11, but since -11 has been corrected multiple times, it actually attches to 2019-09-02-13?

flow: as currently envisioned, attaching is solely to the original stanza.

But I agree this part is something needing more thought.

It might be useful to specify a second id, in this case the edit

well that id you already have, the <stanza-id/> of the stanza performing the edit, no?

"apply to 1, as modified by 2"

Wave but not quite?

ralphm, xep372 begin/end are zero indexed

Because it depends on semantics of the thing being attached.

it appears you use 1-index in your examples

Yeah, I also think how much we potentially could learn from wave

flow: oh, I'll check that tomorrow

A look at the wave spec couldn't hurt

Protobufs, just like Ge0rG wanted

E.g. for reactions you generally apply to the 'message' irregardless of edits.

But references break with edits.

Yeah Ge0rG and stanza versioning has come up a few times in private discussions I've had in this.

I was not involved in any backroom deals!

I've just read up on U+061C, it's assigned since 2013 and in the Cf category, which means it is a control character and hence disallowed in resourceparts

yay, protobufs, this NIH thing known only because google invented it

It also magically solves all protocol problems

Isn't that just a serialisation format? (I've never actually used it)

indeed. seen a bad case of hyperprotobufoxia before

Why does XMPP even exist when protobufs can do all that?

Or was it MQTT?

pep.: I haven't used it either, which makes me qualified to describe exactly what it is. And I say "versioned structs".

pep., yes, it's a serialization format that's mediocre at what it can express (lots of great prior work) with somewhat good tooling (something that, i think, was the actual breakthrough of protobufs)

So it's like JSON?

more strongly typed

I see

also, binary

It's like C structs

With version numbers!

and not self-describing, ie. you can't parse a protobuf binary encoding unless you know the spec used to generate it

and not self-terminating either, ie. if you have a binary message, only part of it being a protobuf, you need to figure out where it ends on your own (e.g. sending length separately)

So you write some C struct definition and then run some tooling that spits out tons of boilerplate for whatever language.

both of these result in shorter messages though

Not being self-describing will do that for you

chat states in this webchat thing are so annoying

it's not a bad tool, but those google folks could have instead support an existing standard instead. that's why it's NIH

flow: but it being unassigned in Unicode 3.2 makes the rest of your argument moot anyway?

Or are you looking at Précis?

So I guess 🥓 being a So makes it acceptable for a resource?

Bacon is always acceptable