▲ 306 ▼ Discord is nuking Nintendo Switch emulator devs and their entire servers (www.theverge.com) submitted 2 years ago by ayla@beehaw.org to c/technology@beehaw.org 140 comments fedilink hide all child comments
[–] tissek@sopuli.xyz 21 points 2 years ago (1 child) Convenient, easy to use, large user base, one point registration for multiple communities, tends to simply just work. But is it the best? Nah. And their increased monetisation drives are annoying. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 10 points 2 years ago (3 children) one point registration for multiple communities, Federation, or at least some form of single sign-on with arbitrary providers (like we used to do with OpenID), is a better way of solving this. permalink fedilink source parent hideshow 6 child comments replies: [–] sonori@beehaw.org 8 points 2 years ago (2 children) Everything here is basically text and maybe images if your lucky. In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. You could probably link account sign in, but any real-time stuff would likely be limited to within that single instance unless you create a whole alternative method of federation that would still only be available between thouse certain supported instances. It’s also a whole lot more expensive to host, unless you go peer to peer in which case good luck, and vulnerable to bad actors massively running up hosting bills even if you can protect against denial of service attacks. It would be nice to see, but there is a reason why Matrix is the closest anyone’s come and it’s still more a proof of concept then an actual platform you could direct family or random strangers to. permalink fedilink source parent hideshow 4 child comments replies: [–] dan@upvote.au 6 points 2 years ago* (last edited 2 years ago) (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. A large number of Discord servers just use text. For video, maybe integrate into something that already exists, like Jitsi? Instead of trying to build one single app that handles everything, maybe it would be nice to have a suite of apps that all work together and can all use the same login. A lot of video conferencing systems are already mostly peer-to-peer, at least for enterprise apps. Skype was originally peer-to-peer too. NAT traversal is usually provided by STUN servers. There's some issues like that (for example it reveals the user's IP addresses) but you could proxy everything through a TURN server to solve that. Peer to peer is the best way to implement end-to-end encrypted communication. Having said that, very large groups can benefit from a client-server model, like what Zoom does. permalink fedilink source parent hideshow 2 child comments replies: [–] dormedas@lemmy.dormedas.com 4 points 2 years ago One of the main reasons why I use Discord nowadays aside from the fact that my gaming community is there is for its extremely low latency video streaming. I tried to use other meet softwares but the latency was 10+ seconds. Not useful when I need immediate feedback. Discord offers the quickest and most reliable way for me to get someone else looking at my stream in real-time. I’ll be looking for alternatives because they’re, of course, not doing anything impossible for others to replicate, they just made it the default. permalink fedilink source parent [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. That falls into the same two fallacies as the ones of complainers against Youtube alternatives: that in order to offer an alternative to a service you have to replicate all of it that you have to provide an alternative to only one service Like, really, you don't need to replace all of Discord, only the parts that matter. The alternative to build not to Discord but to "Discord is being used for documentation" already exists, it's called web forums. Ditto, the alternative to "Discord is being used for communities" also exists, it's called XMPP or IRC or Matrix depending on who you ask. The alternative to "Discord tracks user data" is simply called "you don't do it", etc. Like, we are literally on Lemmy. Just about the first thing that we Get It from the internet is that centralization is bad, be it Products or Services. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 1 point 2 years ago (1 child) Forgive me, but I fail to see how expecting video/voice conferencing software to actually be capable of carrying video/voice could be described as a fallacy. It seems to me like that is kind of a core functionality to any software trying to fulfill that role. IRC has nothing to do with the subject, and while XMPP/Matrix are promising they are still a long way from being able to talk someone without significant tech expertise and who has never seen them before into jumping onto a call in five minutes or so without touching a single setting. That is the fundamental part of Discord, Teams, Skype, or Zoom that matters. Lemmy isn’t exactly voice conferencing software, so I don’t know why you would want to collaborate on software development work with it as a forum. As for documentation, a static site is probably the best place for that, although in this case keeping it off the clearnet was presumably a core consideration. permalink fedilink source parent hideshow 2 child comments replies: [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) See, it's the entire premise that voice conferencing is needed to have a replacement for "Discord is used for documentation". It's not. Almost by definition. If anyone wants videoconferencing there's Jitsi. That's the thing I'm aiming to: you won't ever to get anyone to "replace" Discord if they have to replace all of it. Capitalism doesn't allow for that. We are trying to do better here. Splitting problems into their component and significative parts makes them much easier to solve. The closest use case that in the case of these kinds of communities would even need videoconferencing would be something like "Discord is being used for live tech support for modchipping Switches" and for that case there's also already established alternatives... and it would be wise to not implement for that anyway. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 2 points 2 years ago Except this preticular discussion thread isn’t about Discord used as documentation, but Discord use in general as a videoconferencing tool. I also imagine the project started using Discord for conferencing, and documentation grew up around it because everyone was already there, emulation is very finicky, and it wasn’t out in the open for Nintendo to find indexed by Google. They could have used Jitsi, and the same thing would have happened. A video conferencing program like Discord is hardly the first or best place to put software documentation, but in this case it being hard to find was presumably the point. It also seems odd to insist that Capitalism doesn’t allow Jitsi, Matrix, or XMPP to exist, when they and many other open source projects do. Jitsi is owned by a major cooperation, but Matrix and XMPP arn’t to my knowledge. Rough around the edges and in need of significant work, yes, but not prevented from ever exsisting. Video, voice, and text messaging are together the signifiant part of Discord as you put it, it doesn’t make sense in order to split them apart any further. permalink fedilink source parent [–] tissek@sopuli.xyz 2 points 2 years ago I would bet all the pieces to make a better communication suite than discord are there. They just need to be put together into a package and marketed well. permalink fedilink source parent [–] Zworf@beehaw.org 1 point 2 years ago (1 child) In other words: Matrix. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 2 points 2 years ago (1 child) I've never tried Matrix but I've heard good things about it. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (1 child) It's not as snazzy as Discord but it's fully open-source and federated. So everyone can run their own server (I do, too). If you don't care about running your own you can just sign up at https://app.element.io/ . It's free of course. It basically is for chat what lemmy and mastodon are to social media. It also offers many "bridges" to other protocols, like WhatsApp, Telegram, even Discord. Those are not quite as mature and mostly third-party provided but they generally work well. There's a really great ansible playbook for installing your own. If you would like to have the full bridged experience, beeper is probably best. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Thanks! I'll have to see if there's Docker containers available. Ansible is definitely doable too, but I prefer Docker. I'll stick it on the same server I'm running Lemmy and Mastodon on :) permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago (1 child) Actually the ansible playbook creates a bundle of docker containers so you get the best of both :) permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] dan@upvote.au 10 points 2 years ago (3 children) one point registration for multiple communities, Federation, or at least some form of single sign-on with arbitrary providers (like we used to do with OpenID), is a better way of solving this. permalink fedilink source parent hideshow 6 child comments replies: [–] sonori@beehaw.org 8 points 2 years ago (2 children) Everything here is basically text and maybe images if your lucky. In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. You could probably link account sign in, but any real-time stuff would likely be limited to within that single instance unless you create a whole alternative method of federation that would still only be available between thouse certain supported instances. It’s also a whole lot more expensive to host, unless you go peer to peer in which case good luck, and vulnerable to bad actors massively running up hosting bills even if you can protect against denial of service attacks. It would be nice to see, but there is a reason why Matrix is the closest anyone’s come and it’s still more a proof of concept then an actual platform you could direct family or random strangers to. permalink fedilink source parent hideshow 4 child comments replies: [–] dan@upvote.au 6 points 2 years ago* (last edited 2 years ago) (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. A large number of Discord servers just use text. For video, maybe integrate into something that already exists, like Jitsi? Instead of trying to build one single app that handles everything, maybe it would be nice to have a suite of apps that all work together and can all use the same login. A lot of video conferencing systems are already mostly peer-to-peer, at least for enterprise apps. Skype was originally peer-to-peer too. NAT traversal is usually provided by STUN servers. There's some issues like that (for example it reveals the user's IP addresses) but you could proxy everything through a TURN server to solve that. Peer to peer is the best way to implement end-to-end encrypted communication. Having said that, very large groups can benefit from a client-server model, like what Zoom does. permalink fedilink source parent hideshow 2 child comments replies: [–] dormedas@lemmy.dormedas.com 4 points 2 years ago One of the main reasons why I use Discord nowadays aside from the fact that my gaming community is there is for its extremely low latency video streaming. I tried to use other meet softwares but the latency was 10+ seconds. Not useful when I need immediate feedback. Discord offers the quickest and most reliable way for me to get someone else looking at my stream in real-time. I’ll be looking for alternatives because they’re, of course, not doing anything impossible for others to replicate, they just made it the default. permalink fedilink source parent [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. That falls into the same two fallacies as the ones of complainers against Youtube alternatives: that in order to offer an alternative to a service you have to replicate all of it that you have to provide an alternative to only one service Like, really, you don't need to replace all of Discord, only the parts that matter. The alternative to build not to Discord but to "Discord is being used for documentation" already exists, it's called web forums. Ditto, the alternative to "Discord is being used for communities" also exists, it's called XMPP or IRC or Matrix depending on who you ask. The alternative to "Discord tracks user data" is simply called "you don't do it", etc. Like, we are literally on Lemmy. Just about the first thing that we Get It from the internet is that centralization is bad, be it Products or Services. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 1 point 2 years ago (1 child) Forgive me, but I fail to see how expecting video/voice conferencing software to actually be capable of carrying video/voice could be described as a fallacy. It seems to me like that is kind of a core functionality to any software trying to fulfill that role. IRC has nothing to do with the subject, and while XMPP/Matrix are promising they are still a long way from being able to talk someone without significant tech expertise and who has never seen them before into jumping onto a call in five minutes or so without touching a single setting. That is the fundamental part of Discord, Teams, Skype, or Zoom that matters. Lemmy isn’t exactly voice conferencing software, so I don’t know why you would want to collaborate on software development work with it as a forum. As for documentation, a static site is probably the best place for that, although in this case keeping it off the clearnet was presumably a core consideration. permalink fedilink source parent hideshow 2 child comments replies: [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) See, it's the entire premise that voice conferencing is needed to have a replacement for "Discord is used for documentation". It's not. Almost by definition. If anyone wants videoconferencing there's Jitsi. That's the thing I'm aiming to: you won't ever to get anyone to "replace" Discord if they have to replace all of it. Capitalism doesn't allow for that. We are trying to do better here. Splitting problems into their component and significative parts makes them much easier to solve. The closest use case that in the case of these kinds of communities would even need videoconferencing would be something like "Discord is being used for live tech support for modchipping Switches" and for that case there's also already established alternatives... and it would be wise to not implement for that anyway. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 2 points 2 years ago Except this preticular discussion thread isn’t about Discord used as documentation, but Discord use in general as a videoconferencing tool. I also imagine the project started using Discord for conferencing, and documentation grew up around it because everyone was already there, emulation is very finicky, and it wasn’t out in the open for Nintendo to find indexed by Google. They could have used Jitsi, and the same thing would have happened. A video conferencing program like Discord is hardly the first or best place to put software documentation, but in this case it being hard to find was presumably the point. It also seems odd to insist that Capitalism doesn’t allow Jitsi, Matrix, or XMPP to exist, when they and many other open source projects do. Jitsi is owned by a major cooperation, but Matrix and XMPP arn’t to my knowledge. Rough around the edges and in need of significant work, yes, but not prevented from ever exsisting. Video, voice, and text messaging are together the signifiant part of Discord as you put it, it doesn’t make sense in order to split them apart any further. permalink fedilink source parent [–] tissek@sopuli.xyz 2 points 2 years ago I would bet all the pieces to make a better communication suite than discord are there. They just need to be put together into a package and marketed well. permalink fedilink source parent [–] Zworf@beehaw.org 1 point 2 years ago (1 child) In other words: Matrix. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 2 points 2 years ago (1 child) I've never tried Matrix but I've heard good things about it. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (1 child) It's not as snazzy as Discord but it's fully open-source and federated. So everyone can run their own server (I do, too). If you don't care about running your own you can just sign up at https://app.element.io/ . It's free of course. It basically is for chat what lemmy and mastodon are to social media. It also offers many "bridges" to other protocols, like WhatsApp, Telegram, even Discord. Those are not quite as mature and mostly third-party provided but they generally work well. There's a really great ansible playbook for installing your own. If you would like to have the full bridged experience, beeper is probably best. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Thanks! I'll have to see if there's Docker containers available. Ansible is definitely doable too, but I prefer Docker. I'll stick it on the same server I'm running Lemmy and Mastodon on :) permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago (1 child) Actually the ansible playbook creates a bundle of docker containers so you get the best of both :) permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] sonori@beehaw.org 8 points 2 years ago (2 children) Everything here is basically text and maybe images if your lucky. In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. You could probably link account sign in, but any real-time stuff would likely be limited to within that single instance unless you create a whole alternative method of federation that would still only be available between thouse certain supported instances. It’s also a whole lot more expensive to host, unless you go peer to peer in which case good luck, and vulnerable to bad actors massively running up hosting bills even if you can protect against denial of service attacks. It would be nice to see, but there is a reason why Matrix is the closest anyone’s come and it’s still more a proof of concept then an actual platform you could direct family or random strangers to. permalink fedilink source parent hideshow 4 child comments replies: [–] dan@upvote.au 6 points 2 years ago* (last edited 2 years ago) (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. A large number of Discord servers just use text. For video, maybe integrate into something that already exists, like Jitsi? Instead of trying to build one single app that handles everything, maybe it would be nice to have a suite of apps that all work together and can all use the same login. A lot of video conferencing systems are already mostly peer-to-peer, at least for enterprise apps. Skype was originally peer-to-peer too. NAT traversal is usually provided by STUN servers. There's some issues like that (for example it reveals the user's IP addresses) but you could proxy everything through a TURN server to solve that. Peer to peer is the best way to implement end-to-end encrypted communication. Having said that, very large groups can benefit from a client-server model, like what Zoom does. permalink fedilink source parent hideshow 2 child comments replies: [–] dormedas@lemmy.dormedas.com 4 points 2 years ago One of the main reasons why I use Discord nowadays aside from the fact that my gaming community is there is for its extremely low latency video streaming. I tried to use other meet softwares but the latency was 10+ seconds. Not useful when I need immediate feedback. Discord offers the quickest and most reliable way for me to get someone else looking at my stream in real-time. I’ll be looking for alternatives because they’re, of course, not doing anything impossible for others to replicate, they just made it the default. permalink fedilink source parent [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. That falls into the same two fallacies as the ones of complainers against Youtube alternatives: that in order to offer an alternative to a service you have to replicate all of it that you have to provide an alternative to only one service Like, really, you don't need to replace all of Discord, only the parts that matter. The alternative to build not to Discord but to "Discord is being used for documentation" already exists, it's called web forums. Ditto, the alternative to "Discord is being used for communities" also exists, it's called XMPP or IRC or Matrix depending on who you ask. The alternative to "Discord tracks user data" is simply called "you don't do it", etc. Like, we are literally on Lemmy. Just about the first thing that we Get It from the internet is that centralization is bad, be it Products or Services. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 1 point 2 years ago (1 child) Forgive me, but I fail to see how expecting video/voice conferencing software to actually be capable of carrying video/voice could be described as a fallacy. It seems to me like that is kind of a core functionality to any software trying to fulfill that role. IRC has nothing to do with the subject, and while XMPP/Matrix are promising they are still a long way from being able to talk someone without significant tech expertise and who has never seen them before into jumping onto a call in five minutes or so without touching a single setting. That is the fundamental part of Discord, Teams, Skype, or Zoom that matters. Lemmy isn’t exactly voice conferencing software, so I don’t know why you would want to collaborate on software development work with it as a forum. As for documentation, a static site is probably the best place for that, although in this case keeping it off the clearnet was presumably a core consideration. permalink fedilink source parent hideshow 2 child comments replies: [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) See, it's the entire premise that voice conferencing is needed to have a replacement for "Discord is used for documentation". It's not. Almost by definition. If anyone wants videoconferencing there's Jitsi. That's the thing I'm aiming to: you won't ever to get anyone to "replace" Discord if they have to replace all of it. Capitalism doesn't allow for that. We are trying to do better here. Splitting problems into their component and significative parts makes them much easier to solve. The closest use case that in the case of these kinds of communities would even need videoconferencing would be something like "Discord is being used for live tech support for modchipping Switches" and for that case there's also already established alternatives... and it would be wise to not implement for that anyway. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 2 points 2 years ago Except this preticular discussion thread isn’t about Discord used as documentation, but Discord use in general as a videoconferencing tool. I also imagine the project started using Discord for conferencing, and documentation grew up around it because everyone was already there, emulation is very finicky, and it wasn’t out in the open for Nintendo to find indexed by Google. They could have used Jitsi, and the same thing would have happened. A video conferencing program like Discord is hardly the first or best place to put software documentation, but in this case it being hard to find was presumably the point. It also seems odd to insist that Capitalism doesn’t allow Jitsi, Matrix, or XMPP to exist, when they and many other open source projects do. Jitsi is owned by a major cooperation, but Matrix and XMPP arn’t to my knowledge. Rough around the edges and in need of significant work, yes, but not prevented from ever exsisting. Video, voice, and text messaging are together the signifiant part of Discord as you put it, it doesn’t make sense in order to split them apart any further. permalink fedilink source parent
[–] dan@upvote.au 6 points 2 years ago* (last edited 2 years ago) (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. A large number of Discord servers just use text. For video, maybe integrate into something that already exists, like Jitsi? Instead of trying to build one single app that handles everything, maybe it would be nice to have a suite of apps that all work together and can all use the same login. A lot of video conferencing systems are already mostly peer-to-peer, at least for enterprise apps. Skype was originally peer-to-peer too. NAT traversal is usually provided by STUN servers. There's some issues like that (for example it reveals the user's IP addresses) but you could proxy everything through a TURN server to solve that. Peer to peer is the best way to implement end-to-end encrypted communication. Having said that, very large groups can benefit from a client-server model, like what Zoom does. permalink fedilink source parent hideshow 2 child comments replies: [–] dormedas@lemmy.dormedas.com 4 points 2 years ago One of the main reasons why I use Discord nowadays aside from the fact that my gaming community is there is for its extremely low latency video streaming. I tried to use other meet softwares but the latency was 10+ seconds. Not useful when I need immediate feedback. Discord offers the quickest and most reliable way for me to get someone else looking at my stream in real-time. I’ll be looking for alternatives because they’re, of course, not doing anything impossible for others to replicate, they just made it the default. permalink fedilink source parent
[–] dormedas@lemmy.dormedas.com 4 points 2 years ago One of the main reasons why I use Discord nowadays aside from the fact that my gaming community is there is for its extremely low latency video streaming. I tried to use other meet softwares but the latency was 10+ seconds. Not useful when I need immediate feedback. Discord offers the quickest and most reliable way for me to get someone else looking at my stream in real-time. I’ll be looking for alternatives because they’re, of course, not doing anything impossible for others to replicate, they just made it the default. permalink fedilink source parent
[–] veniasilente@lemm.ee 1 point 2 years ago (1 child) In order to make it into a Discord or Zoom competitor you would need to solve far higher bandwidth things like HD video and low latency audio, and both of thouse are fundamentally very different things for a server to handle as compared to high latency short text messages. That falls into the same two fallacies as the ones of complainers against Youtube alternatives: that in order to offer an alternative to a service you have to replicate all of it that you have to provide an alternative to only one service Like, really, you don't need to replace all of Discord, only the parts that matter. The alternative to build not to Discord but to "Discord is being used for documentation" already exists, it's called web forums. Ditto, the alternative to "Discord is being used for communities" also exists, it's called XMPP or IRC or Matrix depending on who you ask. The alternative to "Discord tracks user data" is simply called "you don't do it", etc. Like, we are literally on Lemmy. Just about the first thing that we Get It from the internet is that centralization is bad, be it Products or Services. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 1 point 2 years ago (1 child) Forgive me, but I fail to see how expecting video/voice conferencing software to actually be capable of carrying video/voice could be described as a fallacy. It seems to me like that is kind of a core functionality to any software trying to fulfill that role. IRC has nothing to do with the subject, and while XMPP/Matrix are promising they are still a long way from being able to talk someone without significant tech expertise and who has never seen them before into jumping onto a call in five minutes or so without touching a single setting. That is the fundamental part of Discord, Teams, Skype, or Zoom that matters. Lemmy isn’t exactly voice conferencing software, so I don’t know why you would want to collaborate on software development work with it as a forum. As for documentation, a static site is probably the best place for that, although in this case keeping it off the clearnet was presumably a core consideration. permalink fedilink source parent hideshow 2 child comments replies: [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) See, it's the entire premise that voice conferencing is needed to have a replacement for "Discord is used for documentation". It's not. Almost by definition. If anyone wants videoconferencing there's Jitsi. That's the thing I'm aiming to: you won't ever to get anyone to "replace" Discord if they have to replace all of it. Capitalism doesn't allow for that. We are trying to do better here. Splitting problems into their component and significative parts makes them much easier to solve. The closest use case that in the case of these kinds of communities would even need videoconferencing would be something like "Discord is being used for live tech support for modchipping Switches" and for that case there's also already established alternatives... and it would be wise to not implement for that anyway. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 2 points 2 years ago Except this preticular discussion thread isn’t about Discord used as documentation, but Discord use in general as a videoconferencing tool. I also imagine the project started using Discord for conferencing, and documentation grew up around it because everyone was already there, emulation is very finicky, and it wasn’t out in the open for Nintendo to find indexed by Google. They could have used Jitsi, and the same thing would have happened. A video conferencing program like Discord is hardly the first or best place to put software documentation, but in this case it being hard to find was presumably the point. It also seems odd to insist that Capitalism doesn’t allow Jitsi, Matrix, or XMPP to exist, when they and many other open source projects do. Jitsi is owned by a major cooperation, but Matrix and XMPP arn’t to my knowledge. Rough around the edges and in need of significant work, yes, but not prevented from ever exsisting. Video, voice, and text messaging are together the signifiant part of Discord as you put it, it doesn’t make sense in order to split them apart any further. permalink fedilink source parent
[–] sonori@beehaw.org 1 point 2 years ago (1 child) Forgive me, but I fail to see how expecting video/voice conferencing software to actually be capable of carrying video/voice could be described as a fallacy. It seems to me like that is kind of a core functionality to any software trying to fulfill that role. IRC has nothing to do with the subject, and while XMPP/Matrix are promising they are still a long way from being able to talk someone without significant tech expertise and who has never seen them before into jumping onto a call in five minutes or so without touching a single setting. That is the fundamental part of Discord, Teams, Skype, or Zoom that matters. Lemmy isn’t exactly voice conferencing software, so I don’t know why you would want to collaborate on software development work with it as a forum. As for documentation, a static site is probably the best place for that, although in this case keeping it off the clearnet was presumably a core consideration. permalink fedilink source parent hideshow 2 child comments replies: [–] veniasilente@lemm.ee 1 point 2 years ago (1 child) See, it's the entire premise that voice conferencing is needed to have a replacement for "Discord is used for documentation". It's not. Almost by definition. If anyone wants videoconferencing there's Jitsi. That's the thing I'm aiming to: you won't ever to get anyone to "replace" Discord if they have to replace all of it. Capitalism doesn't allow for that. We are trying to do better here. Splitting problems into their component and significative parts makes them much easier to solve. The closest use case that in the case of these kinds of communities would even need videoconferencing would be something like "Discord is being used for live tech support for modchipping Switches" and for that case there's also already established alternatives... and it would be wise to not implement for that anyway. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 2 points 2 years ago Except this preticular discussion thread isn’t about Discord used as documentation, but Discord use in general as a videoconferencing tool. I also imagine the project started using Discord for conferencing, and documentation grew up around it because everyone was already there, emulation is very finicky, and it wasn’t out in the open for Nintendo to find indexed by Google. They could have used Jitsi, and the same thing would have happened. A video conferencing program like Discord is hardly the first or best place to put software documentation, but in this case it being hard to find was presumably the point. It also seems odd to insist that Capitalism doesn’t allow Jitsi, Matrix, or XMPP to exist, when they and many other open source projects do. Jitsi is owned by a major cooperation, but Matrix and XMPP arn’t to my knowledge. Rough around the edges and in need of significant work, yes, but not prevented from ever exsisting. Video, voice, and text messaging are together the signifiant part of Discord as you put it, it doesn’t make sense in order to split them apart any further. permalink fedilink source parent
[–] veniasilente@lemm.ee 1 point 2 years ago (1 child) See, it's the entire premise that voice conferencing is needed to have a replacement for "Discord is used for documentation". It's not. Almost by definition. If anyone wants videoconferencing there's Jitsi. That's the thing I'm aiming to: you won't ever to get anyone to "replace" Discord if they have to replace all of it. Capitalism doesn't allow for that. We are trying to do better here. Splitting problems into their component and significative parts makes them much easier to solve. The closest use case that in the case of these kinds of communities would even need videoconferencing would be something like "Discord is being used for live tech support for modchipping Switches" and for that case there's also already established alternatives... and it would be wise to not implement for that anyway. permalink fedilink source parent hideshow 2 child comments replies: [–] sonori@beehaw.org 2 points 2 years ago Except this preticular discussion thread isn’t about Discord used as documentation, but Discord use in general as a videoconferencing tool. I also imagine the project started using Discord for conferencing, and documentation grew up around it because everyone was already there, emulation is very finicky, and it wasn’t out in the open for Nintendo to find indexed by Google. They could have used Jitsi, and the same thing would have happened. A video conferencing program like Discord is hardly the first or best place to put software documentation, but in this case it being hard to find was presumably the point. It also seems odd to insist that Capitalism doesn’t allow Jitsi, Matrix, or XMPP to exist, when they and many other open source projects do. Jitsi is owned by a major cooperation, but Matrix and XMPP arn’t to my knowledge. Rough around the edges and in need of significant work, yes, but not prevented from ever exsisting. Video, voice, and text messaging are together the signifiant part of Discord as you put it, it doesn’t make sense in order to split them apart any further. permalink fedilink source parent
[–] sonori@beehaw.org 2 points 2 years ago Except this preticular discussion thread isn’t about Discord used as documentation, but Discord use in general as a videoconferencing tool. I also imagine the project started using Discord for conferencing, and documentation grew up around it because everyone was already there, emulation is very finicky, and it wasn’t out in the open for Nintendo to find indexed by Google. They could have used Jitsi, and the same thing would have happened. A video conferencing program like Discord is hardly the first or best place to put software documentation, but in this case it being hard to find was presumably the point. It also seems odd to insist that Capitalism doesn’t allow Jitsi, Matrix, or XMPP to exist, when they and many other open source projects do. Jitsi is owned by a major cooperation, but Matrix and XMPP arn’t to my knowledge. Rough around the edges and in need of significant work, yes, but not prevented from ever exsisting. Video, voice, and text messaging are together the signifiant part of Discord as you put it, it doesn’t make sense in order to split them apart any further. permalink fedilink source parent
[–] tissek@sopuli.xyz 2 points 2 years ago I would bet all the pieces to make a better communication suite than discord are there. They just need to be put together into a package and marketed well. permalink fedilink source parent
[–] Zworf@beehaw.org 1 point 2 years ago (1 child) In other words: Matrix. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 2 points 2 years ago (1 child) I've never tried Matrix but I've heard good things about it. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (1 child) It's not as snazzy as Discord but it's fully open-source and federated. So everyone can run their own server (I do, too). If you don't care about running your own you can just sign up at https://app.element.io/ . It's free of course. It basically is for chat what lemmy and mastodon are to social media. It also offers many "bridges" to other protocols, like WhatsApp, Telegram, even Discord. Those are not quite as mature and mostly third-party provided but they generally work well. There's a really great ansible playbook for installing your own. If you would like to have the full bridged experience, beeper is probably best. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Thanks! I'll have to see if there's Docker containers available. Ansible is definitely doable too, but I prefer Docker. I'll stick it on the same server I'm running Lemmy and Mastodon on :) permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago (1 child) Actually the ansible playbook creates a bundle of docker containers so you get the best of both :) permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] dan@upvote.au 2 points 2 years ago (1 child) I've never tried Matrix but I've heard good things about it. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (1 child) It's not as snazzy as Discord but it's fully open-source and federated. So everyone can run their own server (I do, too). If you don't care about running your own you can just sign up at https://app.element.io/ . It's free of course. It basically is for chat what lemmy and mastodon are to social media. It also offers many "bridges" to other protocols, like WhatsApp, Telegram, even Discord. Those are not quite as mature and mostly third-party provided but they generally work well. There's a really great ansible playbook for installing your own. If you would like to have the full bridged experience, beeper is probably best. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Thanks! I'll have to see if there's Docker containers available. Ansible is definitely doable too, but I prefer Docker. I'll stick it on the same server I'm running Lemmy and Mastodon on :) permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago (1 child) Actually the ansible playbook creates a bundle of docker containers so you get the best of both :) permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] Zworf@beehaw.org 1 point 2 years ago* (1 child) It's not as snazzy as Discord but it's fully open-source and federated. So everyone can run their own server (I do, too). If you don't care about running your own you can just sign up at https://app.element.io/ . It's free of course. It basically is for chat what lemmy and mastodon are to social media. It also offers many "bridges" to other protocols, like WhatsApp, Telegram, even Discord. Those are not quite as mature and mostly third-party provided but they generally work well. There's a really great ansible playbook for installing your own. If you would like to have the full bridged experience, beeper is probably best. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Thanks! I'll have to see if there's Docker containers available. Ansible is definitely doable too, but I prefer Docker. I'll stick it on the same server I'm running Lemmy and Mastodon on :) permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago (1 child) Actually the ansible playbook creates a bundle of docker containers so you get the best of both :) permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] dan@upvote.au 1 point 2 years ago (1 child) Thanks! I'll have to see if there's Docker containers available. Ansible is definitely doable too, but I prefer Docker. I'll stick it on the same server I'm running Lemmy and Mastodon on :) permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago (1 child) Actually the ansible playbook creates a bundle of docker containers so you get the best of both :) permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] Zworf@beehaw.org 1 point 2 years ago (1 child) Actually the ansible playbook creates a bundle of docker containers so you get the best of both :) permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] dan@upvote.au 1 point 2 years ago (1 child) Ahh... Interesting! Do you know how much RAM it needs? I have a spare VPS with 9GB RAM - is that sufficient? I could run it in a VM on my home server instead, too. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] Zworf@beehaw.org 2 points 2 years ago* (1 child) Yeah for sure. I run the server + a bunch of bridges (whatsapp, signal, telegram, chatgpt) on an old atom NUC with 8GB RAM and it only actually uses 2 GB. Here's the documentation for the playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy I can really recommend it. It takes some reading to set it up because it's insanely configurable. But in the end I have a config file with like 20 statements in it and that sets it all up and keeps it up to date. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] dan@upvote.au 1 point 2 years ago* (last edited 2 years ago) (1 child) Just tried out that playbook to set up a staging server, and it works pretty well. I feel like it's a bit too magical though. I like knowing how all the software I'm using is installed and configured, and introducing another layer of abstraction makes that harder. I have particular ways things like my web server (Nginx), database servers, Let's Encrypt (certbot), etc are configured and want to keep things that way. I think I'll just use the Ansible playbook for the staging server, and set up the real server using the Docker containers directly, based on documentation from the upstream projects (Synapse, etc) It looks like they have both Docker containers and Debian packages avaliable, so I'll have to see if it's worth using the Debian packages instead. permalink fedilink source parent hideshow 2 child comments replies: [–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] Zworf@beehaw.org 1 point 2 years ago* (last edited 2 years ago) (1 child) That's true. They actually stopped supporting Nginx recently which really bothered me too because I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. So right now I'm locked out from updating until I fix that. And yes it is totally feasible to use upstream! Not a problem at all. I would recommend to use the dockers though, as the whole debian thing becomes a bit of a mess with different python requirements for some of the bridges. I tried that in a long forgotten past and there is a reason I'm trying to forget that 🤭 Like you I know the ansible playbook has its limits (for example one other thing I run into is that I want to run several instances of the same bridge to bridge eg. 2 whatsapp accounts!) but I do think docker is the way to go. I'm interested to hear how you're faring though as it's a long time ago since I tried that. permalink fedilink source parent hideshow 2 child comments replies: [–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent
[–] dan@upvote.au 1 point 2 years ago I want to keep using self-signed certs (my server is only reachable internally and I do not want to expose it to the internet). And the new server they use (I forgot which) didn't really have that option. If you have your own domain name, you can get Let's Encrypt certificates for internal servers by using DNS challenges instead of HTTP challenges. I use subdomains like whatever.int.example.com for my internal systems. Of course, it's possible that the Ansible playbook doesn't support that... Thanks for the note about Python and the Debian packages. That's a good point. I'll definitely use the Docker containers. permalink fedilink source parent