XSF Discussion - 2023-06-18

Hi everyone, small topic regarding PEP and Pubsub node configurations.

It seems that Movim didn't configured properly some PEP nodes while publishing things, linked with that ejabberd bug https://github.com/processone/ejabberd/issues/3044

One of the way that I'm pushing to prevent that is to ensure server side that some of the PEP nodes have a fixed configuration, see https://github.com/movim/movim/wiki/Configure%20ejabberd#enforce-pubsub-configuration

I have the feeling that trusting XMPP clients to configure each time correctly the nodes when publishing is kind of an illusion, you can have bugs, you can have "bad clients" etc...

Wouldn't be wise to push those kind of "fixed server configuration", at least for all the config options that are defined as MUST in the XEPs ?

Fix clients and you won't have these issues ✏

Enforcing stuff at the deployment level will just contribute to hiding issues like this

pep., as much as I like fixing clients, I deem enforcing this on the deployment level as a necessary defense-in-depth.

publishing user bookmarks, for instance, because of a typo is Not Great.

we've considered and rejected this in prosody before

and if servers protect against that (either by overriding defaults of the bookmark node _or_ by rejecting attempts to publish with access_model open), I very much welcome that ✏

jonas’: does that prevent fixing clients though

I don't think it does :)

> Enforcing stuff at the deployment level will just contribute to hiding issues like this I'm fine rejecting the configuration with an "error" if it doesn't fit, at least the client knows, and it's perfectly "pubsub compatible". ↺

Good and working clients will be OK, "bad clients" will have an error and can then know directly what to fix.

The server can't protect against typos, e.g. in the node name

XEPs MUST options are respected, and server admins will not be afraid to have "bad clients" misconfiguring nodes for some of their users.

Everyone is happy and we can then fix our clients to make them fully compliants.

You never know which weird client your users will use in the end.

MattJ, arguably, node name typos are more easily discovered than access model typos

you notice the former right away when doing interop testing with other clients

the latter you only notice when someone finds bookmark notifications in their XML logs.

It feels like it's shifting the responsibility to the server to protect an arbitrary and unbounded list of node names that are supposed to be opaque

More sensible IMHO would be to e.g. default all PEP nodes to private by default, and require explicit configuration to make them open

That might (almost certainly would) break a bunch of existing clients

But I'd feel more comfortable with an arbitrary list of nodes we know should be open by default

And update all those XEPs to require the client to include publish-options in the future

Can be a solution yes

Knowing that its a bit more than the access_model and publish_model

But also the max_items and the item persistence

Clients should configure it

If they don't, they are already broken

Hacky workarounds on the server are not the solution, especially if privacy/security is not at stake

And hardcoded lists in the server will get outdated since it's clients that know what nodes they use.

ejabberd intentionally broke OMEMO for years by overriding PEP configuration

I don't want to get into the game of intentionally or accidentally enforcing configuration that is supposed to be controlled by clients

When the client publishes stuff, it knows what it is publishing and what the intended configuration for that data is

The server does not know, and matching on node name is a hack

If a XEP namespace gets bumped or whatever, everything breaks until all the servers update

That's also why the PEP nodes have versions bookmarks:1

It's very different to just "private by default" which is a sensible policy

If you change the default node config, you bump the version

or a new cool XEP is published, clients rush to implement and deploy, but since everyone is running the most ancient Ubuntu they don't get the new list for 5 years ✏

Maybe we should just make publish-options mandatory

At least for initial publishes

Maybe we should

and access model a required option that can't be left out

For backwards compatibility I can then see us having a list of default configurations for existing widespread PEP node names

But with the intention of deprecating that eventually

> /me like private by default. I like it as well ↺

I'll try and draft some XEP PRs this week

why does it need a XEP? Its simply a server config to define a default node configuration or not?

No, because 163 requires "presence" as the default.

The core proposal would be to 1) have every XEP that uses PEP declare the recommended node configuration, and 2) make publish-options mandatory (at least a SHOULD) everywhere we reasonably can (that means at least all new PEP-based XEPs)

And I would add text about this to the existing informational XEPs, at least

I don't really understand publish-options, as it seems to enforce a weird flow on the client, but it's where we are, so that seems sensible enough.

what do you find weird about ? i tell the server what i want, it tells me this does not reflect whats actually is there, and then i go into a node config flow

I agree it's an awkward flow (in the failure case), but it's a very common pattern (check-and-set) in distributed systems

lovetox: one awkward thing is that if you simply do that, two clients can fight over the configuration in a loop

It opens you up to all sorts of fun race conditions that there's just no reason for.

xyrrset !

I've not seen that happen so far, but I consider that mostly luck

<Client> Please publish with these options <Server> But those aren't the options I've got set <Client> ... <Client> Please set these options <Server> Certainly, Ma'am. <Client> Please publish with these options <Server> Okeydokey, no problem

Compare with <Client> Please publish with these options <Server> Ok, I'll set those options and then publish

Okay, so you think it should overwrite the configuration instead of failing

But then you get no indication that two clients are flipping settings back and forth

Like the disagreement on whether OMEMO stuff should be public or presence

> Okay, so you think it should overwrite the configuration instead of failing I have no problem with publish-options having a flag saying "fail" or "change", if people have a need for failing instead, but I suspect that the standard client behaviour is to just blindly do the change as in my tongue-in-cheek exchange above, and in that case the server may as well have done it.

> But then you get no indication that two clients are flipping settings back and forth You don't anyway, because the clients are (most likely) going to just silently reconfigure the node and you'll have the same flap, but with more stanzas.

yeah sure a overwrite flag is nice, but does not spare a client to implement the failure flow

so you have an indication; in your data usage.

so not really a gain

Wait none of this protects against a bad client that sets bad settings

> lovetox: one awkward thing is that if you simply do that, two clients can fight over the configuration in a loop

thats a spec issue

what would be a solution to that issue?

and probably a client developer experience issue

I fail to come up with good ideas

writing a good spec?

if you say, hey max items in a node is undefined i leave this to whatever developers need

yeah bad spec will lead to config fights

should never get published into a spec ..

lovetox, nevermind max items. how would a better flow look like for things like access_model on bookmark nodes?

thats why for bookmarks we invented "max" setting :)

jonas’, i never said the current flow is bad, so i dont have solutions for things where i see no problem

you may ask the ones that think its bad

So we've moved away from "we should fix faulty clients" :p

im not sure what the problem is, you found one more thing a client devleoper has to care about or otherwise privacy of the user is at risk

is it possible with pubsub to discover open nodes on a contact?

Yes

funny info i just received, about security labels, seems there are at least 2 government agencies who use Gajim and depend on the security labels support

remove immediately and offer paid support!

but .. then its like a job ... beside my other job

it wasn't already? :)

until now its a relaxing freetime hobby

right... also, hard to make a living only offering support for a minor XEP

Feel free to remove it and send them to Isode ;p