cross-posted from: https://lemmy.dbzer0.com/post/28930199
A bit of an effortpost :)
Please do crosspost in more fitting communities if you think of any
cross-posted from: https://lemmy.dbzer0.com/post/28930199
A bit of an effortpost :)
Please do crosspost in more fitting communities if you think of any
But neither have seamless voice chat/screen sharing, which is a staple of Discord that users are very used to.
I do not know what you talk about. I use screen sharing and voice chat daily on elements with our own hosted matrix server.
Edit: i felt wrong saying “voice chat” what even is that. I make regular calls and video calls with screen sharing in elements ;)
That is interesting, the last time i tried Element/matrix it did not have these features. Can I ask, is your screen sharing of a quality that you can stream videos and games at equivilant frame rates?
I have never tried that. We use it to share powerpoints in meetings or do troubleshooting together. Or I use it to do family video calls with the kids. Fps are never an issue. There are times where there are compression artifacts tho. Especially if someone have a bad or variable connection. On a buss or a train or similar.
What do you need screen sharing for? This comes up so, so rarely for me.
Besides the expensive Matrix option the parent suggested, IRC covers text fine. Mumble handles low-latency, low-resource voice chat with positional audio for games. XMPP uses more resources that IRC (but can have encryption) but a ton less resources than Matrix which makes it suitable for self-hosting—my partner & I do voice/video calls over my home server fine & Movim is working on group calls with a Web UI (tho it should be noted both Zoom & Jitsi use XMPP under the hood).
it’s convenient, also it’d be nice if it had the feature capability.
Mumble is great, but if there was something like mumble, that implemented video sharing, that would be miles better, though a lot of people would probably still use mumble, as it’s fine.
From what i’ve dug into, basically every video sharing capable setup is based on web technology, and i simply refuse to go near web technology unless i WANT to use a web browser. It’s just, worse, in so many ways.
Well Discord, Slack, & others are web tech too so it’s not like avoiding it is easy. If I have to use these services, I would prefer it be in the browser’s sandbox.
Even still, almost all debug, troubleshoot, pairing session I have done in the last 4 years have been done over Upterm or Tmate, which is much, much lighter on bandwidth & not crushed by video compression.
yeah, and discord slack and basically everything based on electron is a fresh hell.
I love having three separate instances of chrome running the background while just using my computer, such that they all consume an entire gigabyte of ram for no particular reason.
TBF i wouldn’t do much if any troubleshooting over RDP or anything similar, i use SSH for all that stuff lol. I’m just confused that nobody has put together a “relatively” functional version of this yet, it seems like it would be prime realestate.
That is why upterm & tmate exist… ephemeral shared SSH sessions. Biggest missing feature would be some sort of scoping since someone could raw dog your system—catting SSH keys, deleting config, force pushing a repo if unlocked keys are in memory.
if i wanted to share my terminal it’s pretty trivial to do that. Unfortunately i use my computer outside of the terminal environment semi regularly, for most applications really.
The folks I collaborate have a policy now that if it doesn’t have a TUI or CLI version, it doesn’t exist 😂
based, i like those people. Unfortunately i can’t exactly share a minecraft window over terminal, so…
In what way are matrix expencive? You do not have to self host it. You can just make an account on any public matrix server.
Matrix servers chew up an order of magnitude more CPU/RAM which limits the places you can deploy it. The eventual consistency model makes storage balloon as every message, attachment, metadata must be copied to all nodes in a conversation which is resilient, but wasteful in duplicated content in practices which has historically caused many medium & larger servers to shut down due to the explosive just of storage (similar issues with Mastodon). That same model is why it takes on the order of minutes to just join a room or come back to a client that hasn’t been opened recently. Element X & new servers have to work so damn hard to work around asynchronously than fundamental decision to attempt to hide it from the sluggish UX but behind the scenes still too expensive. & since it is expensive to run in many vectors this causes folks to then move to the biggest servers that can handle the load which means the Matrix network is in actuality a small number of massive servers (most of which managed by Matrix.org) & a small number of tiny hobbyists running nodes of <10 users is practice. With so many users on Matrix.org-controlled instances (& again with eventual consistency), almost all data gets synced to their nodes make subpoenas a breeze.
A healthier network would have many fewer massive centralized nodes, medium-sized nodes, & the resource requirements would be low enough that more folks would be encouraged more often to run their own nodes they control so they aren’t required to trust an unknown serves operator. Meaning “just making an account on any public server” isn’t a great mode of operation for privacy—especially as with Matrix joining a medium-sized server will put them under a lot of strain causing them to throw in the tower & joining the few massive servers further exacerbating the centralization issue.
Copying the UX of Slack/Telegram/Discord in a decentralized manner is a fool’s errand. Keeping the chat history for eternity is already a questionable call over using forums, but trying to distribute that out like a blockchain is so wasteful.
https://lukesmith.xyz/articles/matrix-vs-xmpp/ https://www.freie-messenger.de/en/systemvergleich/xmpp-matrix/ https://www.process-one.net/blog/matrix-and-xmpp-thoughts-on-improving-messaging-protocols-part-1/