4 ms·

Head on over to: https://github.com/matrix-org/synapse#synapse-installation https://github.com/matrix-org/synapse#synapse-installation ...Then scroll to the la

by mxuribe 10y ago

Head on over to: https://github.com/matrix-org/synapse#synapse-installation https://github.com/matrix-org/synapse#synapse-installation ...Then scroll to the last paragraph of this section, "...By default, registration of new users is disabled." The little command line method is what i used to manually register the (3) accounts for my family on my private matrix server. If you plan on using it only for yourself, it might be best to keep registration disabled, and only add yourself manually via the command line...and then you would be done. As far as "web server", I think i know what you mean now, and admittedly I have my private matrix home server running behind nginx...but that's only because I've set it up via DigitalOcean, and simply picked one of their pre-set "LEMP" server images. I believe others have installed/run a matrix home server without nginx or apache, etc. Again, since this is all just a test for my family, i literally went into my DigitalOcean account, generated a new droplet (what they call their virtual servers), and picked a "LEMP" pre-set server. From there, i went installing the synapse server. Because nginx was already installed, I did have to forward/proxy stuff from nginx to synapse...I fully expect to kill this test matrix server off. Now having lived this, I would not have picked the LEMP image, instead just use a basic linux server from DigitalOcean and then install synapse (and any associated requirements/dependencies), that way it doesn't have nginx/apache, etc. I have no experience with Pallium, but I suppose because there are several different implementations (python-based, Go-based, etc.) of the matrix homeserver, there could be different nuances for implementation. Side note: The DigitalOcean droplet that I'm using for my private test matrix home server is the $5/month version (w/512MB memory, 20GB storage). Once I create the production matrix homeserver for my family, I was thinking on using the next level up $10/month version (1GB memory, 30GB storage).

chriswarbo 10y ago
> "...By default, registration of new users is disabled." It's good to know that it can be disabled, but I'm mostly concerned with attack surface, minimalism/hackability and not getting caught on an upgrade treadmill. At the moment my personal Web site is static, the Web UI to my git repos is static and read-only, pushing to those repos is done via SSH, I accept patches by email, etc. I'm hesistant to run anything dynamic at all, let alone something more complex than I need (e.g. a Web frontend) with the capability to perform destructive actions which I don't need (even if they're marked 'disabled'). It would be nice to have an Internet-facing server which only deals with untrusted data, accumulates incoming updates to a file (e.g. sqlite), pushes out posts from a queue (e.g. a directory) and serves the necessary public info when requested, maybe using static files for stuff like my profile. I can then read and write those files over SSH, maybe transforming them into some easy to consume format like maildir. Of course, the first rule of security is don't write it yourself, but this is beginning to sound like a nice weekend project :)
chriswarbo 10y ago
> As far as "web server", I think i know what you mean now, and admittedly I have my private matrix home server running behind nginx Sorry, I should have clarified: when talking about "web" stuff, I meant hyperlinked HTML, intended for human consumption. Whilst sending/receiving HTTP is how most of these protocols work, at least parsing/printing JSON data in a standard format only presents quite a small attack surface, and can be set up "once and for all" (maybe tweaked as the standards slowly improve). It's quite another thing to be serving HTML, since it (like everything user-facing) tends towards bloat and churn (everyone has different tastes). That's fine, but it shouldn't require a server upgrade to fiddle with the UI (or complicating the server with dozens of configuration knobs that have nothing to do with its operation). In contrast, config files on disk are a safer way to perform admin jobs than accepting POSTs from the Internet, and using a separate client (dedicated, multi-protocol, bridging to another format, native or Web, etc.) means that the UI bloat and churn doesn't affect the server.

by mxuribe 10y ago

chriswarbo 10y ago

> "...By default, registration of new users is disabled." It's good to know that it can be disabled, but I'm mostly concerned with attack surface, minimalism/hackability and not getting caught on an upgrade treadmill. At the moment my personal Web site is static, the Web UI to my git repos is static and read-only, pushing to those repos is done via SSH, I accept patches by email, etc. I'm hesistant to run anything dynamic at all, let alone something more complex than I need (e.g. a Web frontend) with the capability to perform destructive actions which I don't need (even if they're marked 'disabled'). It would be nice to have an Internet-facing server which only deals with untrusted data, accumulates incoming updates to a file (e.g. sqlite), pushes out posts from a queue (e.g. a directory) and serves the necessary public info when requested, maybe using static files for stuff like my profile. I can then read and write those files over SSH, maybe transforming them into some easy to consume format like maildir. Of course, the first rule of security is don't write it yourself, but this is beginning to sound like a nice weekend project :)

chriswarbo 10y ago

> As far as "web server", I think i know what you mean now, and admittedly I have my private matrix home server running behind nginx Sorry, I should have clarified: when talking about "web" stuff, I meant hyperlinked HTML, intended for human consumption. Whilst sending/receiving HTTP is how most of these protocols work, at least parsing/printing JSON data in a standard format only presents quite a small attack surface, and can be set up "once and for all" (maybe tweaked as the standards slowly improve). It's quite another thing to be serving HTML, since it (like everything user-facing) tends towards bloat and churn (everyone has different tastes). That's fine, but it shouldn't require a server upgrade to fiddle with the UI (or complicating the server with dozens of configuration knobs that have nothing to do with its operation). In contrast, config files on disk are a safer way to perform admin jobs than accepting POSTs from the Internet, and using a separate client (dedicated, multi-protocol, bridging to another format, native or Web, etc.) means that the UI bloat and churn doesn't affect the server.