jdev - 2022-12-16

In current Unicode using PRECIS that jid would fail the bidi rule and be invalid: https://go.dev/play/p/HylpIxghJ8P

Luckily nothing in the wild uses precis or ever can

It works great; some people are just too conservative and refuse to upgrade because "using ancient versions of Unicode is how it's always been done"

It's literally impossible to upgrade

It's quite easy to upgrade.

Sure hope you're not talking about Prosody, we're waiting for https://unicode-org.atlassian.net/browse/ICU-11981

How would it work? Just allow half the network to not interop with the other half until everyone is upgraded? A flag day?

As opposed to the old thing which literally hardcore's an ancient version of Unicode, but somehow that's upgradable?

No, we don't have an upgrade path that works

Well or at all, precis exists but there is no way to upgrade the federated network to it

YOLO upgrade and see who breaks 🤷️

> impossible strong claims need strong evidence, posted to a mailing list, that I'm not going to read now

Has it been a decade and no one has proposed an upgrade path yet?

No

PRECIS is dated 2015, come back in 2025

9 years is close enough lol

Or 8, maybe I should go to bed

Probably if all XMPP servers started validating local accounts are valid with both precis and stringprep, and then we wait a decade, we can probably remove the stringprep code?

Prosody validates locally created things (user and MUC localparts, MUC nicknames) according to stringprep, not much else we can do until ICU gains support (or someone RIIRs all our C code)

Things created by remote entities are not validated as strictly, so things Should Work if everyone acts the same.

moparisthebest, fwiw, I think there is intentionally no upgrade path. it's similar to IDNA 2003 to 2008

So in pubsub you can subscribe/unsubscribe, obviously, which is how I've always used it. There's also "filtered notifications" where you advertise nodes in caps, which I always thought was an explicit "go ahead and subscribe me to these nodes so I don't have to do it every time", but apparently it's a filter so you don't get notifications for all nodes, but I don't actually understand why I would be getting all nodes because I haven't subscribed to them, what am I missing here about pubsub?

Is it just in case some other client subscribed with the bare JID? If you weren't already getting events, does using filtered notifications automatically subscribe you, or do you still have to manually subscribe to each node you want locally?

If you mean +notify, it's for automatic subscriptions.

Cool, that's what I thought. The text of this XEP makes *no* sense in any way that I can figure out then :)

Sam, from the client perspective, whether you are implicitly subscribed to everyone's PEP nodes with notifications filtered locally, or automatically subscribe based on +notify makes little difference. So it could be done either way on the server side.

I don't understand how the word "filtering" fits into any of this, I guess

with PEP, if you share presence with a contact, then you are subscribed to its virtual pubsub service, however your server will filter pubsub notifications from this server based on +notify

Sam, does this help?

flow: I still have no idea what "filter" means there, same problem?

Sam, imagine that your server receives all notifications and filters out those which are not explicitly announced by the client as supported via +notify

Imagine that remote servers send *all* notifications, but your local server filters them based unless you put the matching +notify in your disco

But then imagine that the local server doesn't do this, but the remote server sends, as the filtering isn't negotiated ...

Oooh, the remote server is sending everything, the local server is filtering? Why not just have the remote only send what's needed?

That's how it works in practice

Zash, so a user server is constantly subscribing and unsubscribing from PEP nodes of other users depending on clients that get online (with new +notify) and offline?

flow, remote servers enable and disable subscriptions or filtering based on incoming presence with caps and corresponding +notify changes

ahh, yes, that makes a lot more sense

Tho I don't know, IIRC ejabberd did the thing where everything was broadcast to everyone all the time, while Prosody does what I just said.

(in the past)

so if the user's server doesn't double check, then the user may end up with unsolicited notifications

correct. this was annoying. I believe it's no longer the case, so that's nice

However if you have multiple devices subscribed (with +notify) to the same node, two notifications are sent

And servers needing to keep state for *remote* users is a bit meh.

Okay, still no idea what the difference is in that case then

The difference is that it's Friday! Woooh

I'm not sure what difference, between what, you are referring to.

I read XEP-0163 (Example 5) that it is the publisher’s server that filters (not the subscribers server), and that the publisher’s server forwards notifications to clients that have the corresponding +notify

"Subscriptions or filtering"

Filter makes no sense here in my mind if it's just subscribing; what are we filtering in that case?

I read XEP-0060 (§9.2 Filtered Notifications) to mean the same: It’s the responsibility of the publisher’s server not to forward notifications to clients that do not have the corresponding +notify

but it is not 100% clear

Sam, subscribing here means subscribing to the whole virtual pubsub service of the user and filtering the nodes for which you will receive notifications

so with PEP it's like a subscription to the whole virtual pubsub service, whereas with traditional PubSub, you subscribe to nodes (of a pubsub service)