XMPP Service Operators - 2023-08-03

Is the server “ussr.im” host here? :D

How weird! I tried all Openfire 4.7.5 servers (with no SSL error) I could find and no one can connect to the one “suchat.org” I am using. ✏

For an unknown reason testssl.sh doesn't connect to suchat.org port 5269. 5222 works. Maybe that's the same reason openfire doesn't work.

Still weird. I did not meet such a thing before this.

“suchat.org” uses a whitelist, I guess.

Thank you.

carlos_

Good morning, on suchat.org there is a blacklist. Both servers and resources.

Meaning it depends on the client? Go xmpp-dns can connect, testssl.sh can't

carlos_, Good afternoon. Thank you. :)

I guess this blacklist is automatically updated. Nevermind.

There were no recent changes to the list.

manually

Hmmm... I would need to try more operations. Don't worry about it yet.

From which server do you have problems?

I am going to eliminate the black list, in case I have it outdated,

jabber.wirtschaftstools.de gfaclan.de chat.krownunity.com ussr.im

There is no blacklist anymore, in case you want to try.

those servers were not on the list, it must be another problem.

you can try to see if the problem was from some resource

OK. Thank you.

“suchat.org” can connect with “ussr.im”, but “suchat.org” can not connect with “conference.ussr.im”. >DNS lookup failed: enoname

As for other three Openfire servers, they can not connect with “suchat.org” at all. The feedback information are “unreachable”.

☭Mike Yellow, SRV and A records for conference.ussr.im are non-existent, so nothing can connect to that.

Then I guess I should turn to Tigase, or some Openfire 4.7.4 or 4.8.0Alpha servers.

has nothing to do with the implementation

☭Mike Yellow: jonas’ is trying to tell you that the DNS configuration of ussr.im is incomplete. DNS records need to be added for the 'conference' subdomain.

I know. I gave up. Nevermind. Thank you jonas’, Guus. ✏

☭Mike Yellow: do you want to test Openfire's translation in forms? I'm curious to see if it works.

> ☭Mike Yellow: do you want to test Openfire's translation in forms? I'm curious to see if it works. Yeah. Sure.

Let me quickly deploy it somewhere public, one sec

I've created a temporary domain. Your account on there is mike / a23dswS (I can't PM you in this room, but I don't care much about these credentials as the domain will be deleted forever in a few moments anyway)

I shall be annoyed but not be able to do much about it if someone abuses it in the meantime

domain is i18n.goodbytes.im

I have disabled server-to-server federation to protect the innocent

☭Mike Yellow give it a try! I'm curious to see if the form gets translated in the language of your client. Note that Openfire supports only a limited set of languages, and not all of them are fully translated

Yes. I am trying.

oh, shoot. I'm only remembering now that this build has _very_ experimental networking changes :S

We kind of replaced the entire networking stack in Openfire, which is currently untested, but what is what you're now using.

Gajim got the English form. But Psi+ got this:

https://suchat.org:5443/upload/72100d426ee0a341f79cb126f62c325d03f117fb/ovTMAN5rNm5U11yzwWoKF7zyxOXafFzumhSupUTg/2b9fe5f4-15b3-45f6-a289-35e5768934a2.png

that's weird, as I see you onlin with Gajim right now

I will try Spark IM, it can get Chinese form too.

but like I said, this might not be the best test environment, given all of the other stuff that's in here. Sorry

>> MUC configuration options are defined in MUC specification > Yes and no... it's true that XEP-0045 defines some options, but there is no obligation to use those options, and absolutely the possibility of adding others that's true, but most of the time room options are mostly following what's in spec. but yes, there is room for extensibility there :-)

https://suchat.org:5443/upload/72100d426ee0a341f79cb126f62c325d03f117fb/PpPgFmNbDv4TOzGTDbw3Psgq1fZVHY0JgG32qVpB/6436f9ce-9686-48b0-a540-1f51fec4c946.png

Still English, except the one string.

Hmm, perhaps the Chinese translation is simply missing for that form.

(it'll default to the setup language of the server, which is English)

What other languages does the form have?

Hmm, the chinese translations should be there, for at least a couple of those headers

No Chinese(Simplified or Traditional), no Russian, I will try others.

pt_BR, cs_CZ, de, es, fr, ja_JP, nl, pl_PL, ru_RU, sk, uk_UA, zh_CN

but using those exact locale definitions

Not working, only English.

I sadly cannot see how the client identifies the language of your session. I'll build something like that, which will make it easier to debug.

That will be another time though.

Should I change the natural language setting in the form first?

Thanks for testing! Sorry that it didn't work.

No, that should not matter.

Oh, OK.

The server should return the form in the language that your client reports when connecting.

You can check what translations are available on https://explore.transifex.com/igniterealtime/openfire/

I'll shut down the server. Let's try again after I've fixed things!

I thought most clients will just report they are English anyway

I do not know what clients do. For some forms, I expect them to report whatever the server sends as text in the form.

(as clients can not always correctly predict the options that will be on the form)

It's not about the form, but about how the server knows what language to send

> I thought most clients will just report they are English anyway That's also my experience.

……

> It's not about the form, but about how the server knows what language to send Agreed. Openfire tries to look at the language that's sent in the open stream element.