TBR docs: fix svgs, this time fo realz
Change-Id: Ie6d23f3d6cbb28bbe97f640b732db48b51e8ddc8
diff --git a/concepts/naming.md b/concepts/naming.md
index f865404..8f56589 100644
--- a/concepts/naming.md
+++ b/concepts/naming.md
@@ -39,7 +39,7 @@
`a/y/foo/bar`, `mount table a/y` must also be consulted, since it serves
mounts made below `y`.
-
+
The first element of a name that begins with `/` points to the mount table at
which to begin the resolution. For example, the name `/ns1.v.io:8101/a` starts
@@ -56,12 +56,12 @@
that is relative to `ns1.v.io:8101`, its root, and hence can resolve
`a`, `b`, `c`, `a/y`, and `a/z`.
-
+
In contrast, process `Client 2` with `ns2.v.io:8102` as its root can
resolve only `y` and `z`.
-
+
The advantage of using a relative namespace is that it can define a context.
For example, for debugging or testing one would set up the namespace to
@@ -85,7 +85,7 @@
difference with relative names is that we're assuming a "current directory" to
start from as opposed to providing it in the name.
-
+
User-supplied server code that implements RPCs also appears as names in mount
tables. In the diagram above `Server 1` and `Server 2` provide a server called
diff --git a/designdocs/authentication.md b/designdocs/authentication.md
index 024255d..27122e3 100644
--- a/designdocs/authentication.md
+++ b/designdocs/authentication.md
@@ -44,7 +44,7 @@
In this implementation, [NaCl/box] is used to establish an [authenticated-encryption]
channel based on an ECDH key exchange.
-
+
Where:
- `{foo}k` represents the message `foo` encrypted using the key `k`
- Channel bindings C1 and C2 at the Client and Server ends respectively are
diff --git a/designdocs/identity-service.md b/designdocs/identity-service.md
index d461395..1a73d97 100644
--- a/designdocs/identity-service.md
+++ b/designdocs/identity-service.md
@@ -90,7 +90,7 @@
for a blessing from the Vanadium Blessing Service. The following sequence
diagram lists the network requests involved in this process:
-
+
- Solid-line arrows represent HTTPS requests (except one HTTP to localhost).
- Dotted-line arrows represent Vanadium RPC requests.
diff --git a/tools/vanadium-chrome-extension.md b/tools/vanadium-chrome-extension.md
index 9ee139f..aca6bfe 100644
--- a/tools/vanadium-chrome-extension.md
+++ b/tools/vanadium-chrome-extension.md
@@ -30,7 +30,7 @@
extension sends messages back to the web app when those calls return, or when
an external device initiates a call to the JavaScript client.
-
+
Isolating the Vanadium libraries inside a NaCl plugin has the added benefit
that no JavaScript web app ever sees any private keys. All cryptographic
@@ -44,7 +44,7 @@
The following diagram depicts these components and the flow of messages between them.
-
+
When a web app makes an RPC to a device using the Vanadium JavaScript library,
a message is sent to the content script, which then forwards that message to
