Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Unable to decrypt message. Please try again.
While I appreciate the joke, I have not seen that problem in quite some time :D
I've last seen it last month. And I have an old chat, where FluffyChat and ("old") Element show all messages by now, but Element X can't decrypt many and both Elements report that they can't guarantee the authenticity of many messages (even my own). For a long time, my chat partner could only read messages I sent via FluffyChat but not those sent by Element. I have not checked if that is still the case.
definetly report the problem. there's a function for it in the app, 3 points menu on the chat list menu, use it after making those errors show up. tick the contact me box. ceo recommends to also notify himself directly: https://gist.github.com/ara4n/190ad712965d0f06e17f508d1a45b554
"can't guarantee the authenticity of this message" just means it was restored from backup. In the same vein, if you can decrypt a message in any client, it should upload the keys to the message backup so it can be decrypted on other clients, even ones that haven't logged in.
Some months ago, I had UTD issues with Element X too. My hs has been up for some years, and the devs claimed they had done a lot to fix UTDs.
I was about to bring the server down, but as a last resort decided to log out all but one Element web session which was able to decrypt the messages and try resetting the key backup. Haven't had any UTD issues since then.
Maybe worth a try.
This is quite annoying. When will devs learn to tell people to resolve the problem instead of just showing a pointless error messages?
afaik those errors can't really be solved by users. I mean other than using an up to date client and server.
If users cannot do anything because all encryption keys are lost, then they need to know that and also how to avoid the situation in the future.
I think it's not a bug. It's simply no one online who can share a decryption key.
its often a bug, because the clients who have the keys don't know they should retry sending.
but also it's all been fixed a year ago as I know. I don't usually use dm rooms and public ones are not encrypted, so I wouldn't know if I didn't read about it.
Matrix encryption keys don't need other people online - they get queued up as messages for each device you have.
https://matrix.org/docs/matrix-concepts/end-to-end-encryption/
Key sharing When an event cannot be decrypted due to missing keys, a client may want to request them from other clients which may have them.
That page seemed outdated, but: From further down that page:
The recommended strategy is to share the keys automatically only to verified devices of the same user
This is the same situation where the key backup is accessible - which is not described on that page, but it's a key store of all the megolm keys. This is what is now generally used instead of that as it doesn't require devices to be online and allows recovering keys if all devices are lost.
I've only seen this message in the last months where different servers are having network issues and can't talk
Ha!
- DNS adjustments aren't needed if you do .well-known delegations which is easier
- Can recommend continuwuity, it runs much better on less resources. Lacks certain features compared to Synapse but overall good
- Notifications (and read markers) depend on client-specific black magic to work
- Federation do sometimes silent-fail completely, you can reset continuwuity's cache + restart when that happens. But full room history convergence needs patience
- Don't join large rooms unless your server can handle the load
- Don't host public rooms without modbots
The many small bugs make Matrix still bad - I wouldn't recommend a non-tech user unless accompanied by a 24/7 admin. It is trying to improve but very slow because of reasons
Matrix works perfectly for me, if you're setting up a new server, I'd go with tuwunel. I'm stuck on synapse, when the tuwunel team makes a way to migrate, I'll do it.
matthew the ceo addressed aot of the criticisms recently, check it out: https://www.youtube.com/watch?v=OyuqM7RbX5E
transcript with links: https://gist.github.com/ara4n/190ad712965d0f06e17f508d1a45b554
other than that, push notifications work fine for me with Ntfy. but as I heard matrix.org hs users have problems, possibly because of serverside firewall issues, investigation is stuck somehow
Matrix seems to work well. I'm on a smallish non-profit server. I regard it as the premium open-source step forward from IRC.
The worst problem is that there are really no channels that I care to follow.
You might want to check out https://matrixrooms.info/, which is good for a search around. Some project communities also have offtopic rooms that are good to chat in. Even very small rooms can be very active.
I host my tuwunnel server and I am happy with it. The lack of a top level client is my turn down. Element X is good but still lacking, and fluffy chat is maybe better looking but more lacking.
My matrix use case is only WhatsApp and telegram backup using the bridges, actually... So YMMV.
My experience as well, though you might take a look at the recent fluffy chat 2.0 release. It is the closest to a usable client.
But I agree and it's baffling to me how a project backed by so many organisations and a considerable amount of cash fails to deliver even a decent user experience.
I believe the machines are currently struggling against the humans
I use conduit. And really happy with it. Since I use 3 bridges the compose.yml is a mess. It works really nice. The sliding feature boosts all media files. But there is always something broken or misconfigured. Actually my WhatsApp bridge blocks all mediafiles and I was too busy to fix it already.
Conduit is long dead. Upgrade to tuwunnel, its successor, while its still binary compatible...
All bridges works fine here.
Continuwuity developer here - Conduit is reviving itself, and you can no longer move from Conduit to tuwunel or Continuwuity. You haven't been able to for as long as either project has existed. You might be confusing conduwuit with Conduit.
Conduwuit has another child? What the difference between continuwuity and tuwunnel?
https://continuwuity.org/ or https://forgejo.ellis.link/continuwuation/continuwuity
As for the difference: https://lemmy.world/post/33271240
Thanks.
I am currently on tuwunnel, might consider a continuwuity migration in the short term future maybe.
Ibwant to stay clear of any drama but stay on a future proof solution if possible.
Hard choices.
Synapse was too heavy on my resources. Moved to XMPP despite I like Matrix more.
Damn. That sucks. (Edit: Referring to the comments saying Matrix is dead and dying.)
I get that IRC and XMPP are more stable and built around federation from the ground up, but... they're not Discord replacements.
That was IMHO, the point of Matrix/Element.
Tell me if I'm wrong, but a significant part of a network's resilience is the number of nodes and users.
Without a glowup or some kind of repackaging, IRC/XMPP are doomed to stay niche.
damn, was not expecting to see so much hate towards matrix.
it sure was annoying to set up, but once I got it up the way I wanted, it kind of just worked from that moment on. I’ve had it for some 5 months now and it works as intended with no issues, aside from some small glitches here and there which get fixed very fast (on the mobile app).
my use case was getting off Discord with a bunch of friends, so we needed a reliable way to have multiple chats, channels/rooms and good voice chat with screen sharing. element call does those well. my federation is of course also closed. for me e2ee is just a bonus
I think that if that’s your use case, it’s good for that. synapse does seem a bit inefficient but I guess you can’t do much about it
My experience is the same as yours, but I think the people complaining are the ones who are federated and are in large communities. Matrix apparently doesnt handle large rooms very well.
fair enough, that’s true. it was one of the reasons I turned off federation, even on a beefy server synapse still lagged and timed out when I would join medium sized rooms.
It's still bad, and the foundation keeps digging itself into a deeper and deeper hole. Dead project.
Absolutely unbased take. Please ignore.
Matrix works fine, I have hosted a server on my own for several years through an ansible playbook here.
IRC and XMPP are infinitely less painful, honestly, and both were designed around federation from the ground up, long before it was cool.
IRC does not have any federation, and XMPP does it in a completely different way from Matrix that has unique pros and cons.
IRC is designed for you to connect to a specific server, with an account on that server, to talk to other people on that server. There is no federation, you cannot talk to oftc from libera.chat. Alongside that, with mobile devices being so common, you'd need to get people to host their own bouncer, or host one for nearly everyone on your network.
XMPP federation conceptually has one major difference compared to Matrix: XMPP rooms are owned by the server that created them, whereas Matrix rooms are equally "owned" by everyone participating in it, with the only deciding factor being which users have administrator permissions.
This makes for better (and easier) scaling on XMPP, so rooms with 50k people isn't that big of an issue for any users in that room. However, if the server owning the room goes down, the whole room is down, and nobody can chat. See Google Talk dropping XMPP federation after making a mess of most client and server implementations.
On Matrix, scaling is a much bigger issue, as everyone connects with everyone else. Your single-person homeserver has to talk with every other homeserver you interact with. If you join a lot of big rooms, this adds up, and takes a lot of resources. However, when a homeserver goes down, only the people on that homeserver are affected, not the rooms. Just recently, matrix.org had some trouble with their database going down. Although it was a bit quieter than usual, I only properly noticed when it was explicitly mentioned in chat by someone else. My service was not interrupted, as I host my own homeserver.
The Matrix method of federation definitely comes with some issues, some conceptually, and some from the implementation. However, a single entity cannot take down the federated Matrix network, even when taking down the most used homeservers. XMPP is effectively killed off by doing the same.
You're absolutely incorrect about IRC. Would you like to learn? Open IRC federation is basically never used anymore and the few networks that exist are very stable (if not completely calcified), but it is a core feature of the design, and in the old days, massive interconnected networks of IRC servers like EFnet and Undernet spanned the globe, there were even some servers that allowed open federation (EFnet is actually named for it -- eris-free-net referring to the last server "eris" that supported free federation), and at some points Netsplits were a frustratingly daily occurrence. Like with any federation, abuse is the reason we can't really have nice things anymore, but IRC absolutely supports federation. Not very well from a modern standpoint since it didn't really keep up with the abuse arms race, but when it was first conceived it was way ahead of its time.
"Open IRC federation is basically never used anymore"
so you admit IRC isn't federated, lmfao
Matrix works good. Two years ago Element should've been what element Next is today. But it is getting there. It still has great backers and lots of users. As long as there is no direct alternative, it'll get there.
I don't want american companies owning all my data and neither do companies want that.
It's not the shiny new kid anymore but there is no other new shiny kid. Hence, it is still the brightest and newest kid.
I set it up during the outage last week.
Easy enough to just pull in the synapse docker container and run it on my home server. I wireguard it to my VPS that acts as a reverse proxy.
Both federation and push notifications work.