XSF Discussion - 2022-05-19

I have a big roster (800 items) and ~50 of them are old contact that are not reachable anymore. I see that my XMPP server return me errors from their presences.

Do we have a mechanism to handle those contacts and "cleanup" the rosters ?

It also happens with transport services when they are disconnected

edhelas, no, but it's been on my to-do list for many years :)

It also causes a lot of unnecessary work for the server

Even in the old days, jabber.org logs used to be full of s2s connection attempts to servers that had gone down, or were never available in the first place (typos, confused users, etc.)

I don't know if automatic deletion is sensible, but removing subscriptions and possibly moving to an 'Archived' group or something, were ideas that I had

If I have a component connection and I send a <message xmlns="jabber:client" to="someone@componentdomain>, does it get delivered to the component as is, or does the message get translated into the jabber:component:accept namespace? I'm having a hard time understanding the spec; it seems to redefine stanzas in the XML schema, but doesn't mention them in the document

I used to deploy a mod_unsubscriber as a component named after servers that were gone, which would respond with unsubscribe{,d}

(if I send the message on a normal client connection, that is, but the component receives it, not if I send a message from a component connection)

> Even in the old days, jabber.org logs used to be full of s2s connection attempts to servers that had gone down, or were never available in the first place (typos, confused users, etc.) jabber.org was even trying to catch some such things early and prevent trying to establish S2S to things that were clearly typos, to reduce the load.

Sam, it gets translated ✏

For example, the schemas for jabber:server and jabber:component:accept both require 'to' and 'from' attributes, while jabber:client is more relaxed

Another one for your "XML mindset" tally, I think this namespace duplication is one thing most of us would love to change

I also have a mod_unsubscribe, but not all s2s errors are permanent errors so I guess one would need to be smart about it

(That is, a server may be down for hours only)

Thanks for the confirmation

Something for XMPP 2.0 🙂

The 'from/to being optional' thing is one of very very few arguments in favour of the client/server split, and I don't feel it's an adequate argument.

Indeed

But schemas are not normative! Surely we can have some text saying as much while having the same namespace ?

Exactly

The schemas can be normative *and* we can have some text saying that the optional from/to must be present in some cases.

For XMPP 2.0 we should just define a new namespace for all stream types

and then the servers can translate to that from legacy streams

I...am not opposed to that.

Although in practice it means that for a long time servers then need to support four namespaces instead of three!

with the stcok markets falling down, a 33% increase in namespaces doesn't look that bad ✏

with the stock markets falling down, a 33% increase in namespaces doesn't look that bad ✏

In case there will be a Board Meeting any time soon, I'd like to get going an analysis of the EU's new Digital Markets Act and Digital Services Act, and what they mean for XMPP service operators

flow: I'm buying XML futures right now!

Time to short on JSON?

NFT of base64 XML avatars is the new cool thing

shush

Le sigh. I feel that the world is going quite backwards with regards to the 'federate all things' sentiment. I now have people refusing to send me an email, as my mail address is not on their domain. And no, this isn't sensitive information, this is because "that's how we do it."

Meanwhile, the high priority project has been delayed a week, because I can't get anyone to tell me where I can use the credentials that I've been provided. I literally have a username and password, but I can't get anyone to tell me what the URL is where these can be used.

</venting>

That's..... Sad

Guus: did you try contacting them on signal?

I agree, ridiculous things everywhere

I had the baffling experience of a user refusing to install Conversations for, apparently, security/privacy/robustness reasons, on a phone riddled with stock chinese firmware, google, *and* country-local shovelware

Jm2c

Do we know which clients actually implement Hats ?

I have lots of difficulties to find documentations and references

Converse.js I think?

I'm using the one on the official website, I don't see any menu/links to configure it

Also currently trying to reverse-engineer the behavior using mod_muc sourcecode

https://github.com/processone/ejabberd/blob/a916d94000df1bf748421a5e8b7d7df0b69f362d/src/mod_muc_room.erl#L83

I'd expect Hats to be defined from the server

Would be useful to have a proper XEP :D

So, like, clients would just show something somehow

I think that the list is open to the admin, but i'm not sure

Part of the idea is to represent roles from external systems, which would also be responsible for assigning those roles.

Well then I think that for now I'll stop here :p