date: Wed Feb 18 10:09:15 2026 UTC Use impersonal tone commit - d0e8cbceae1c4ebef5a7cfc46acbf0e4137f7e8e commit + df7a70ed077a86e2e21083368fd051dd02f46aed blob - 82361647db6cc996e63316fcd5da5cfd8965ecdd blob + 7b700fdb9efb0492a8d24089c3c4935d2224e2bc --- index.html +++ index.html @@ -44,21 +44,22 @@

This configuration serves website content from the www repository - and allows you to browse the website at demo.gothub.org. It - is conveniently managed by committing changes to the repository. + and allows browsing the website at demo.gothub.org. It is + conveniently managed by committing changes to the repository.

- Since the website makes use of the root domain, we set the repositories - url path to /repos, allowing you to still browse repositories at + Since the website makes use of the root domain, the repositories url + path is set to /repos, allowing repositories to be browsed at demo.gothub.org/repos.

- Note that we disable authentication, as web servers on the Game of - Trees Hub are configured with authentication enabled by default. Without - this, you would be required to log in to view the website. + Note that the disable authentication directive is used, as web + servers on the Game of Trees Hub are configured with authentication enabled + by default. Without this, viewing the website would require users to be + logged in.

- Want a different setup? See the examples below to learn more! For + See the examples below to learn about different configurations. For additional documentation, see gotsys.conf(5).

@@ -68,10 +69,10 @@

One of gotsysd(8)'s - coolest features is its ability to let you manage your repositories - directly from + features is its ability to let users manage their repositories directly + from gotsys.conf(5). - For example, your server configuration will initially contain the following + For example, all server configurations will initially contain the following snippet:

@@ -86,7 +87,7 @@
     repository.
     
     
-    The gotsys repository is special, as it lets you manage your
+    The gotsys repository is special, as it lets users manage their
     repository space by committing changes to it. However, it is declared as
     any other repository. For example, the following snippet creates three new
     repositories:
@@ -104,8 +105,8 @@
     }

- Just like with the gotsys repository, we declare three new - repositories that can be read and written to by the flan_hacker. + Just like with the gotsys repository, three new repositories are + declared that can be read and written to by the flan_hacker user. Note that public_repo_b also allows the anonymous user to clone the repository, but not to send new changes to it, as it is declared with the ro mode (read-only). Repositories that are readable by the @@ -113,11 +114,12 @@ repository when browsing it with a web browser.

- Lastly, it is worth noting that there is currently no way to rename or - delete repositories via + It is worth noting that there is currently no way to rename or delete + repositories via gotsys.conf(5). - However, you can simply remove any repository declaration from your - configuration and the repository will no longer be accesible. + However, existing repositories that are no longer mentioned in the + configuration will be inaccessible, as if they had been declared without + any access rules.

@@ -125,7 +127,7 @@

Setting up a custom domain

- A good way to personalize your repository space is by assigning it a custom + A good way to personalize a repository space is by assigning it a custom domain. This can be done as follows:

- Lastly, configure a web server in your + Lastly, configure a web server in gotsys.conf(5) - using your custom domain. For example, the following snippet configures + using the custom domain. For example, the following snippet configures one for no.vmmbugs.net:

@@ -164,11 +166,9 @@
     
     
     The Game of Trees Hub configures all web servers with authentication
-    enabled by default. This requires visitors to log in before accessing your
-    repositories or website. However, it is up to you to configure who is
-    allowed to authenticate and who isn't. If you want anyone to be able to
-    authenticate, you can use the anonymous user, a reserved user
-    which doesn't need to be declared with the user directive:
+    enabled by default. This requires visitors to log in before accessing
+    repositories or a website. To allow anyone to authenticate, the
+    anonymous user can be used:
     
          web server no.vmmbugs.net {
@@ -177,13 +177,13 @@
     }
     
     
-    This will present you with a login screen and instructions on how to
-    authenticate over ssh when visiting
+    This will present all visitors with a login screen and instructions on how
+    to authenticate over ssh when visiting
     no.vmmbugs.net.
     
     
-    If you want only specific users to be able to authenticate, you need to
-    declare them first with the user directive:
+    In order to allow only specific users to authenticate, those users must
+    first be declared with the user directive:
     
          user flan_hacker {
@@ -195,18 +195,18 @@
     }
     
     
-    Note that in this case you won't be presented with instructions on how to
-    authenticate, as it is expected from the permitted user to know how to do
-    so.
+    Note that in this case, visitors won't be presented with instructions on
+    how to authenticate, as it is expected from the permitted user to know how
+    to do so.
     
     
-    You can set permit/deny rules for all repositories on a web
-    server, like we did in the examples above, or per-repository using the
-    repository directive within the web server block.
+    The permit and deny directives can be set for all
+    repositories on a web server, like in the example above, or per-repository
+    using the repository directive within the web server block.
     
     
-    As a nice bonus, enabling authentication gives your repositories and
-    website an added layer of protection against scraping bots.
+    As a nice bonus, enabling authentication gives repositories and websites an
+    added layer of protection against scraping bots.
     
     
     
@@ -214,11 +214,11 @@
     Configuring the visibility of repositories
     
     
-    When first configuring a web server, you may notice that no repositories
-    are shown in the repository index. This is because web servers on the Game
-    of Trees Hub are initially configured to hide all repositories, preventing
-    the accidental leakage of private repositories. You can use
-    repository-specific parameters to configure this behaviour.
+    When first configuring a web server, the repository index will be empty by
+    default. This is because web servers on the Game of Trees Hub are initially
+    configured to hide all repositories, preventing the accidental leakage of
+    private repositories. This behaviour can be configured by using
+    repository-specific parameters.
     
     
     Repository-specific parameters can be set by using the repository
@@ -240,9 +240,8 @@
     }

- If most of your repositories are public, you can spare yourself some typing - by making all repositories visible by default, and hiding only the private - ones. + Alternatively, repositories can be made visible by default and private + repositories can be hidden as needed.

     web server no.vmmbugs.net {
@@ -254,9 +253,6 @@
       }
     }

- If you decide to do this, be careful not to leak any private repositories! -

@@ -264,7 +260,7 @@

Invalid configurations will be automatically rejected by the server when - sending changes to it. To avoid this, you can validate your configuration + sending changes to it. To avoid this, configurations can be validated before committing any changes with the following gotsys(1) command: @@ -273,9 +269,9 @@ $ gotsys check -f /path/to/gotsys.conf

- This will report any errors in your configuration. Once there are no more - errors, the command will output configuration OK, at which point you - can safely send your changes to the server. + This will report any errors in the configuration. Once there are no more + errors, the command will output configuration OK, at which point + changes can be safely sent to the server.