about: move about pages content to root, use /about as base uri

aboutPages/config.toml

@@ -4,17 +4,17 @@
 title = "keys.openpgp.org"
 
 # change with --base-url
-base_url = "https://keys.openpgp.org"
+base_url = "/about"
 
 generate_feeds = true
 feed_filenames = ["atom.xml"]
 
 [extra]
 menu = [
-  "about/_index.md",
-  "about/news/_index.md",
-  "about/usage.md",
-  "about/faq.md",
-  "about/stats.md",
-  "about/privacy.md",
+  "_index.md",
+  "news/_index.md",
+  "usage.md",
+  "faq.md",
+  "stats.md",
+  "privacy.md",
 ]

aboutPages/content/_index.md

@@ -1,3 +1,27 @@
 ---
-redirect_to: /about/
+title: About
+template: page.html
 ---
+
+The {{ brand() }} server is a public service for the distribution and discovery of OpenPGP-compatible keys, commonly referred to as a "keyserver".
+
+**For instructions, see our [usage guide](@/usage.md).**
+
+### How it works
+
+An OpenPGP key contains two types of information:
+
+- **Identity information** describes the parts of a key that identify its owner, also known as "User IDs". A User ID typically includes a name and an email address.
+- **Non-identity information** is all the technical information about the key itself. This includes the large numbers used for verifying signatures and encrypting messages. It also includes metadata like date of creation, some expiration dates, and revocation status.
+
+Traditionally, these pieces of information have always been distributed together. On {{ brand() }}, they are treated differently.  While anyone can upload all parts of any OpenPGP key to {{ brand() }}, our keyserver will only retain and publish certain parts under certain conditions:
+
+Any **non-identity information** will be stored and freely redistributed, if it passes a cryptographic integrity check. Anyone can download these parts at any time as they contain only technical data that can't be used to directly identify a person. Good OpenPGP software can use {{ brand() }} to keep this information up to date for any key that it knows about. This helps OpenPGP users maintain secure and reliable communication.
+
+The **identity information** in an OpenPGP key is only distributed with consent. It contains personal data, and is not strictly necessary for a key to be used for encryption or signature verification. Once the owner gives consent by verifying their email address, the key can be found via search by address.
+
+### Community and platform {#community}
+
+This service is run as a community effort. You can talk to us in #hagrid on OFTC IRC, also reachable as #hagrid:stratum0.org on Matrix. Of course you can also reach us via email, at <tt>support at keys dot openpgp dot org</tt>. The folks who are running this come from various projects in the OpenPGP ecosystem, including Sequoia-PGP, OpenKeychain, and Enigmail.
+
+Technically, {{ brand() }} runs on the [Hagrid](https://gitlab.com/keys.openpgp.org/hagrid) keyserver software, which is based on [Sequoia-PGP](https://sequoia-pgp.org). We are running on [eclips.is](https://eclips.is), a hosting platform focused on Internet Freedom projects, which is managed by [Greenhost](https://greenhost.net/).

aboutPages/content/about/_index.md

@@ -1,27 +0,0 @@
----
-title: About
-template: page.html
----
-
-The {{ brand() }} server is a public service for the distribution and discovery of OpenPGP-compatible keys, commonly referred to as a "keyserver".
-
-**For instructions, see our [usage guide](@/about/usage.md).**
-
-### How it works
-
-An OpenPGP key contains two types of information:
-
-- **Identity information** describes the parts of a key that identify its owner, also known as "User IDs". A User ID typically includes a name and an email address.
-- **Non-identity information** is all the technical information about the key itself. This includes the large numbers used for verifying signatures and encrypting messages. It also includes metadata like date of creation, some expiration dates, and revocation status.
-
-Traditionally, these pieces of information have always been distributed together. On {{ brand() }}, they are treated differently.  While anyone can upload all parts of any OpenPGP key to {{ brand() }}, our keyserver will only retain and publish certain parts under certain conditions:
-
-Any **non-identity information** will be stored and freely redistributed, if it passes a cryptographic integrity check. Anyone can download these parts at any time as they contain only technical data that can't be used to directly identify a person. Good OpenPGP software can use {{ brand() }} to keep this information up to date for any key that it knows about. This helps OpenPGP users maintain secure and reliable communication.
-
-The **identity information** in an OpenPGP key is only distributed with consent. It contains personal data, and is not strictly necessary for a key to be used for encryption or signature verification. Once the owner gives consent by verifying their email address, the key can be found via search by address.
-
-### Community and platform {#community}
-
-This service is run as a community effort. You can talk to us in #hagrid on OFTC IRC, also reachable as #hagrid:stratum0.org on Matrix. Of course you can also reach us via email, at <tt>support at keys dot openpgp dot org</tt>. The folks who are running this come from various projects in the OpenPGP ecosystem, including Sequoia-PGP, OpenKeychain, and Enigmail.
-
-Technically, {{ brand() }} runs on the [Hagrid](https://gitlab.com/keys.openpgp.org/hagrid) keyserver software, which is based on [Sequoia-PGP](https://sequoia-pgp.org). We are running on [eclips.is](https://eclips.is), a hosting platform focused on Internet Freedom projects, which is managed by [Greenhost](https://greenhost.net/).

aboutPages/content/faq.md

@@ -2,7 +2,7 @@
 title: FAQ
 ---
 
-**For instructions, see our [usage guide](@/about/usage.md).**
+**For instructions, see our [usage guide](@/usage.md).**
 
 ### Is this server part of the "SKS" pool? {#sks-pool}
 
@@ -25,7 +25,7 @@ Note: Some OpenPGP software creates keys with incorrectly formatted email addres
 
 ### Can I verify more than one key for some email address? {#verify-multiple}
 
-An email address can only be associated with a single key. When an address is verified for a new key, it will no longer appear in any key for which it was previously verified. [Non-identity information](@/about/_index.md) will still be distributed for all keys.
+An email address can only be associated with a single key. When an address is verified for a new key, it will no longer appear in any key for which it was previously verified. [Non-identity information](@/_index.md) will still be distributed for all keys.
 
 This means a search by email address will only return a single key, not multiple candidates. This eliminates an impossible choice for the user ("Which key is the right one?"), and makes key discovery by email much more convenient.
 
@@ -63,7 +63,7 @@ Some keyservers support search for keys by part of an email address. This allows
 
 A search by email address on {{ brand() }} returns a key only if it exactly matches the email address. That way, a normal user can discover the key associated with any address they already know, but they cannot discover any new email addresses. This prevents a malicious user or spammer from easily obtaining a list of all email addresses on the server.
 
-We made this restriction a part of our [privacy policy](@/about/privacy.md), which means we can't change it without asking for user consent.
+We made this restriction a part of our [privacy policy](@/privacy.md), which means we can't change it without asking for user consent.
 
 ### Do you support Tor? {#tor}
 
@@ -81,7 +81,7 @@ Various reasons:
 
 ### I have trouble updating some keys with GnuPG. Is there a bug? {#older-gnupg}
 
-GnuPG considers keys that contain no identity information to be invalid, and refuses to import them. However, a key that has no [verified email addresses](@/about/_index.md) may still contain useful information. In particular, it's still possible to check whether the key is revoked or not.
+GnuPG considers keys that contain no identity information to be invalid, and refuses to import them. However, a key that has no [verified email addresses](@/_index.md) may still contain useful information. In particular, it's still possible to check whether the key is revoked or not.
 
 In June 2019, the {{ brand() }} team created a patch that allows GnuPG to process updates from keys without identity information. This patch was quickly included in several downstream distributions of GnuPG, including Debian, Fedora, NixOS, and GPG Suite for macOS.
 

aboutPages/content/news/2019-06-12-launch.md

@@ -22,7 +22,7 @@ We thought it time to consider a fresh approach to solve these problems.
 
 #### Identity and non-identity information
 
-The {{ brand() }} keyserver splits up identity and non-identity information in keys. You can find more details on our [about page](@/about/_index.md): The gist is that non-identity information (keys, revocations, and so on) is freely distributed, while identity information is only distributed with consent that can also be revoked at any time.
+The {{ brand() }} keyserver splits up identity and non-identity information in keys. You can find more details on our [about page](@/_index.md): The gist is that non-identity information (keys, revocations, and so on) is freely distributed, while identity information is only distributed with consent that can also be revoked at any time.
 
 If a new key is verified for some email address, it will replace the previous one. This way, every email address is only associated with a single key at most. It can also be removed from the listing at any time by the owner of the address. This is very useful for key discovery: if a search by email address returns a key, it means this is the single key that is currently valid for the searched email address.
 
@@ -40,6 +40,6 @@ In particular, when GnuPG (as of this writing, version 2.2.16) encounters an Ope
 
 Privacy-preserving techniques in keyservers are still new, and we have more ideas for reducing the metadata. But for now, our plan is only to keep {{ brand() }} reliable and fast 🐇, fix any upcoming bugs 🐞, and [listen to feedback](/about#community) from the community. 👂
 
-For more info, head on over to our [about page](@/about/_index.md) and [FAQ](@/about/faq.md) pages. You can get started right away by [uploading your your key](/upload)! Beyond that there is more cool stuff to discover, like our [API](@/about/api.md), and an [Onion Service](@/about/faq.md#tor)!
+For more info, head on over to our [about page](@/_index.md) and [FAQ](@/faq.md) pages. You can get started right away by [uploading your your key](/upload)! Beyond that there is more cool stuff to discover, like our [API](@/api.md), and an [Onion Service](@/faq.md#tor)!
 
 Cheers! 🍻

aboutPages/content/news/2019-09-12-three-months-later/index.md

@@ -2,7 +2,7 @@
 title: Three months after launch ✨
 ---
 
-It has been three months now [since we launched](/about/news#2019-06-12-launch) {{ brand() }}. We are happy to report: It has been a resounding success! 🥳
+It has been three months now [since we launched](/news#2019-06-12-launch) {{ brand() }}. We are happy to report: It has been a resounding success! 🥳
 
 #### Adoption in clients
 
@@ -21,7 +21,7 @@ There is not a lot to report operationally, and no news is good news in this cas
 
 Our traffic is currently at about ten requests per second (more during the day, less on the weekend), and we delivered roughly 100.000 emails in the last month. No sweat.
 
-We made several small operational improvements including deployment of [DNSSEC](http://dnsviz.net/d/keys.openpgp.org/dnssec/), implementing some [rate-limiting](/about/api#rate-limiting), nailing down our [content security policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) headers, and enabling [single-hop](https://blog.torproject.org/whats-new-tor-0298) mode on our Tor Onion Service. You can find a more complete list [here](https://gitlab.com/keys.openpgp.org/hagrid/merge_requests?scope=all&utf8=%E2%9C%93&state=merged).
+We made several small operational improvements including deployment of [DNSSEC](http://dnsviz.net/d/keys.openpgp.org/dnssec/), implementing some [rate-limiting](/api#rate-limiting), nailing down our [content security policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) headers, and enabling [single-hop](https://blog.torproject.org/whats-new-tor-0298) mode on our Tor Onion Service. You can find a more complete list [here](https://gitlab.com/keys.openpgp.org/hagrid/merge_requests?scope=all&utf8=%E2%9C%93&state=merged).
 
 #### Secure email delivery with MTA-STS
 
@@ -41,10 +41,10 @@ We are working on two features:
 
 The first is **localization**. Most people do not speak English, but so far that is the only language we support. To make this service more accessible, we are working with the OTF's [Localization Lab](https://www.opentech.fund/labs/localization-lab/) to make the website and outgoing emails available in several more languages.
 
-The second is to bring back **third-party signatures**. As [mentioned in our FAQ](@/about/faq.md#third-party-signatures), we currently don't support these due to spam and potential for abuse. The idea is to require [cross-signatures](https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20/diffs), which allow each key to choose for itself which signatures from other people it wants to distribute. Despite this extra step, this is fairly compatible with existing software. It also nicely stays out of the way of users who don't care about signatures.
+The second is to bring back **third-party signatures**. As [mentioned in our FAQ](@/faq.md#third-party-signatures), we currently don't support these due to spam and potential for abuse. The idea is to require [cross-signatures](https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20/diffs), which allow each key to choose for itself which signatures from other people it wants to distribute. Despite this extra step, this is fairly compatible with existing software. It also nicely stays out of the way of users who don't care about signatures.
 
 Although work is in progress for both of those features, neither have a planned time of release yet.
 
-Regarding the "no user ID" issue with GnuPG (mentioned in our [last news post](/about/news#2019-06-12-launch-challenges) and our [FAQ](@/about/faq.md#older-gnupg)), a patch that fixes this problem is now carried by Debian, as well as GPGTools for macOS. GnuPG upstream has not merged the patch so far.
+Regarding the "no user ID" issue with GnuPG (mentioned in our [last news post](/news#2019-06-12-launch-challenges) and our [FAQ](@/faq.md#older-gnupg)), a patch that fixes this problem is now carried by Debian, as well as GPGTools for macOS. GnuPG upstream has not merged the patch so far.
 
 That's it! Thanks for your interest! 👋

aboutPages/content/privacy.md

@@ -4,7 +4,7 @@ title: Privacy
 
 ### Name and contact details
 
-{{ brand() }} is a community effort. You can find more information about us, and our contact, details [here](@/about/_index.md).
+{{ brand() }} is a community effort. You can find more information about us, and our contact, details [here](@/_index.md).
 
 ### How we process data
 
@@ -36,7 +36,7 @@ The public keyserver running on {{ brand() }} processes, stores, and distributes
     OpenPGP packet types that were not specifically mentioned above are stripped during upload and never stored, processed or distributed in any way.
 
 
-Data is never relayed to third parties outside of what is available from the public API interfaces, and what is described in this policy and on our [about page](@/about/_index.md).
+Data is never relayed to third parties outside of what is available from the public API interfaces, and what is described in this policy and on our [about page](@/_index.md).
 
 This service is available on the Internet, so anyone, anywhere in the world, can access it and retrieve data from it.
 

aboutPages/content/usage.md

@@ -62,7 +62,7 @@ To configure [GnuPG](https://gnupg.org) to use {{ brand() }} as keyserver, add t
 
 #### Uploading your key {#gnupg-upload}
 
-Keys can be uploaded with GnuPG's --send-keys command, but identity information can't be verified that way to make the key searchable by email address ([what does this mean?](@/about/_index.md)).
+Keys can be uploaded with GnuPG's --send-keys command, but identity information can't be verified that way to make the key searchable by email address ([what does this mean?](@/_index.md)).
 
 *   You can try this shortcut for uploading your key, which outputs a direct link to the verification page:
 
@@ -118,7 +118,7 @@ For testing key retrieval:
 
 ## API
 
-We offer an API for integrated support in OpenPGP applications. Check out our [API documentation](/about/api).
+We offer an API for integrated support in OpenPGP applications. Check out our [API documentation](@/api.md).
 
 ## Others