diff --git a/dealing-with-abuse.md b/dealing-with-abuse.md
index 1720e35ade382ff8e4b8e0a02a9b35ff7542a532..40faa2b52c78673a9888233ccd42974ef5440bed 100644
--- a/dealing-with-abuse.md
+++ b/dealing-with-abuse.md
@@ -2,94 +2,94 @@ The network is hooked into [dronebl.org->https://dronebl.org/] which keeps away
 
 [[toc]]
 
-h1. Channel operator resources
+# Channel operator resources
 
 Very often, channel operators do not need network operators to deal with abuse, but might not know all the tricks they have at their disposal, so it's useful to note them here again. A lot of this comes from the [channel modes documentation->https://charybdis.readthedocs.io/en/release-3.5/cmodes.html]. Basic settings include:
 
-* @+n@ and @+t@: no messages from users outside the channel and topic modifiable only by channel operators
-* @+s@: secret channel. it will not be visible in the server listings or @/WHOIS@ for a user. surprisingly effective
-* @+r@: only registered users can join. very effective, but might not be possible on public support channels as registration is a big barrier for entry on IRC
-* @+S@: SSL-only, surprisingly effective: some bots do not bother connecting over TLS
-* @+b $HOST@: ban the user from the channel.
-* @+q $HOST@: like ban, but the user is not kicked out and is just silenced. useful for trolls as they don't know they are censored.
-* @+i@: make channel invite only
-* @+O@: make channel IRC operator only
-* @+m@ or @+z@: moderated channels
+* `+n` and `+t`: no messages from users outside the channel and topic modifiable only by channel operators
+* `+s`: secret channel. it will not be visible in the server listings or `/WHOIS` for a user. surprisingly effective
+* `+r`: only registered users can join. very effective, but might not be possible on public support channels as registration is a big barrier for entry on IRC
+* `+S`: SSL-only, surprisingly effective: some bots do not bother connecting over TLS
+* `+b $HOST`: ban the user from the channel.
+* `+q $HOST`: like ban, but the user is not kicked out and is just silenced. useful for trolls as they don't know they are censored.
+* `+i`: make channel invite only
+* `+O`: make channel IRC operator only
+* `+m` or `+z`: moderated channels
 
 All those require users to be operators in the channel. A network operator can get channel operator rights in any channel with this:
 
-<code>
+```
 /MSG OperServ MODE #channel +o user
-</code>
+```
 
-See the other [channel modes->https://charybdis.readthedocs.io/en/latest/cmodes.html] you can use in the charybdis documentation, although that list is incomplete: the authoritative list is visible by typing @/QUOTE HELP CMODE@ in your IRC client.
+See the other [channel modes->https://charybdis.readthedocs.io/en/latest/cmodes.html] you can use in the charybdis documentation, although that list is incomplete: the authoritative list is visible by typing `/QUOTE HELP CMODE` in your IRC client.
 
-h1. Private message spam
+# Private message spam
 
-Users susceptible to PM spam can set the @+R@ mode on their nick to ignore messages from unregistered users.
+Users susceptible to PM spam can set the `+R` mode on their nick to ignore messages from unregistered users.
 
-<code>
+```
 /mode +R user
-</code>
+```
 
-h1. Killing users
+# Killing users
 
-The basic way to ban a user network wide is to set a @AKILL@ "line", which blocks a user based on its IP. The simplest way to do this is to talk with @OperServ@ which deploys the ban on all servers for us, with a command like this:
+The basic way to ban a user network wide is to set a `AKILL` "line", which blocks a user based on its IP. The simplest way to do this is to talk with `OperServ` which deploys the ban on all servers for us, with a command like this:
 
-<code>
+```
 /MSG OperServ AKILL ADD *@*.compute.amazonaws.com !T 7d weird freenode spam
-</code>
+```
 
 In this extreme case, we blocked all of Amazon from connecting to the servers because of some spam coming from multiple AWS servers. A less brutal case is to block a single user:
 
-<code>
+```
 /MSG OperServ AKILL ADD baduser !T 7d harassing users and avoiding channel bans
-</code>
+```
 
-Notice how we set a temporary ban (@!T@) of limited duration (seven days, @7d@) and specify a reason (@harassing users and avoiding channel bans@). It's nice to put a "reason" that will make sense to other operators (including yourself) in the future when we review those bans.
+Notice how we set a temporary ban (`!T`) of limited duration (seven days, `7d`) and specify a reason (`harassing users and avoiding channel bans`). It's nice to put a "reason" that will make sense to other operators (including yourself) in the future when we review those bans.
 
-A permanent ban can be set with @!P@. 
+A permanent ban can be set with `!P`. 
 
-You can also look for users joining the network with the @+c@ server notice masks, for example:
+You can also look for users joining the network with the `+c` server notice masks, for example:
 
-<code>
+```
 /MODE user +s +c
-</code>
+```
 
 There are more such flags that can be useful, but too many to detail here, see [the full list of flags->https://charybdis.readthedocs.io/en/release-3.5/umodes.html#meanings-of-server-notice-masks] for more information.
 
-h1. Host/nick pattern-matching
+# Host/nick pattern-matching
 
-Sometimes the above is not enough and users return under a different IP address. In that case, it might be useful to match certain patterns like username or nickname, which can be done with the @RWATCH@ command. For example, this bans the nick @psycl0n@ from the network completely, regardless of the hostname:
+Sometimes the above is not enough and users return under a different IP address. In that case, it might be useful to match certain patterns like username or nickname, which can be done with the `RWATCH` command. For example, this bans the nick `psycl0n` from the network completely, regardless of the hostname:
 
-<code>
+```
 /MSG OperServ RWATCH ADD /^psycl0n!/iSK troll, death threats
-</code>
+```
 
 Some explanation:
 
-* @/^psycl0n!/@ is a regular expression.
-* @/@ marks the beginning and end of the regex, like in Perl
-* @^@ is the beginning of the host string, like in Perl
-* @!@ is the hostmask seperator (which separates the IRC name from the hostname)
-* @i@ means case-insensitive, like in Perl
-* @S@ means to show the nick in the @#services@ channel
-* and, finally, @K@ means to kill the darn user
+* `/^psycl0n!/` is a regular expression.
+* `/` marks the beginning and end of the regex, like in Perl
+* `^` is the beginning of the host string, like in Perl
+* `!` is the hostmask seperator (which separates the IRC name from the hostname)
+* `i` means case-insensitive, like in Perl
+* `S` means to show the nick in the `#services` channel
+* and, finally, `K` means to kill the darn user
 
-Those patterns should be tested with @RMATCH@ first to make sure only the right user is banned.
+Those patterns should be tested with `RMATCH` first to make sure only the right user is banned.
 
-h1. Killing users joining a channel
+# Killing users joining a channel
 
-Botnet frequently try to grab a hold on a network by rejoining always a control channel. Once found, this channel can be blocked by first registering it with @ChanServ@ then telling @OperServ@ to automatically kill users joining a certain channel:
+Botnet frequently try to grab a hold on a network by rejoining always a control channel. Once found, this channel can be blocked by first registering it with `ChanServ` then telling `OperServ` to automatically kill users joining a certain channel:
 
-<code>
+```
 /MSG ChanServ REGISTER #channel
 /MSG OpeServ KLINECHAN #channel ON reason
-</code>
+```
 
-Anyone that joins @#channel@ will be temporarily killed on the network, which is very effective. Already present users will not be killed, but might if they disconnect and reconnect.
+Anyone that joins `#channel` will be temporarily killed on the network, which is very effective. Already present users will not be killed, but might if they disconnect and reconnect.
 
-h1. Other approaches
+# Other approaches
 
 There's a [irssi script->https://dronebl.org/downloads/dronebl.pl] to interoperate directly with DroneBL. It can list and add entries to the database which can be useful for other networks, but wasn't tested by the staff here (yet?).
 
@@ -97,22 +97,22 @@ Freenode uses a [Linmoria->https://github.com/ProgVal/Limnoria] bot called [Sigy
 
 Atheme has a bot to censor "bad words" called [cs_badwords.c->https://github.com/atheme/atheme-contrib-modules] that could be useful to channel operators as well. It should be available in our version of atheme and might just be a matter of enabling the module and configuring it...
 
-h1. Server-wide announces
+# Server-wide announces
 
-When trouble comes, it's good to warn users something is going on. The typical way to do this is to send a Global Notice. This can be done by talking with the @Global@ service:
+When trouble comes, it's good to warn users something is going on. The typical way to do this is to send a Global Notice. This can be done by talking with the `Global` service:
 
-<code>
+```
 /msg Global This is a test. Do not try this at home.
 /msg Global SEND
-</code>
+```
 
-If services are down, however, this will not work and you'll need to issue a notice by hand, using a special @/notice@ command, targeting all server domains:
+If services are down, however, this will not work and you'll need to issue a notice by hand, using a special `/notice` command, targeting all server domains:
 
-<code>
+```
 /notice $$*.koumbit.net This is a test. Do not try this at home.
 /notice $$*.indymedia.org This is a test. Do not try this at home.
-</code>
+```
 
-Note how you need to cycle through all the domain names of the servers in the network (see the list with @/links@ or @/map@).
+Note how you need to cycle through all the domain names of the servers in the network (see the list with `/links` or `/map`).
 
 In both cases, you obviously need to be a network operator on the servers.
diff --git a/getting-a-cloak.md b/getting-a-cloak.md
index cddf6215c1d82438dc7326517689d9a84dfa6415..1c057793c1634e31f6abf97eb6317fa8bcd56c0a 100644
--- a/getting-a-cloak.md
+++ b/getting-a-cloak.md
@@ -1,21 +1,31 @@
 A "cloak" is a string of text that will show to other people on the network if you are logged in to your user instead of your hostname.
 
-*Requirements (e.g. you need to do this before getting a cloak)*
+# Requirements (e.g. you need to do this before getting a cloak)
 
-# if not already done, register with nickserv: <pre>/msg nickserv register <newirconlypassword></pre> (you need to replace &lt;newirconlypassword&gt; by a good password you made up)
-# login to your user. You may want to configure your client to do this every time you login to the network. most clients have mechanisms to perform the login for you. You can also login manually by communicating with nickserv: <pre>/msg nickserv identify <nickname> <yourircpassword></pre> (again, you need to replace &lt;nickname&gt; by your actual nickname, and &lt;yourircpassword&gt; with the password you set for your account).
+1. if not already done, register with nickserv: `/msg nickserv register <newirconlypassword>` (you need to replace `<newirconlypassword>` by a good password you made up)
+1. login to your user. You may want to configure your client to do this every time you login to the network. most clients have mechanisms to perform the login for you. You can also login manually by communicating with nickserv: `/msg nickserv identify <nickname> <yourircpassword>` (again, you need to replace `<nickname>` by your actual nickname, and `<yourircpassword>` with the password you set for your account).
 
-*Grab the generic cloak by yourself*
+# Grab the generic cloak by yourself
 
 There is one cloak pattern that you can configure for your login by yourself. The generic cloak is @$account.unaffiliated@. To get it, you can talk with the @hostserv@ service:
 
-# <pre>/msg hostserv take $account.unaffiliated</pre> -- please note that the @$account@ part should *not* be replaced by your account name. The @hostserv@ service will substitute it automatically for you, and it is part of the cloak pattern.
+1. `/msg hostserv take $account.unaffiliated` -- please note that the
+   `$account` part should *not* be replaced by your account name. The
+   `hostserv` service will substitute it automatically for you, and it
+   is part of the cloak pattern.
 
-*To get a cloak of your choosing*
+# To get a cloak of your choosing
 
 If the generic cloak doesn't suit your taste or needs, you can request one of your choosing:
 
-# decide what string of text should be your cloak. when your cloak is set, you will show up on the network as &lt;nickname&gt;@&lt;yourcloak&gt; -- only when logged in, however.
-** Cloak names can contain numbers, letters, dots and hyphens. They must start and end with either a digit or a letter.
-# once logged in, say in the support channel (@#ircd@): I would like a cloak: &lt;the cloak name&gt;
-# wait, we will add it when we can
+* decide what string of text should be your cloak. when your cloak is
+  set, you will show up on the network as <nickname>@<yourcloak> --
+  only when logged in, however.
+  
+  Cloak names can contain numbers, letters, dots and hyphens. They
+  must start and end with either a digit or a letter.
+  
+1. once logged in, say in the support channel (@#ircd@): I would like
+   a cloak: `<the cloak name>`
+
+1. wait, we will add it when we can
diff --git a/how-to-connect-through-tor-hidden-service.md b/how-to-connect-through-tor-hidden-service.md
index ea8c74ea31a19e6e3daad9e444794214954cb64c..f46e7babbcaa8791dbb39aa184b40a78e6253f20 100644
--- a/how-to-connect-through-tor-hidden-service.md
+++ b/how-to-connect-through-tor-hidden-service.md
@@ -1,9 +1,9 @@
-You can connect to Indymedia IRC server through a Tor Hidden Service, instead of just using Tor to connect to the normal @irc.indymedia.org@ address (which is also possible, by the way).
+You can connect to Indymedia IRC server through a Tor Hidden Service, instead of just using Tor to connect to the normal `irc.indymedia.org` address (which is also possible, by the way).
 
-The hidden service has the address @akeyxc6hie26nlfylwiuyuf3a4tdwt4os7wiz3fsafijpvbgrkrzx2qd.onion@.
+The hidden service has the address `akeyxc6hie26nlfylwiuyuf3a4tdwt4os7wiz3fsafijpvbgrkrzx2qd.onion`.
 
-If your tor software is too old and can't connect to the previous address, you can use the following address: @h7gf2ha3hefoj5ls.onion@ -- however, if it is possible to upgrade your tor software to a more recent version we strongly recommend that you do this and use the first address mentioned above.
+If your tor software is too old and can't connect to the previous address, you can use the following address: `h7gf2ha3hefoj5ls.onion` -- however, if it is possible to upgrade your tor software to a more recent version we strongly recommend that you do this and use the first address mentioned above.
 
 You should connect to it *without SSL* on *port 6667*. The SSL/TLS is already present in Tor, so it's not necessary here.
 
-Warning: SSL/TLS connections are currently allowed through the hidden service (only the "old" v2 onion service), however the service will present to you a certificate that is only valid for host name @irc.indymedia.org@, thus not for the onion host name. Because of this we recommend not to use SSL/TLS with the hidden service since it's impossible to trust the certificate in this situation.
+Warning: SSL/TLS connections are currently allowed through the hidden service (only the "old" v2 onion service), however the service will present to you a certificate that is only valid for host name `irc.indymedia.org`, thus not for the onion host name. Because of this we recommend not to use SSL/TLS with the hidden service since it's impossible to trust the certificate in this situation.
diff --git a/operator.md b/operator.md
index 7fd4f564ec9132e1805f667fe9b09d444ed1e6e3..9757938849662634227f04487d9a37f172073b62 100644
--- a/operator.md
+++ b/operator.md
@@ -3,8 +3,7 @@ Notice: this was copied from https://docs.indymedia.org/Sysadmin/IrcOper and may
 See also http://www.stack.nl/~jilles/irc/charybdis-oper-guide/index.html
 [[toc]]
 
-What is an IRC Operator?
-==========================================================================
+# What is an IRC Operator?
 
 Being an IRC Operator means that you have quite a bit of power of the IMC
 IRC network, this power is not glamerous, it can be difficult to deal with
@@ -27,16 +26,15 @@ operator, server operators can also be channel operators, these people will
 have "*@" next to their name). Also doing a /whois <nick> will show you that
 this person is an operator:
 
-<code>
+```
 00:06 -!- PseudoPunk [irc@localhost]
 00:06 -!-  ircname  : grrrr
 00:06 -!-  server   : kropotkin.indymedia.org [kropotkin IMC IRC server]
 00:06 -!-           : IRC Operator
 00:06 -!- PseudoPunk is a Server Administrator
-</code>
+```
 
-What is required of an IRC Operator?
--------------------------------------------------------------------------
+## What is required of an IRC Operator?
 
 IRC Operators must have a registered nick with nickserv, be subscribed to
 the ircd@indymedia.org mailing list, hang out in #ircd when on IRC, help
@@ -49,8 +47,7 @@ are easy to get to know if you spend some time doing /msg nickserv help,
 IRC Operators have to have access, both server operator access, and operserv
 access and only be an IRC Operator when connected via SecureIRC.
 
-How to become an IRC Operator
--------------------------------------------------------------------------
+## How to become an IRC Operator
 
 As said earlier, there is a lot of power associated with being an IRC
 Operator, unfortunately we need to know that you are going to be able to act
@@ -61,12 +58,11 @@ listservs, help people out in #tech, or work closely on one of the active
 coding projects. Demonstrate to others that we can trust you, and you will
 find that you will be welcomed with open arms.
 
-How to create a new IRC Operator
-==========================================================================
+# How to create a new IRC Operator
 
   1. On che edit /etc/ircd/etc/ircd.conf and search for the operator blocks (search for operator), they look like the following:
 
-<code>
+```
 operator {
         name = "micah";
         user = "*@*127.0.0.1";
@@ -82,8 +78,7 @@ operator {
         nick_changes = yes;
         admin = yes;
 };
-</code>
-
+```
         Copy an existing block, paste it in and then make the appropriate changes:
         change the name, the hostmask and the password.
 
@@ -111,11 +106,9 @@ If everything is ok, do the last thing:
         
   7. Send an announcement to ircd@lists.indymedia.org to let everyone know that there is a new operator on board.
 
-IRC Operator duties
-==========================================================================
+# IRC Operator duties
         
-Securing a channel's operator status
--------------------------------------------------------------------------
+## Securing a channel's operator status
 
 Sometimes channels lose their channel operators, due to lost connections, or
 whatever, and the only way they can get them back is by making everyone
@@ -137,8 +130,7 @@ Once you have secured a channel, try to instruct the people there about
 chanserv and how to use it so that they will always have operator access on
 the channel.
 
-Services are unavailble, how to reconnect them
--------------------------------------------------------------------------
+## Services are unavailble, how to reconnect them
 
          where is nickserv?
 
@@ -165,8 +157,7 @@ What to do if this doesn't work? Generaly this means that the services on
 the services server need to be restarted. To do this, follow the directions
 in http://docs.indymedia.org/view/Sysadmin/IrcD#Restarting_Hybrid_Services
 
-How to deal with bad users
--------------------------------------------------------------------------
+## How to deal with bad users
 
 Sometimes people show up on channels to cause problems, flooding the channel
 with nick changes, obscenities, or whatever. This is not tolerated here,
@@ -186,11 +177,13 @@ keep coming back, ban them from the channel. /kick <nick> reason
 a /ban and then a /kick separately, or there might be a more convenient
 alias for this), /ban <channel> <nicks>
 for example:
-        
+
+```
 /BAN looser       - Bans the nick 'looser'
 /BAN -host looser - Bans the host of nick 'looser'
 /BAN *!*@*.org    - Bans all the users coming from any .org domain (don't do
 this)
+```
 
 be very careful that you don't ban the irc@localhst address or you are going
 to keep out a lot of people...
@@ -203,7 +196,7 @@ and banned from the server. (use operserv /msg operserv gline <user@host>
 [reason]) -- again, **DON'T** gline irc@localhost!! Ban them for something
 like an hour and a half (see second example below):
 
-<code>
+```
 Examples:
 
 /msg operserv GLINE *@*.lamers.org  Don't come back
@@ -212,10 +205,9 @@ Examples:
 /msg operserv GLINE 1h30m *clone@clone.com no clones
               Glines *clone@clone.com for an hour and a half, with the message
               "no clones"
-</code>
+```
 
-How to send a global notice
--------------------------------------------------------------------------
+## How to send a global notice
 
 Sometimes you need to alert everyone on IRC that things need to be
 restarted, or whatever, this should be done for technical reasons only!
@@ -223,27 +215,23 @@ restarted, or whatever, this should be done for technical reasons only!
 Use: /notice $$*.indymedia.org to hit all servers
      or /notice $$judi.indymedia.org for just that server
 
-Cloaks
--------------------------------------------------------------------------
+## Cloaks
 
 To provide cloaks for users, you can use the following commands:
 
-<code>
+```
 /msg NickServ vhost <nick> [<host>]
-</code>
+```
 
 For example, to show myself as anarcat@koumbit.org, I used:
 
-<code>
+```
 /msg NickServ vhost anarcat koumbit.org
-</code>
+```
 
-Reference
-==========================================================================
+# Reference
         
 Here is a good operator reference page:
 http://www.irchelp.org/irchelp/ircd/ircopguide.html
 
-
-
 -- Main.MicahA - 26 Feb 2003
diff --git a/servers.md b/servers.md
index 0702710a419cf1e83aab8892fab4076739a94ee1..d00e84e025d9343734e922fed9388792e2af607f 100644
--- a/servers.md
+++ b/servers.md
@@ -8,11 +8,11 @@ Charybdis
 
 All servers run [Charybdis](http://www.charybdis.io/) for the main IRC server functionality.
 
-Configuration is in @/etc/charybdis/sharedconf@. See [sharedconf] for details on how to propagate that configuration around the different servers.
+Configuration is in `/etc/charybdis/sharedconf`. See [sharedconf](sharedconf) for details on how to propagate that configuration around the different servers.
 
-Charybdis is installed from Debian packages, which is maintained by anarcat. The git repository is in [collab-maint->https://anonscm.debian.org/cgit/collab-maint/charybdis.git/] and you can also see the [package tracker page->http://tracker.debian.org/charybdis] that is quite useful.
+Charybdis is installed from Debian packages, which is maintained by anarcat. The git repository is in [collab-maint](https://anonscm.debian.org/cgit/collab-maint/charybdis.git/) and you can also see the [package tracker page](http://tracker.debian.org/charybdis) that is quite useful.
 
-See also the [operator guide->https://www.stack.nl/~jilles/irc/charybdis-oper-guide/index.html] ([shipped with charybdis->https://github.com/charybdis-ircd/charybdis/tree/release/3.5/doc/sgml/oper-guide]) for more information on channel flags and IRCd configuration. Some extensions are *not* documented in the manual, however, see the [extensions source code->https://github.com/charybdis-ircd/charybdis/blob/release/3.5/doc/reference.conf#L48] for a list of such directives.
+See also the [operator guide](https://www.stack.nl/~jilles/irc/charybdis-oper-guide/index.html) ([shipped with charybdis](https://github.com/charybdis-ircd/charybdis/tree/release/3.5/doc/sgml/oper-guide)) for more information on channel flags and IRCd configuration. Some extensions are *not* documented in the manual, however, see the [extensions source code](https://github.com/charybdis-ircd/charybdis/blob/release/3.5/doc/reference.conf#L48) for a list of such directives.
 
 Web chat
 --------------
@@ -38,7 +38,7 @@ See also
 Server list
 ===========
 
-Note that this section is just aiming to be a global overview of the machines. Specific state of each server (e.g. version, disk space and other stats) is best described by the machine itself. Each IRC operator *should* have shell access with @sudo@ on each of those machines, unless otherwise noted. 
+Note that this section is just aiming to be a global overview of the machines. Specific state of each server (e.g. version, disk space and other stats) is best described by the machine itself. Each IRC operator *should* have shell access with `sudo` on each of those machines, unless otherwise noted. 
 
 The IRC network is composed of those machines:
 
diff --git a/services.md b/services.md
index 459b21414a4dd9b2525745edc83d3ffca97b1a9b..864869ad2f1d23bcc4103f60bb7c1e291e9eeb37 100644
--- a/services.md
+++ b/services.md
@@ -1,8 +1,8 @@
-This is tightly coupled with the maintenance of the [atheme-services debian package->https://tracker.debian.org/pkg/atheme-services]. Usually, the first step in setting up a new host or updating it is to update the Debian package, which is not documented here for now. So let's assume there's a version up to date in unstable for now.
+This is tightly coupled with the maintenance of the [atheme-services debian package](https://tracker.debian.org/pkg/atheme-services). Usually, the first step in setting up a new host or updating it is to update the Debian package, which is not documented here for now. So let's assume there's a version up to date in unstable for now.
 
 We are assuming here you are running Debian stable on a fully configured IRC server (with Charybdis).
 
-Documentation for atheme services can be found on the [official wiki->https://github.com/atheme/atheme/wiki].
+Documentation for atheme services can be found on the [official wiki](https://github.com/atheme/atheme/wiki).
 
 [[toc]]
 
@@ -11,25 +11,25 @@ Installing
 
 The version of atheme in stable is probably outdated and we'll want to use a backport. Hopefully, the version in Debian will already up to date, so you will simply run:
 
-<code>
+```
 sudo apt install -t jessie-backports atheme-services
-</code>
+```
 
 If it's not available publicly or not up to date, you can build a backport by checking out the latest source from stretch and building it in a Jessie host:
 
-<code>
+```
 git clone -b jessie-backports git+ssh://git.debian.org/git/collab-maint/atheme-services.git
 sudo DIST=jessie ARCH=amd64 git-buildpackage --git-debian-branch=jessie-backports
-</code>
+```
 
 If there is no appropriate branch for the current distribution, you can still build the package:
 
-<code>
+```
 apt-get source -t testing atheme-services
 cd atheme-services*
 dch --bpo
 debuild
-</code>
+```
 
 Ideally, you would build those on your own computer in a clean Jessie chroot, and then copy the files over to the server to avoid having all the build tools on the server.
 
@@ -41,7 +41,7 @@ Charybdis
 
 Charybdis should *already* be configured, if you are using the shared config (which you should), with a block like:
 
-<code>
+```
 connect "services.indymedia.org" {
         host = "127.0.0.1";
         send_password = "[censored]";
@@ -51,25 +51,25 @@ connect "services.indymedia.org" {
         class = "server";
         flags = topicburst;
 };
-</code>
+```
 
 Atheme
 ------------
 
 Upon install, the Debian packages does absolutely no configuration. You need to copy files from `/usr/share/doc/atheme-services/examples` to make a new setup. We have not done that for over a decade, however, so you will probably be upgrading from a previous config, see the Upgrading section below.
 
-At the very least, there should be a matching @connect@ block for the above IRC server.
+At the very least, there should be a matching `connect` block for the above IRC server.
 
-@ENABLE=1@ needs to be set in @/etc/default/atheme-services@ for the service to start properly.
+`ENABLE=1` needs to be set in `/etc/default/atheme-services` for the service to start properly.
 
 Upgrading
 =======
 
-Merging the @atheme.conf@ file consists mostly at discovering new modules, new functionalities which can be shared with the users.
+Merging the `atheme.conf` file consists mostly at discovering new modules, new functionalities which can be shared with the users.
 
 First, a git tag is laid against the current config, then the new config is put in place in a separate branch. Then the two branches are merged, and changes are cherry-picked between the two:
 
-<code>
+```
 cd /etc/atheme
 git tag 6.0.11
 git checkout -b 7.0.7
@@ -83,9 +83,9 @@ git reset atheme.conf
 git add -p atheme.conf # re-add the parts of the old config we need
 git checkout -p atheme.conf # restore the upstream configs we want
 git commit -m"upgrade to 7.0.7"
-</code>
+```
 
-This is obviously be a little too complicated: the simplest way to manage this would be for the Debian package to ship a @/etc/atheme/atheme.conf@ default config.
+This is obviously be a little too complicated: the simplest way to manage this would be for the Debian package to ship a `/etc/atheme/atheme.conf` default config.
 
 6 to 7.0.7 upgrade
 --------------------------
@@ -93,39 +93,39 @@ This is obviously be a little too complicated: the simplest way to manage this w
 Changes noted in the config:
 
 * new functionalities:
-** warn before clones limit is hit (4/5)
-** identified users do not count towards the clones limit, up to double the limit
+  * warn before clones limit is hit (4/5)
+  * identified users do not count towards the clones limit, up to double the limit
 * new modules:
-** Bad email address blocking (@nickserv/badmail@)
-** LISTGROUPS command (@nickserv/listgroups@)
-** RESTRICT command (@nickserv/restrict@)
-** CLONE command (@chanserv/clone@)
-** SET NEVERGROUP command (@nickserv/set_nevergroup@)
-** SET NEVEROP command (@nickserv/set_neverop@)
-** SET NOGREET command (@nickserv/set_nogreet@)
-** Moderated channel registration (@chanserv/moderate@, disabled)
-** SYNC command (and automatic ACL syncing, @chanserv/sync@)
-** SET command for OperServ to modify temporarily config options (@operserv/set@)
-** StatServ (adds basic stats and split tracking, main, netsplit and server enabled, channel disabled)
-** RPGserv (provides a facility for finding roleplaying channels, disabled)
-** ChanFix (provides recovery services without registration, disabled)
+  * Bad email address blocking (`nickserv/badmail`)
+  * LISTGROUPS command (`nickserv/listgroups`)
+  * RESTRICT command (`nickserv/restrict`)
+  * CLONE command (`chanserv/clone`)
+  * SET NEVERGROUP command (`nickserv/set_nevergroup`)
+  * SET NEVEROP command (`nickserv/set_neverop`)
+  * SET NOGREET command (`nickserv/set_nogreet`)
+  * Moderated channel registration (`chanserv/moderate`, disabled)
+  * SYNC command (and automatic ACL syncing, `chanserv/sync`)
+  * SET command for OperServ to modify temporarily config options (`operserv/set`)
+  * StatServ (adds basic stats and split tracking, main, netsplit and server enabled, channel disabled)
+  * RPGserv (provides a facility for finding roleplaying channels, disabled)
+  * ChanFix (provides recovery services without registration, disabled)
 * wants to be disable, we keep:
-** @nickserv/access@
-** @nickserv/cert@
-** @nickserv/enforce@
-** @nickserv/fflags@
-** @nickserv/xop@
-** @saslserv/dh-blowfish@
-** @operserv/clearchan@
-** @operserv/clones@
-** @operserv/rakill@
-** @operserv/soper@
+  * `nickserv/access`
+  * `nickserv/cert`
+  * `nickserv/enforce`
+  * `nickserv/fflags`
+  * `nickserv/xop`
+  * `saslserv/dh-blowfish`
+  * `operserv/clearchan`
+  * `operserv/clones`
+  * `operserv/rakill`
+  * `operserv/soper`
 * wants to enable, we keep disabled:
-** nickserv spam setting
-** nickserv and chanserv 30 day expiry (we keep 180 days)
-** httpd server wants to come back
+  * nickserv spam setting
+  * nickserv and chanserv 30 day expiry (we keep 180 days)
+  * httpd server wants to come back
 
-Note that there's a now [Web UI called SWI->https://atheme.github.io/swi.html) as well, which could allow
+Note that there's a now [Web UI called SWI](https://atheme.github.io/swi.html) as well, which could allow
 users to register through Tor to join the network anonymously.
 
 Backups
@@ -133,9 +133,9 @@ Backups
 
 A full backup of the configuration and databases of atheme can be performed with:
 
-<code>
+```
 tar cfz /var/backups/atheme-services-$(date %+Ymd).tgz /etc/atheme /var/lib/atheme
-</code>
+```
 
 This omits logfiles.
 
@@ -146,11 +146,11 @@ Migrating to another host is basically all of the above:
 
 * install charybdis
 * install atheme (see "Installing" above)
-* copy the config (@atheme.conf@) over and upgrade it (see "Upgrading" above)
-* fix @connect@ block in charybdis
-* fix @uplink@ block in atheme
-* stop services on current host: @service atheme-services stop@ (ignore if old host is down, obviously)
-* copy @/var/lib/atheme/services.db@ from old host to new host (or restore from backups)
+* copy the config (`atheme.conf`) over and upgrade it (see "Upgrading" above)
+* fix `connect` block in charybdis
+* fix `uplink` block in atheme
+* stop services on current host: `service atheme-services stop` (ignore if old host is down, obviously)
+* copy `/var/lib/atheme/services.db` from old host to new host (or restore from backups)
 * start atheme on new host
 
 The secret channel
@@ -160,28 +160,28 @@ Services are confiured to hang out in a channel and post some information there
 
 That channel needs to be restricted so that only authenticated network operators can join. There's a magic mode that we can set manually to setup the desired restriction:
 
-<code>
+```
 /mode #services +O
-</code>
+```
 
-Unfortunately, this flag currently (2020-05) won't stick around when we restart atheme and/or charybdis on chat1 even though the channel has mode @+P@ which charybdis developers said it should make channel modes persist even if it gets emptied of all users.
+Unfortunately, this flag currently (2020-05) won't stick around when we restart atheme and/or charybdis on chat1 even though the channel has mode `+P` which charybdis developers said it should make channel modes persist even if it gets emptied of all users.
 
-The @+O@ flag seems to be a shortcut for @+irc@ and @+I $o@. We can add the @+irc@ options to the MLOCK to make them permanent. TODO: verify that @+irc@ modes persist through restarts of charybdis on chat1 in the future.
+The `+O` flag seems to be a shortcut for `+irc` and `+I $o`. We can add the `+irc` options to the MLOCK to make them permanent. TODO: verify that `+irc` modes persist through restarts of charybdis on chat1 in the future.
 
 However the invite exemption list might still get cleared if the channel is destroyed (presumably that's what's happening since flags get cleared out). To check whether the invite exemption is still present, one can list them with:
 
-<code>
+```
 /mode #services +I
-</code>
+```
 
 there should be an entry that looks like the following:
 
-<code>
+```
 16:38 -!- #services: invite $o [by LeLutin!~lelutin@koumbit.org, 13521 secs ago]
-</code>
+```
 
 If the list is empty, you can place the invite exemption back with:
 
-<code>
+```
 /mode #service +I $o
-</code>
+```
diff --git a/sharedconf.md b/sharedconf.md
index 02c3c92ae71502f4e4b59622cca73f975f53c37c..65448d9a04f952ed65be56bb6a6615fbe331779c 100644
--- a/sharedconf.md
+++ b/sharedconf.md
@@ -1,24 +1,24 @@
-We have a shared configuration among all the IRC servers in @/etc/charybdis/sharedconf@. That configuration is committed into git and should be the same on *all* servers. You can *clonse* that directory directly and push to it, provided you are part of the @ircd@ group (which you should be if you are an operator).
+We have a shared configuration among all the IRC servers in `/etc/charybdis/sharedconf`. That configuration is committed into git and should be the same on *all* servers. You can *clonse* that directory directly and push to it, provided you are part of the `ircd` group (which you should be if you are an operator).
 
-@/etc@ is also under version control with @etckeeper@. Please do commit changes with a meaningful commit log. For more far-ranging changes, edit @/etc/changelog@.
+`/etc` is also under version control with `etckeeper`. Please do commit changes with a meaningful commit log. For more far-ranging changes, edit `/etc/changelog`.
 
 [[toc]]
 
 Applying configuration changes
 =====================
 
-When modified, the configuration should be reloaded with @service charybdis reload@. Important: on some servers, the reload may *not* work, as the @init.d@ script has a bug where the signal is not delivered correctly. If the motd doesn't mention the @init.d@ is patched, you probably need to find the process yourself (@ps ax | grep charybdis@) and delivery the signal yourself (@kill -HUP $pid@). The bug is present in charybdis 3.5.0-1 and previous.
+When modified, the configuration should be reloaded with `service charybdis reload`. Important: on some servers, the reload may *not* work, as the `init.d` script has a bug where the signal is not delivered correctly. If the motd doesn't mention the `init.d` is patched, you probably need to find the process yourself (`ps ax | grep charybdis`) and delivery the signal yourself (`kill -HUP $pid`). The bug is present in charybdis 3.5.0-1 and previous.
 
 Propogating configuration changes
 =================
 
-All the important configuration for the IRC servers lives in @/etc/charybdis/sharedconf@, which is a git repository *separate* from the parent @/etc@ repository. Changes can be pushed and pulled from thar repository, because it is setup with @core.sharedRepository@ set to @group@. This picture shows basically how this works:
+All the important configuration for the IRC servers lives in `/etc/charybdis/sharedconf`, which is a git repository *separate* from the parent `/etc` repository. Changes can be pushed and pulled from thar repository, because it is setup with `core.sharedRepository` set to `group`. This picture shows basically how this works:
 
-!/assets/291844/s.png!:/assets/291844/s.png
+![diagram](s.png)
 
 To clone the configuration and setup all branches:
 
-<code>
+```
 git clone chat1.koumbit.net:/etc/charybdis/sharedconf
 cd sharedconf
 git remote rename origin chat1
@@ -26,11 +26,11 @@ git remote add chat0 chat0.koumbit.net:/etc/charybdis/sharedconf
 git fetch chat0
 git remote add che che.indymedia.org:/etc/charybdis/sharedconf
 git fetch che
-</code>
+```
 
-On 2019-11-13, the following configuration was performed on @che@:
+On 2019-11-13, the following configuration was performed on `che`:
 
-<code>
+```
 addgroup ircop
 for op in $ALL_OPS ; do adduser $op ircop ; done
 cd /etc/charybdis/sharedconf
@@ -39,7 +39,7 @@ git config core.sharedRepository group
 chown -R :ircop .
 chmod g+rwX -R .
 chmod a+X .
-</code>
+```
 
 The downside of this approach is it removes the "two-factor authentication" (SSH keys and password) we currently have (more or less) to change configurations.
 
@@ -50,13 +50,13 @@ This is the way anarcat built the push/pull system originally, but it was very c
 
 !/assets/291841/s.png!:/assets/291841/s.png
 
-Obviously, this would be simpler if @/etc/chardybdis/sharedconf@ was a "shared" git repository (all users in the same group with write access, see @core.sharedRepository@ in @git-config(1)@. A post-receive hook to reset the checkout would also need to be added, like [post-receive-checkout-force->https://redmine.koumbit.net/projects/git-hooks/repository/revisions/master/entry/post-receive-checkout-force] or [post-receive-checkout-copy->https://redmine.koumbit.net/projects/git-hooks/repository/revisions/master/entry/post-receive-checkout-copy], if we want to keep a separate bare repository.
+Obviously, this would be simpler if `/etc/chardybdis/sharedconf` was a "shared" git repository (all users in the same group with write access, see `core.sharedRepository` in `git-config(1)`. A post-receive hook to reset the checkout would also need to be added, like [post-receive-checkout-force](https://redmine.koumbit.net/projects/git-hooks/repository/revisions/master/entry/post-receive-checkout-force) or [post-receive-checkout-copy](https://redmine.koumbit.net/projects/git-hooks/repository/revisions/master/entry/post-receive-checkout-copy), if we want to keep a separate bare repository.
 
-Also: notice how there is no clear way of sending changes from @/etc/charybdis/sharedconf@! I usually cheat by pushing to my personal repo as root and then fix the permissions with @chown -R anarcat ~/sharedconf.git@.
+Also: notice how there is no clear way of sending changes from `/etc/charybdis/sharedconf`! I usually cheat by pushing to my personal repo as root and then fix the permissions with `chown -R anarcat ~/sharedconf.git`.
 
 And yes, this means a fairly elaborate configuration on your laptop. Here is my current list of remotes:
 
-<code>
+```
 anarcat@angela:sharedconf$ git remote -v
 chat0   chat0.koumbit.net:sharedconf.git (fetch)
 chat0   chat0.koumbit.net:sharedconf.git (push)
@@ -66,15 +66,15 @@ che     che.indymedia.org:sharedconf.git (fetch)
 che     che.indymedia.org:sharedconf.git (push)
 guerin  guerin.indymedia.org:sharedconf.git (fetch)
 guerin  guerin.indymedia.org:sharedconf.git (push)
-</code>
+```
 
-Also note that the @/etc/charybdis/ircd.conf@ file is specific to each server. Still, it is managed in the @sharedconf@ directory through a symlink to @/etc/charybdis/sharedconf/ircd-$(hostname -s).conf@. This allows easier comparison between the server of this crucial configuration file.
+Also note that the `/etc/charybdis/ircd.conf` file is specific to each server. Still, it is managed in the `sharedconf` directory through a symlink to `/etc/charybdis/sharedconf/ircd-$(hostname -s).conf`. This allows easier comparison between the server of this crucial configuration file.
 
 h3. Downsides
 
-Obviously, this setup is too complicated. It could be better to have a central git host - but then we have a central point of failure to exchange files. It also means setting up SSH connexions among the servers, which implies that a compromise on one server could extend on the other servers. Maybe this could be limited with the use of a restricted @git-shell@ and a special user on some host, but then you quickly get into key management problems.
+Obviously, this setup is too complicated. It could be better to have a central git host - but then we have a central point of failure to exchange files. It also means setting up SSH connexions among the servers, which implies that a compromise on one server could extend on the other servers. Maybe this could be limited with the use of a restricted `git-shell` and a special user on some host, but then you quickly get into key management problems.
 
-The setup above is especially complicated because users don't have write access to @/etc/charybdis/sharedconf@ without first going through @sudo@.
+The setup above is especially complicated because users don't have write access to `/etc/charybdis/sharedconf` without first going through `sudo`.
 
 
 Configuration management
@@ -84,32 +84,32 @@ Another alternative would be to use more elaborate configuration management like
 
 The task of cleaning up that stuff is assigned and tracked as part of the main [todo] list.
 
-Update: note that Puppet is currently in use in some of the nodes. In particular, che has some Puppet configuration that is manually ran out of @/root/puppet@.
+Update: note that Puppet is currently in use in some of the nodes. In particular, che has some Puppet configuration that is manually ran out of `/root/puppet`.
 
 Configuration management problems
 ==========================
 
 There are a few configuration management problems to solve on the cluster right now.
 
-# user, password and SSH key setup - currently done by hand
-# charybdis code deployment - currently done through the debian package and "by hand" deployment (@scp@ to each host and @dpkg -i@)
-# charybdis configuration - currently done with git with the above convoluted setup
-# tor hidden service configuration - currently done with a master-less puppet setup
-# TLS/X509 certificates deployment - currently done automatically with let's encrypt on @chat1@, certificates are synchronized by hand
+1. user, password and SSH key setup - currently done by hand
+2. charybdis code deployment - currently done through the debian package and "by hand" deployment (`scp` to each host and `dpkg -i`)
+3. charybdis configuration - currently done with git with the above convoluted setup
+4. tor hidden service configuration - currently done with a master-less puppet setup
+5. TLS/X509 certificates deployment - currently done automatically with let's encrypt on `chat1`, certificates are synchronized by hand
 
 We should find a unified solution for all of this. Here are the solutions proposed so far:
 
-* keep using only git, with a centralized repository (say on [0xacab->https://0xacab.org/]) and possibly with git-gcrypt encryption. downside: doesn't address parts 1, 4 and 5 above
-* use a master-less Puppet setup. already setup on @che.indymedia.org:/root/puppet@. downside: syncing the configurations still requires a central repo. workflow unclear to do deployments (how do we pull the code on each server? by hand?)
+* keep using only git, with a centralized repository (say on [0xacab](https://0xacab.org/)) and possibly with git-gcrypt encryption. downside: doesn't address parts 1, 4 and 5 above
+* use a master-less Puppet setup. already setup on `che.indymedia.org:/root/puppet`. downside: syncing the configurations still requires a central repo. workflow unclear to do deployments (how do we pull the code on each server? by hand?)
 * create a new Ansible playbook. downside: syncing configurations still requires a central repo. some people less familiar with ansible.
-* use [DNS authentication->https://certbot-dns-rfc2136.readthedocs.io/en/latest/] for X509 certificates renewals. allows per-host real names (e.g. you can connect to "che.indymedia.org" and the hostname will match). downside: requires access (delegation!) to indymedia.org (and koumbit.net!) records
+* use [DNS authentication](https://certbot-dns-rfc2136.readthedocs.io/en/latest/) for X509 certificates renewals. allows per-host real names (e.g. you can connect to "che.indymedia.org" and the hostname will match). downside: requires access (delegation!) to indymedia.org (and koumbit.net!) records
 
 Graphs source code
 ==================
 
 The above graphs were generated with the following dot files:
 
-<code>
+```
 digraph sharedconf {
         guerinsharedconf [ label="guerin:/etc/charybdis/sharedconf" ]
         guerinsharedconfbare [ label="guerin:/home/anarcat/sharedconf.git (bare)" ]
@@ -123,9 +123,9 @@ digraph sharedconf {
         chesharedconfbare -> chesharedconf [ label="local pull as root" ]
         laptop -> chesharedconfbare [ label="pull/push over ssh" ]
 }
-</code>
+```
 
-<code>
+```
 digraph sharedconf {
         guerinsharedconf [ label="guerin:/etc/charybdis/sharedconf" ]
         chesharedconf [ label="che:/etc/charybdis/sharedconf" ]
@@ -137,4 +137,4 @@ digraph sharedconf {
         etc [ label = "..." ]
         laptop -> etc
 }
-</code>
+```
diff --git a/tls-configuration.md b/tls-configuration.md
index a6467233ae48509bb9a12d71e23c358827cfa3a7..82b5be43732c814df7e0c35125f68528bf857a60 100644
--- a/tls-configuration.md
+++ b/tls-configuration.md
@@ -1,28 +1,28 @@
-h1. Initial problematic
+# Initial problematic
 
-Before april 2020, our TLS configuration was this: @chat1.koumbit.net@ was generating the cert which we were copying by hand to all hosts. But at some point in 2020, this completely stopped working, because of [changes in Let's Encrypt->https://letsencrypt.org/caaproblem/]. So other servers were kicked out of rotation and the cert was correctly renewed.
+Before april 2020, our TLS configuration was this: `chat1.koumbit.net` was generating the cert which we were copying by hand to all hosts. But at some point in 2020, this completely stopped working, because of [changes in Let's Encrypt](https://letsencrypt.org/caaproblem/). So other servers were kicked out of rotation and the cert was correctly renewed.
 
-h1. Switch to DNS-based authentication
+# Switch to DNS-based authentication
 
-On April 26 2020, certbot was configured to do a DNS-01 challenge with Let's Encrypt and the [dns-rfc2136 plugin->https://certbot-dns-rfc2136.readthedocs.io/en/stable/] on all three servers. They now have a valid TLS certificate.
+On April 26 2020, certbot was configured to do a DNS-01 challenge with Let's Encrypt and the [dns-rfc2136 plugin](https://certbot-dns-rfc2136.readthedocs.io/en/stable/) on all three servers. They now have a valid TLS certificate.
 
 The configuration is that every server fetches its own version of the irc.indymedia.org TLS certificate using DNS-01 authentication. Ideally, each server would also add its own FQDN to the cert, but that still needs to be configured. We needed a patched version of certbot to make this work.
 
-Then RFC2136 "nsupdate" keys are distributed from the primary DNS server to each ircd. Those keys have UPDATE access on the @irc-le.indymedia.org@ zone and generate their own cert in their own time. We use the @--reuse-key@ parameter to make sure the private key doesn't change on renewal, as we use the private key fingerprint in the cross-connect configuration.
+Then RFC2136 "nsupdate" keys are distributed from the primary DNS server to each ircd. Those keys have UPDATE access on the `irc-le.indymedia.org` zone and generate their own cert in their own time. We use the `--reuse-key` parameter to make sure the private key doesn't change on renewal, as we use the private key fingerprint in the cross-connect configuration.
 
 Changes performed:
 
-# chat0.koumbit.net relinked with chat1.koumbit.net
-# chat0.koumbit.net private key changed
-# irc.indymedia.org cert created on chat0.koumbit.net with DNS-01 authentication, with virtualenv code that will fail at next renewal
-# DNS-01 configuration performed on chat0.koumbit.net
-# chat0 and che added back into rotation (che still down)
-# DNS-01 configuration attempted (and failed) on che
+1. chat0.koumbit.net relinked with chat1.koumbit.net
+1. chat0.koumbit.net private key changed
+1. irc.indymedia.org cert created on chat0.koumbit.net with DNS-01 authentication, with virtualenv code that will fail at next renewal
+1. DNS-01 configuration performed on chat0.koumbit.net
+1. chat0 and che added back into rotation (che still down)
+1. DNS-01 configuration attempted (and failed) on che
 
 To reproduce the config:
 
-# deploy certbot from the fork:
-<code>
+1. deploy certbot from the fork:
+```
 git clone https://github.com/certbot/certbot/
 cd certbot
 git remote add -f hpax https://github.com/hpax/certbot.git
@@ -33,47 +33,48 @@ cd certbot
 ~/.virtualenv/certbot/bin/pip3 install .
 cd ../certbot-dns-rfc2136
 ~/.virtualenv/certbot/bin/pip3 install .
-</code>
-# configure a @/etc/letsencrypt/rfc2136-credentials.ini@ file with the following content (e.g. on che), the @dns_rfc2136_name@, @dns_rfc2136_secret@ and @dns_rfc2136_algorithm@ parameters are magic and come from the DNS primary :
-<code># Target DNS server
+```
+1. configure a `/etc/letsencrypt/rfc2136-credentials.ini` file with the following content (e.g. on che), the `dns_rfc2136_name`, `dns_rfc2136_secret` and `dns_rfc2136_algorithm` parameters are magic and come from the DNS primary :
+```
+# Target DNS server
 #dns_rfc2136_server = ns2.riseup.net.
-# https://github.com/certbot/certbot/issues/7871
+1. https://github.com/certbot/certbot/issues/7871
 dns_rfc2136_server = 204.13.164.8
-# Target DNS port
+1. Target DNS port
 dns_rfc2136_port = 53
-# TSIG key name
+1. TSIG key name
 dns_rfc2136_name = che_ircd_key
-# TSIG key secret
+1. TSIG key secret
 dns_rfc2136_secret = [CENSORED]==
-# TSIG key algorithm
+1. TSIG key algorithm
 dns_rfc2136_algorithm = HMAC-SHA512
-</code>
-# create the certificate:
-<code>
+```
+1. create the certificate:
+```
 ~/.virtualenv/certbot/bin/certbot --dns-rfc2136-credentials /etc/letsencrypt/rfc2136-credentials.ini  certonly -d irc.indymedia.org --register-unsafely-without-email --dns-rfc2136 --reuse-key
-</code>
-# change permissions on the generated cert:
-<code>
+```
+1. change permissions on the generated cert:
+```
 chown -R :ssl-cert /etc/letsencrypt/archive/
 chmod -R g+rX /etc/letsencrypt/archive/
-</code>
-# add the cert to @/etc/charybdis/ircd.conf@ and restart the ircd
-<code>
+```
+1. add the cert to `/etc/charybdis/ircd.conf` and restart the ircd
+```
 service charybdis restart
-</code>
-# extract the new SHA256 private key fingerprint:
-<code>
+```
+1. extract the new SHA256 private key fingerprint:
+```
 certtool --pubkey-info --load-privkey /etc/letsencrypt/live/irc.indymedia.org/privkey.pem |  grep -i sha256 | grep -v pin-
-</code>
-# add that key to the @connect@ block on the other servers, and restarted those ircds:
-<code>
+```
+1. add that key to the `connect` block on the other servers, and restarted those ircds:
+```
 service charybdis restart
-</code>
-# create cronjob to use patched certbot for renewals:
-<code>
+```
+1. create cronjob to use patched certbot for renewals:
+```
 cat > /etc/cron.daily/certbot-rfc2136 <<EOF
-# We need to use our patched version of certbot to renew certs so that DNS-01
-# challenges can be completed
+1. We need to use our patched version of certbot to renew certs so that DNS-01
+1. challenges can be completed
 
 SHELL=/bin/sh
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
@@ -83,32 +84,32 @@ EOF
 cat > /usr/local/bin/patched_certbot_renew <<EOF
 #!/bin/sh
 
-# Use the patched certbot to renew certificates
+1. Use the patched certbot to renew certificates
 /root/.virtualenv/certbot/bin/certbot -q renew
 EOF
 chmod a+x /usr/local/bin/patched_certbot_renew
-</code>
-# create renewal hook so that charybdis takes on the new certificates automatically
-<code>
+```
+1. create renewal hook so that charybdis takes on the new certificates automatically
+```
 cat > /etc/letsencrypt/renewal-hooks/deploy/charybdis <<EOF
 #!/bin/sh
 
 /usr/sbin/service charybdis reload
 EOF
 chmod a+x /etc/letsencrypt/renewal-hooks/deploy/charybdis
-</code>
+```
 
 To configure a DNS primary server, the following command need to be issued:
 
-<code>
+```
 dnssec-keygen -a HMAC-SHA512 -b 512 -n _acme-challenge.irc-le.indymedia.org chat1.koumbit.net.
 dnssec-keygen -a HMAC-SHA512 -b 512 -n _acme-challenge.irc-le.indymedia.org chat0.koumbit.net.
 dnssec-keygen -a HMAC-SHA512 -b 512 -n _acme-challenge.irc-le.indymedia.org che.indymedia.org.
-</code>
+```
 
 And the following config must be added to bind:
 
-<code>
+```
 key "chat1.koumbit.net." {
   algorithm hmac-sha512;
   secret "[KEY CONTENT]";
@@ -133,25 +134,27 @@ zone "irc-le.indymedia.org." IN {
     grant che.indymedia.org. name _acme-challenge.irc-le.indymedia.org. txt;
   };
 };
-</code>
+```
 
-Then the challenge record gets delegated with this entry in the @indymedia.org@ zone:
+Then the challenge record gets delegated with this entry in the `indymedia.org` zone:
 
-<code>_acme-challenge.irc.indymedia.org CNAME _acme-challenge.irc-le.indymedia.org.</code>
+```
+_acme-challenge.irc.indymedia.org CNAME _acme-challenge.irc-le.indymedia.org.
+```
 
-h1. Problems encountered
+# Problems encountered
 
-# che blocks responses from primary nameserver (ns2.r.n), we see the traffic goign ouit of ns2 but not in che. this makes it impossible for che to get its own certificate, so we gave up on it for now.
-# certbot doesn't take a hostname as a DNS server argument: https://github.com/certbot/certbot/issues/7871 workaround: we used the IP
-# _acme-challenge CNAME delegation is buggy in certbot. workaround: we deployed code from: https://github.com/certbot/certbot/pull/7244
-# the dns-rfc2136 plugin hardcodes a DNS server instead of looking up the NS records, which makes it impossible to (say) authenticate with @koumbit.net@ *and* @indymedia.org@, which makes it impossible to have a @SubjectAltName@  for the @koumbit.net@ servers
-# when the certbot plugin failed, we tried to use dehydrated but we couldn't figure out how to make it work. it might be possible to make a custom renewal hook to implement exactly what we need here and that might be simpler than patching certbot!
+1. che blocks responses from primary nameserver (ns2.r.n), we see the traffic goign ouit of ns2 but not in che. this makes it impossible for che to get its own certificate, so we gave up on it for now.
+1. certbot doesn't take a hostname as a DNS server argument: https://github.com/certbot/certbot/issues/7871 workaround: we used the IP
+1. _acme-challenge CNAME delegation is buggy in certbot. workaround: we deployed code from: https://github.com/certbot/certbot/pull/7244
+1. the dns-rfc2136 plugin hardcodes a DNS server instead of looking up the NS records, which makes it impossible to (say) authenticate with `koumbit.net` *and* `indymedia.org`, which makes it impossible to have a `SubjectAltName`  for the `koumbit.net` servers
+1. when the certbot plugin failed, we tried to use dehydrated but we couldn't figure out how to make it work. it might be possible to make a custom renewal hook to implement exactly what we need here and that might be simpler than patching certbot!
 
-h1. Remaining work
+# Remaining work
 
-# -contact che people re networking troubles, and redo the DNS-01 deployment on che-: DONE! DNS updates now work. we investigated why certbot couldn't fallback to TCP (which works, as confirmed by @nsupdate -v@) but could not figure it out
-# deploy CNAME delegation workaround "correctly": right now renewal will fail on chat0 because certbot is deploy from @~/.virtualenv/certbot@ and not in the system's @$PATH@. this might involve forking in a different plugin
-# -a new cert needs to be issued on chat1.koumbit.net, and the fingerprint distributed to the other nodes, using the DNS-01 mechanism-: DONE! chat1 and che now both have valid certs too, although not with their own name.
-# research how it would be possible to add the @SubjectAltName@ for the @koumbit.net@ servers. would probably need a custom dehydrated hook, or more patches to certbot.
+1. -contact che people re networking troubles, and redo the DNS-01 deployment on che-: DONE! DNS updates now work. we investigated why certbot couldn't fallback to TCP (which works, as confirmed by `nsupdate -v`) but could not figure it out
+1. deploy CNAME delegation workaround "correctly": right now renewal will fail on chat0 because certbot is deploy from `~/.virtualenv/certbot` and not in the system's `$PATH`. this might involve forking in a different plugin
+1. -a new cert needs to be issued on chat1.koumbit.net, and the fingerprint distributed to the other nodes, using the DNS-01 mechanism-: DONE! chat1 and che now both have valid certs too, although not with their own name.
+1. research how it would be possible to add the `SubjectAltName` for the `koumbit.net` servers. would probably need a custom dehydrated hook, or more patches to certbot.
 ** this does not seem to be necessary
-# -the charybdis servers probably need to be restarted in the certbot hooks, which is not currently the case-
+1. -the charybdis servers probably need to be restarted in the certbot hooks, which is not currently the case-
diff --git a/tor-hidden-service.md b/tor-hidden-service.md
index 16bb921446de88a0aab6b7c3c56989e397621307..469800d9eb2ca283fd067cf005b526c3ca6951dd 100644
--- a/tor-hidden-service.md
+++ b/tor-hidden-service.md
@@ -1,12 +1,12 @@
-h1. Configuration
+# Configuration
 
 We have a Hidden Service to allow Tor users to connect directly to the IRC network. The hostname is:
 
-<code>akeyxc6hie26nlfylwiuyuf3a4tdwt4os7wiz3fsafijpvbgrkrzx2qd.onion</code>
+```akeyxc6hie26nlfylwiuyuf3a4tdwt4os7wiz3fsafijpvbgrkrzx2qd.onion```
 
 It has a minimal configuration:
 
-<code>
+```
 # relay
 OutboundBindAddress 199.58.80.38
 BandwidthRate 256 KB
@@ -40,16 +40,16 @@ DisableDebuggerAttachment 0
 # down the following value. When set lower, tor pushes the value up to 10mins
 # so it seems to be the lower bound.
 RendPostPeriod 10 minutes
-</code>
+```
 
 Then a hidden service key is stored in `/var/lib/tor/hidden_irc` for the v2 onion service and in `/var/lib/tor/hidden_irc_v3` for the v3 onion service. This is configured by Puppet on che in `/root/puppet/manifests/site.pp` (not the v3 onion service).
 Currently (2017-Sep-28) the onion service runs on chat1.koumbit
 
-h2. Security considerations
+## Security considerations
 
 The IP addresses are specified because otherwise tor users would be able to brute-force search the services password. Note that it is *still* possible for that brute-force searching to happen because the ExitPolicy is set to `accept private...` which allows a determined attacker to build his own circuit to connect to localhost here, even if the Hidden Service doesn't allow it explicitely. But at least it's somewhat hidden.
 
-h2. Possibility of failover setup
+## Possibility of failover setup
 
 This was setup on 2018-02-11 by LeLutin. We need to test that other nodes are picking up the HS when tor is out cold for 10mins. If this works out well then this section will be adjusted to explain how things work instead of how they *might be* working.
 
diff --git a/webchat.md b/webchat.md
index f9ab6653199946d8e6bb831ab567a12a44bca5c6..94eadbcf667422f87124e1eff71fbc07ce695918 100644
--- a/webchat.md
+++ b/webchat.md
@@ -32,10 +32,10 @@ https://thelounge.github.io/
 
 Installing on Debian jessie:
 
-<code>
+```
 sudo apt install npm nodejs-legacy
 npm -g install thelounge
-</code>
+```
 
 IRC anywhere
 --------------------