Implementation Guidelines: Adapt URLs

content/implementation-guidelines/_index.md

@@ -7,7 +7,7 @@ layout: single
 ## Overview
 
 **Modern XMPP** is an independent project launched to improve the quality of user-to-user messaging applications
-that use XMPP. [XMPP](https://xmpp.org/) is a mature open standard for internet messaging. If you are reading
+that use XMPP. [XMPP](/) is a mature open standard for internet messaging. If you are reading
 this, you have probably heard of it.
 
 We are developing a handful of simple documents aimed at people who wish to build on top of XMPP. The recommendations are derived from healthy discussions between developers from multiple XMPP projects and other members of the XMPP community.
@@ -22,11 +22,9 @@ and thus make it possible to identify and weed out software that falls behind th
 
 ## Current status
 
-It is early days. We are still building the foundations of what will become the initial set of documents. Nevertheless, we already have a bunch of stuff documented that developers of XMPP software (both new and experienced) will find useful. This includes [design guidelines](client/design.md) and lower-level [protocol implementation recommendations](client/protocol.md).
+It is early days. We are still building the foundations of what will become the initial set of documents. Nevertheless, we already have a bunch of stuff documented that developers of XMPP software (both new and experienced) will find useful. This includes [design guidelines](/implementation-guidelines/design) and lower-level [protocol implementation recommendations](/implementation-guidelines/protocol).
 
 If you're interested in joining us, our primary discussion venue is our *channel* which can be reached at:
 
 - XMPP: [[email protected]](xmpp:[email protected]?join)
 - Web: [chat.modernxmpp.org](https://chat.modernxmpp.org/)
-
-Contributions to the docs can be made through Github [modernxmpp/modernxmpp](https://github.com/modernxmpp/modernxmpp).

content/implementation-guidelines/design.md

@@ -1,11 +1,7 @@
 ---
-Title: Design Guidelines
+Title: Client Design Guidelines
 ---
 
-Title: 
-
-# Client design guidelines
-
 This document lays out a set of guidelines for designing Modern XMPP clients. For contributions,
 please [open an issue or pull request](https://github.com/modernxmpp/modernxmpp) at Github for discussion.
 
@@ -41,16 +37,16 @@ Support for these options is OPTIONAL, but **not** recommended. They are only ne
 | Connect port        | The network port to connect to               |
 | TLS Mode[^tls-mode] | Multiple choice: "STARTTLS" or "Direct TLS"  |
 
-Both of the above should be automatically discovered from DNS, according to the [rules in RFC 6120](https://xmpp.org/rfcs/rfc6120.html#tcp-resolution).
-Clients that support other connection mechanisms, such as BOSH, SHOULD also implement [XEP-0156](https://xmpp.org/extensions/xep-0156.html).
+Both of the above should be automatically discovered from DNS, according to the [rules in RFC 6120](/rfcs/rfc6120.html#tcp-resolution).
+Clients that support other connection mechanisms, such as BOSH, SHOULD also implement [XEP-0156](/extensions/xep-0156.html).
 
 ### Deprecated options
 
 Support for these options is NOT RECOMMENDED.
 
 | Option       | Description                              | Notes |
 |:-------------|:-----------------------------------------|:--------|
-| Resource     |  The resource to request from the server | see [Resource generation](protocol.md#resource-generation)  |
+| Resource     |  The resource to request from the server | see [Resource generation](/implementation-guidelines/protocol#resource-generation)  |
 | Priority     |  The priority to include in presence     | 0       |
 
 ## User status
@@ -133,7 +129,7 @@ Support for multiple accounts is OPTIONAL.
 
 ## Group chat
 
-You can find more details about [group chats here](groupchat.md).
+You can find more details about [group chats here](/implementation-guidelines/groupchat).
 
 ## Documentation
 
@@ -168,7 +164,7 @@ Address book
 : Platform-dependent. If the application is somehow linked to the user's address book and is able to access a contact's information there.
 
 User nickname
-: A nickname published by the sender in PEP per [XEP-0172](https://xmpp.org/extensions/xep-0172.html).
+: A nickname published by the sender in PEP per [XEP-0172](/extensions/xep-0172.html).
 
 Resource
 : The resource of the sending JID.
@@ -203,7 +199,7 @@ A client may want to associate a color with a user. Example use cases for this i
 - Dummy avatars in contexts where an avatar cannot be or has not yet been retrieved
 - Coloring the user name in a conversation log (be aware that this needs to be done very carefully to be accessible!)
 
-To generate a color for a user, the algorithm described in [XEP-0392](https://xmpp.org/extensions/xep-0392.html) MUST be used.
+To generate a color for a user, the algorithm described in [XEP-0392](/extensions/xep-0392.html) MUST be used.
 
 ### Generator input based on context
 

content/implementation-guidelines/groupchat.md

@@ -20,9 +20,9 @@ To detect if a multi-user chat is a *group chat* or a *channel*
 | Publicly listed  | muc#roomconfig_publicroom | No  (3)   | muc_hidden      | Yes     | muc_public    |
 | PMs              | muc#roomconfig_allowpm | No  (3)   | muc#roomconfig_allowpm to `none` | Yes     | muc#roomconfig_allowpm to `anyone` |
 
-(1) As defined in [XEP-0045: Multi-User Chat - 16.5.3](https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owner)
+(1) As defined in [XEP-0045: Multi-User Chat - 16.5.3](/extensions/xep-0045.html#registrar-formtype-owner)
 
-(2) As defined in [XEP-0045: Multi-User Chat - 16.3](https://xmpp.org/extensions/xep-0045.html#registrar-features)
+(2) As defined in [XEP-0045: Multi-User Chat - 16.3](/extensions/xep-0045.html#registrar-features)
 
 (3) Immutable for *group chats*.
 
@@ -31,7 +31,7 @@ Options marked `(3) Immutable` should be used when creating group chats, and als
 #### About PMs
 
 While it is possible to entirely prevent PMs from being sent with
-[`muc#roomconfig_allowpm`](https://xmpp.org/extensions/xep-0045.html#privatemessage),
+[`muc#roomconfig_allowpm`](/extensions/xep-0045.html#privatemessage),
 clients should prefer using JIDs when `muc#roomconfig_whois` is set to `anyone`.
 
 In channels, if the initiating client has access to revealed JIDs (with
@@ -73,12 +73,12 @@ Bookmark
 : If the chat is present in the user's bookmarks and has a nickname present (as the resource).
 
 Reserved name
-: A chat [may be queried](https://xmpp.org/extensions/xep-0045.html#reservednick) to fetch the
+: A chat [may be queried](/extensions/xep-0045.html#reservednick) to fetch the
     name that is registered by the user for that chat.
 
 User nickname (PEP)
 : The name stored in the user's account according to
-    [XEP-0172](https://xmpp.org/extensions/xep-0172.html#manage).
+    [XEP-0172](/extensions/xep-0172.html#manage).
 
 User nickname (vCard)
 : The name stored in the user's vCard as `NICKNAME`.
@@ -91,21 +91,21 @@ JID username
 
 ### Other user's names
 
-The display of other user's names is covered in the [general UI recommendations](design.md#names).
+The display of other user's names is covered in the [general UI recommendations](/implementation-guidelines/design#names).
 
 ## Bookmarks
 
 Figuring out which group chats to join is the client’s job. For that it
 should store the list of group chats to rejoin automatically on the
 server, named bookmarks. Three possible protocols exist for this:
 
-- [XEP-0402](https://xmpp.org/extensions/xep-0402.html) which is the
+- [XEP-0402](/extensions/xep-0402.html) which is the
   current preferred method
-- [XEP-0048 1.1](https://xmpp.org/extensions/xep-0048.html), recently
+- [XEP-0048 1.1](/extensions/xep-0048.html), recently
   deprecated but still in use by some clients
-- [XEP-0048 1.0](https://xmpp.org/extensions/attic/xep-0048-1.0.html),
+- [XEP-0048 1.0](/extensions/attic/xep-0048-1.0.html),
   in wide use, based on
-  [XEP-0049](https://xmpp.org/extensions/xep-0049.html)
+  [XEP-0049](/extensions/xep-0049.html)
 
 In order to see the same set of bookmarks as every other client the
 user might be using, it is recommended to implement **XEP-0048 1.0** first
@@ -115,7 +115,7 @@ This legacy protocol however doesn’t support notifications when the bookmarks
 change due to another client or the server. To avoid this issue, a modern client
 should also implement **XEP-0402** ("PEP Native Bookmarks"), but use it *only* if the account
 advertises 'urn:xmpp:bookmarks:1#compat' (as defined in [XEP-0402 paragraph 5.3
-Compatibility](https://xmpp.org/extensions/xep-0402.html#compatibility)).
+Compatibility](/extensions/xep-0402.html#compatibility)).
 
 Implementing XEP-0048 1.1 is not recommended in modern clients.
 
@@ -133,7 +133,7 @@ Clients must always use real JIDs for messaging privately within a *group chat*
 
 <!-- Footnotes -->
 
-[^rationale-gc]: Rationale [group chats](/rationale#group-chats)
+[^rationale-gc]: Rationale [group chats](/implementation-guidelines/rationale#group-chats)
 [^local-nickname]: To avoid requiring the user to configure a nickname manually on each device, shared cross-device stores such as PEP and vCard should be preferred.
 [^pm-realjid]: If real JIDs are known to all participants, it is preferable to use that for private communication to avoid confusion. Through-MUC PMs have the following disadvantages:
 

content/implementation-guidelines/invites.md

@@ -116,6 +116,6 @@ If possible, platform detection should be used to highlight download links relev
 
 If the detected platform is a desktop environment, consider also adding a QR code for easy transmission to a user's mobile device.
 
-[XEP-0401]: https://xmpp.org/extensions/xep-0401.html "Ad-hoc Account Invitation Generation"
-[XEP-0445]: https://xmpp.org/extensions/xep-0445.html "Pre-Authenticated In-Band Registration"
-[XEP-0379]: https://xmpp.org/extensions/xep-0379.html "Pre-Authenticated Roster Subscription"
+[XEP-0401]: /extensions/xep-0401.html "Ad-hoc Account Invitation Generation"
+[XEP-0445]: /extensions/xep-0445.html "Pre-Authenticated In-Band Registration"
+[XEP-0379]: /extensions/xep-0379.html "Pre-Authenticated Roster Subscription"