XMPP Service Operators - 2024-05-22

Some websites claim that WireGuard is faster then IPsec, but does that remain true with modern CPUs that have hardware acceleration for AES?

> <nuegia.net> Some websites claim that WireGuard is faster then IPsec, but does that remain true with modern CPUs that have hardware acceleration for AES? That's not a claim it's just a fact

what is?

Irregardless that's not offloaded like IPSec

Wasn't wireguard invented afert every computer already had aes hardware acceleration? In my head aes acceleration is older then wireguard. So yes all test account that already in

(for example: we get over 1Gb/s transits on site to site tunnels with WG while maybe 300Mb/s with IPSec with the same hardware)

> Wasn't wireguard invented afert every computer already had aes hardware acceleration? In my head aes acceleration is older then wireguard. > So yes all test account that already in yes, much older ↺

Maranda, what about wireguard set to ciphers you have a hardware accelerated implementation of. not chacha20/poly1305

but AES256

Wireguard's cipher is optimized for CPUs that don't have AESNI feature

most prosumer grade and up CPUs support this, even mips

octeon MIPS

Just use wireguard and don't worry about anything. It works and doesn't stress cpu.

nuegia.net I don't know about an implementation of WG that let's you set ciphers, also the former ciphers are better in every aspect compared to AES256-CBC/CTR/GCM irregardless

So I'm not sure what are you on about.

you can't change ciphers with wireguard only ipsec

that's a feature

much less complexity

'better' is situational. a hardware implementation of AES can be way faster and just as secure (if not more) as chacha20

if chacha20 is only implemented in software

chacha20 was only ever intended as a software fallback that's 'good enough' while also not melting mobile (smartphone) cpus

nuegia.net to improve throughput with IPSec IKE or IKEv2 the only way has always been setting weaker ciphers, which brought more additional issues than it solved, so since we're almost in 2025 ditching a protocol that is dumb at NAT traversal (even with all the caveats) and that is blocked at every corner in transit, is a good idea and that's all I have to add to the topic.

Modern ARM cpus are more than capable at handling WG even without offloading.

There's no NAT in IPv6 so the mode IPsec is in doesn't really matter. Also AES isn't a weaker cipher and most cpus with hardware implementations can do multi-gigabit sometimes 10+ gigabit with aesni. Also this does matter for embedded cpus which most networking appliances use.

this is not the wireguard discussion room, so please take it elsewhere.

nuegia.net at this rate I think you're arguing over nothing, so do as you wilt. You have been given enough advice already.

not really

worlio.com, what do you mean?

So uh... on the topic of XMPP... Anybody just tired of blocking MUC PMs outright to everyone when it becomes a problem (aka muc_block_pm)? ✏

» [03:14:45] <jonas’> worlio.com, what do you mean? My bad, my edit to make it clearer took too long. ✏

I think for public rooms blocking PMs between non-mods is not the worst thing to do.

Yes but I hate doing that because there are useful cases for MUC PMs between members.

worlio.com, right. I have no good ideas for solutions unfortunately.

I wasn't really conveying I have a problem though because if you're using Prosody, I recently made and pushed a mod called muc_restrict_pm.

I just wanted to let people know that.

It still blocks pm for every (participant), the difference to the other module is, it is per room, isn't it?

muc_restrict_pm is configurable per-room.

You can set what affiliation to require rather than block for all particpants.

ah its an allowlist right? interesting

from the description at least i read

https://xmpp.worlio.com:5281/file_share/MsVXScQLkKMCWOSgTSuou2nY/psishare-jIaxHu.png

It adds these room configuration options.

ah okay

This still allows PMing moderators regardless (for voice requesting). ✏

It uses the affiliation, so you can assign people as members like you would if you wanted to set the room to moderated.

fyi ejabberd has this already. prosody doesnt apparently

I'm not really aware of ejabberd by much, I like Prosody too much.

A per room config is nice to have.

Yeah ejabberd has that by default

It's a really nice feature

For my public room I default all users to Visitors without voice, then they can either use XMPP voice requests or PM a moderator

visitors aren't allowed to PM others

also it looks like my friend Squeaky Latex Folf doesn't have voice in here

See https://xmpp.org/community/channels/operators/#who-is-authbot https://xmpp.org/community/channels/operators/#how-do-I-get-channel-membership about voice. The "don't fret - - not required part" is obsolete at the moment ✏

ah okay ty

The irony of discussing ejabberd having the ability to block PMs and Prosody not, in a channel hosted on Prosody where PMs are in fact blocked... :)

Seems prosody is approaching having it three times (three different modules)

» [13:26:18] <MattJ> The irony of discussing ejabberd having the ability to block PMs and Prosody not, in a channel hosted on Prosody where PMs are in fact blocked... :) Is the server running this MUC not using a module for it?

I think that was the focus. From my understanding, the option is in ejabberd by default.

Well in prosody everything is a module. Even client connections

Blocking PMs in a Prosody-hosted MUC is a community module, so yeah... there is that. On the other hand, yes, everything is a module in Prosody.

Well now it can be blocked per-muc was the point.

I guess that does depend on which module you use. Now that I scroll up a bit, making it more flexible is nice.

It would also be nice if there weren't half a dozen modules doing the same thing slightly differently. I made a slight mod to the block_strangers module to add an exception list, and was invited to create a new module for that, but it seems to me that patching the old one (the list is optional, after all) would be better. Just my opinion...