Typographic fixes around double quotes.

2 files changed, 16 insertions, 16 deletions

diff --git a/wiki/gossamer/index.md b/wiki/gossamer/index.md
index ec9811e..7964d13 100644
--- a/wiki/gossamer/index.md
+++ b/wiki/gossamer/index.md
@@ -29,7 +29,7 @@ mistakes, not merely different mistakes, and certainly not more mistakes.
 
 The following is loosely inspired by [Rumor
 Monger](http://www.mememotes.com/meme_motes/2005/02/rumor_monger.html), at
-"whole world" scale.
+“whole world” scale.
 
 ## Design Goals
 
@@ -141,13 +141,13 @@ legitimate.
 
 Gossamer maintains relationships between identities to allow users to
 _verify_ the identities of one another, and to publish attestations of that
-to other Gossamer nodes. From this, Gossamer can recover much of GPG's "web
-of trust".
+to other Gossamer nodes. From this, Gossamer can recover much of GPG's “web
+of trust.”
 
 **TODO**: revocation of identities, revocation of verifications. Both are
 important; novice users are likely to verify people poorly, and there should
-be a recovery path less drastic than GPG's "you swore it, you're stuck with
-it" model.
+be a recovery path less drastic than GPG's “you swore it, you're stuck with
+it” model.
 
 Gossamer encourages users to create additional identities as needed to, for
 example, support the separation of work and home conversations, or to provide
@@ -181,7 +181,7 @@ the same identity.
 WON'T**. Identity keys protect the user's Gossamer identity, but they _also_
 protect the user's private messages (see below) and other potentially
 identifying data. The export format must be designed to be as resilient as
-possible, and Gossamer's software must take care to ensure that "used"
+possible, and Gossamer's software must take care to ensure that “used”
 identity files are _automatically_ destroyed safely wherever possible and to
 discourage users from following practices that weaken their own safety
 unknowingly.
@@ -236,7 +236,7 @@ clear. The author's bare identity is included in the encrypted part of the
 message, to allow the intended recipient to identify the sender.
 
 **TODO**: sign-then-encrypt, or encrypt-then-sign? If sign-then-encrypt, are
-private messages exempted from the "drop broken messages" rule above?
+private messages exempted from the “drop broken messages” rule above?
 
 ## Following Users
 
@@ -304,7 +304,7 @@ three or more identities in this database, will automatically be filtered out
 from display. (Additionally, transitively-blocked users will automatically be
 added to the block database. Blocking is contagious.) (**TODO**: should
 Gossamer _drop_ blocked messages? How does that interact with the inevitable
-"shared blocklist" systems that arise in any social network?)
+“shared blocklist” systems that arise in any social network?)
 
 As with the follow list, the block database is encrypted using the node's
 identities.
@@ -328,12 +328,12 @@ Gossamer bootstraps its network using a number of paths:
 * Gossamer nodes in the same broadcast domain discover one another using UDP
   broadcasts as well as Bonjour/mDNS.
 
-* Gossamer can generate _locator_ strings, which can be shared "out of band"
+* Gossamer can generate _locator_ strings, which can be shared “out of band”
   via email, SMS messages, Twitter, graffiti, etc.
 
 * Gossamer nodes share knowledge of nodes whenever they exchange messages, to
   allow the Gossamer network to recover from lost nodes and to permit nodes
-  to remain on the network as "known" nodes are lost to outages and entropy.
+  to remain on the network as “known” nodes are lost to outages and entropy.
 
 ### Locators
 
@@ -357,7 +357,7 @@ the identity list.)
 
 ### Gossip
 
-Each Gossamer node maintains a pair of "freshness" databases, associating
+Each Gossamer node maintains a pair of “freshness” databases, associating
 some information with a freshness score (expressed as an integer). One
 freshness database holds the addresses of known Gossamer nodes, and another
 holds Gossamer messages.
@@ -365,14 +365,14 @@ holds Gossamer messages.
 Whenever two Gossamer nodes interact, each sends the other a Gossamer node
 from its current node database, and a message from its message database. When
 selecting an item to send for either category, Gossamer uses a random
-selection that weights towards items with a higher "freshness" score.
+selection that weights towards items with a higher “freshness” score.
 (**TODO**: how?)
 
 When sending a fact, if the receiving node already knows the fact, both nodes
 decrement that fact's freshness by one. If the receiving node _does not_
 already know the fact, the sending node leaves its freshness unaltered, and
 the receiving node sets its freshness to the freshest possible value. This
-system encourages nodes to exchange "fresh" facts, then cease exchanging them
+system encourages nodes to exchange “fresh” facts, then cease exchanging them
 as the network becomes aware of them.
 
 During each exchange, Gossamer nodes send each other one Gossamer node
diff --git a/wiki/gossamer/mistakes.md b/wiki/gossamer/mistakes.md
index 110fe29..23b731b 100644
--- a/wiki/gossamer/mistakes.md
+++ b/wiki/gossamer/mistakes.md
@@ -40,13 +40,13 @@ Gossamer's network protocol converges towards a total graph, where every node
 knows how to connect to every other node, and new information (new posts)
 rapidly push out to every single node.
 
-If you've ever been privy to the Twitter "firehose" feed, you'll understand
+If you've ever been privy to the Twitter “firehose” feed, you'll understand
 why this is a drastic mistake. Even a moderately successful social network
 sees on the order of millions of messages a day. Delivering _all_ of this
 directly to _every_ node _all_ of the time would rapidly drown users in
 bandwidth charges and render their internet connections completely unusable.
 
-Gossamer's design also has no concept of "quiet" periods: every fifteen to
+Gossamer's design also has no concept of “quiet” periods: every fifteen to
 thirty seconds, rain or shine, every node is supposed to wake up and exchange
 data with some other node, regardless of how long it's been since either node
 in the exchange has seen new data. This very effectively ensures that
@@ -74,7 +74,7 @@ Gossamer node immediately forwards it to at least one other node to inject it
 into the network. This makes unencrypted Gossamer relatively vulnerable to
 traffic analysis for correlating Gossamer identities with human beings.
 
-Someone at a network "pinch point" -- an ISP, or a coffee shop wifi router --
+Someone at a network “pinch point” -- an ISP, or a coffee shop wifi router --
 can monitor Gossamer traffic entering and exiting nodes on their network and
 easily identify which nodes originated which messages, and thus which nodes
 have access to which identities. This seriously compromises the effectiveness