XSF Discussion - 2020-10-17

I have this error message: > Server-to-server connection failed: Connecting failed: dh key too small When writing one of my contacts. He has his jid on jabber.org

Any know reason?

I can see the online-status of the contact though.

dh key of your server is maybe set wrong

Your server and jabber.org negotiated a cipher with ephemeral diffie-hellman key agreement. The parameters on jabber.org are 1024bit iirc. Your server didn't like it and gave up.

eevvoor, make sure your server is up to date and doesn't have weird tls configuration. normally these days most connections should be negotiating elliptic curve dh

It is not my own server.

Bother your local server admin then :)

the 'proper' way would probably be to increase the dh param size on jabber.org tthough

because 1024 is not a lot

and many servers will have issues with that

Isn't the migration of jabber.org underway?

It is. The MUC component is already on a new server. But no idea whether there is any fixed schedule.

MattJ might know.

yes, devilz gave me the feedback that he disabled the support for the short key.

Does someone know the jabber.org admins?

https://www.jabber.org/notices.html says nothing about planned updated.

Matthew, are you one of the admins? ✏

Ok, I got the info about jabber.org from the jabber.de admin: Jabber.org is migrating to prosody rigth now, so I should just wait and dring tea ...

eevvoor: the migration was slightly delayed because we had to show the ietf that they are using jabber wrong 😉

eevvoor: yes, the migration is happening

Looking at the Github issues I assume stpeter has "We are working on it!" on a shortcut. :D

Damn, I wasn't supposed to say that in public. ✏

Reminds me when I wanted to debug an issue and posted a snippet from my debug log and no one cared about my problem but everyone was abused that according to my logs MattJ is a bot. :D

s/abused/amused/

^^

MattJ, that is a good reason for a delay. 🙄 😂

The MattJ-Bot, oh yeah :D.

The jabber.de Admin is laughing btw. I informed him about the reason for the delay.

So far we have most user data exported and conversion scripts written. There are are some bits of data which are not exported and we're working on ways to access that...

With over a million user accounts we are likely looking at taking the server down for a day while we perform the migration

And of course that will be announced once a date is set

We (well, stpeter) just went through a lot of effort to renew the certificate and it would be good to get the migration done before we need to do that again

So hopefully in the coming weeks

good luck then MattJ and stpeter

Is anyone aware of anything still relying on XEP-0091: Legacy Delayed Delivery ?

I looked at a raw MUC message and wondered if all 5 of the extra id tags were really necessary.

emus: once again excellent job on newsletter and also thanks for posting it on fediverse! :D

moparisthebest: Thank you very much! But I dont know who it did - maybe SouL! So thanks to him!

its not good that the native bookmark xep loses no word about a correctly configured node

it only has an example where some publish options are included, but says nothing about if they are important or not

No reference to XEP-0223 either?

there is a reference, but i dont see how this is helpful

this would be my node config

'pubsub#notify_delete': 'true', 'pubsub#notify_retract': 'true', 'pubsub#persist_items': 'true', 'pubsub#max_items': 'max', 'pubsub#access_model': 'whitelist', 'pubsub#send_last_published_item': 'never',

except send_last_published_item, i consider the other ones mandatory

so the XEP should mention this

and we need to add the max_items=max change to the xep

hm ok, notify_delete is probably not mandatory is a edge case, and applies to all pubsub based xeps

notify_react is not needed if clients add the notify=true attribute to the react

persist and access are mentioned in 0223

send last published item is not mandatory

and max_items also not