We also updated our Photon frontend to the latest 2.0-rc5 just now. Please test and report any issues.

I discussed this on the Lemmy issue tracker and the Lemmy devs are not willing to put some standartized restrictions on password composition to ease such interoperability. Thus the only advise I can give is to change your password to not use any obscure non-ascii characters and keep the length below 60 (30?) characters.

This is or at least was a problem with cross-posts in the same community in Lemmy as well. I think now Lemmy just prevents posts with the same URL to be counted as crossposts when they are in the same community.

Update to Lemmy 0.19.10 was completed. Looks like it went fine. This update will allow us to remove that “Nicole” DM spam a bit better.

In other news: looks like those AI scrapers found a way around out attempts to block them again and this this afternoon we are at near constant 100% CPU utilization again because of this 😢 Lets see what we can do about this. Edit: got slightly better, only 60-80% now. Lets see in the coming days how it develops.

The server can swap to a modified JS that exfiltrates the e2ee key and thus allows the server owner to decrypt the messages, or in more advanced encryption schemes add additional keys without you knowing and achieve the same thing.

Yes you can juryrig something like that with cookies, but it is highly fragile and browser based e2ee is basically a scam anyways as the server serving the website can always swap out the javascript that decrypts the messages.

e2ee is not really compatible with what you want due to necessary key management, and once you drop that there are so many possible options for what you want that I don’t want to list them all here.

/me notes the commenter’s home instance and concludes there is no point in arguing about this very biased take…

Movim does, for Libervia and Dino I am not 100% sure right now, but at least for Libervia the browser version should have it as it is really more of a general Webrtc browser feature than client specific.

Maybe it was based on the “lifetime” of their hamster 🤷

https://join-lemmy.org/docs/administration/configuration.html

You need to set it to proxy all images.

The currently common older implementation of e2ee in xmpp has the same issue with only the message body being encrypted. There are newer specs of OMEMO that have better metadata protection, but its adoption in xmpp clients has been very slow.

Prosody is more of a sandbox, with Snikket being a preconfigured version of it, but yes running Slidge will be a bit easier with a normal Prosody server.

Then you have not enabled to full image proxy (and note that it does not work retroactively). Here on our instance all the Nicole images were proxied correctly to protect the privacy of our members.

Today xmpp uses a distant relative of those original jingle specifications, which have been modernized to use Webrtc.

Lemmy does have a functional image proxy, but due to the storage and bandwidth requirements many larger instances have chosen to not enable it.

Xmpp is mostly used for private groups and 1:1 chat, so more of a WhatsApp than a Discord replacement.

But you can find some public channels here: https://search.jabber.network/

The issues you mentioned have been fixed, and XML was never an issue 😅

Jitsi-meet is already using xmpp under the hood.

But there are some efforts to add multi-user video calls to full xmpp clients as well. Dino can already do it for a while, and Movim and Libervia recently added experimental support.

Its not quite a full Discord replacement, but for private groups it works quite well.

Why would you down-grade from Snikket to Matrix?

If you want to skill up a bit add a Slidge.im gateway to your Snikket xmpp server to access Matrix (and Discord etc.) from there.

Jitsi-meet does that. Easy to install as well.

This would be something to suggest on the upstream Lemmy issue tracker, but I am relatively sure they are already aware but for some reason did not find the time to implement this (or found it unimportant). I somewhat suspect though that this is not so easy to implement as DMs are AFAIK internally not much different from regular posts, and it is generally not possible for regular users to delete posts or comments by other users.

IMHO it would be probably best to add an user profile option to block DMs in general and that at least should be easy to implement.

However, if you receive repeated unwanted DMs from a specific account you can block that user and that will also prevent future DMs from reaching you.