apply @raulk's suggestions.

pubsub/README.md

@@ -148,23 +148,24 @@ and
 
 ## Message Identification
 
-To uniquely identify a message in a set of topics, a `message_id` is computed based on the message.
-This can be configured on the application layer, as `message_id_fn(*Message) => message_id`.
-A `message_id_fn` may conditionally call different `message_id_fn` implementations per topic (or group thereof).
+To uniquely identify a message in a set of topics (for de-duplication, tracking, scoring and other purposes), a `message_id` is calculated based on the message.
+How the calculated happens can be configured on the application layer by supplying a function `message_id_fn`, such that `message_id_fn(*Message) => message_id`.
 
-The message ID approach generally fits in two flavors:
+> [[ Implementation note ]]: At the time of writing this section, go-libp2p-pubsub (reference implementation of this spec) only allows configuring a single top-level `message_id_fn`. This function may, however, vary its behaviour based on the topic (contained inside its `*Message`) argument. Thus, it's feasible to implement a per-topic policy using branch selection control flow logic. go-libp2p-pubsub plans to push down the configuration of the `message_id_fn` to the topic level. Other implementations are encouraged to do the same.
+
+The message ID calculation approach generally fits in two flavors:
 - **origin-stamped** messaging: the combination of the `seqno` and `from` fields
   uniquely identifies a message based on the *author*.
-- **content-stamped** messaging: a message ID derived from the `data` field
+- **content-addressed** messaging: a message ID derived from the `data` field
   uniquely identifies a message based on the *data*.
 
-The default `message_id_fn` is origin-stamped, and defined as the string concatenation of `from` and `seqno`.
+**The default `message_id_fn` is origin-stamped,** and defined as the string concatenation of `from` and `seqno`.
 
 If fabricated collisions are not a concern, or difficult enough within the window the message is relevant in,
-a `message_id` based on a short digest of inputs may benefit performance.
+a `message_id` based on a short digest of inputs may benefit performance. Whichever the choice, it is crucial that **all peers** participating in a topic implement the same message ID calculation logic, or the topic may function suboptimally.
 
-Note that different specialized pubsub components, such as the 'timecache' used in the Go implementation,
-may use the `message_id` to key messages.
+Note that different specialized pubsub components, such as the 'timecache' used in the Go implementation, scoring functions or circuit-breakers 
+may use the `message_id` to key and track messages.
 
 It was also proposed in [#116](https://github.com/libp2p/specs/issues/116)
 to use a `message_hash`, however, it was noted:
@@ -172,7 +173,7 @@ to use a `message_hash`, however, it was noted:
 the peer won't be able to send identical messages (e.g. keepalives) within the
 timecache interval, as they will get rejected as duplicates.
 
-Some applications may not need keepalives, or choose to implement something more specific than a message hash. 
+Some applications may not need keepalives, or choose to implement something more specific than a message hash. In those cases where duplicate payloads are not desirable, a `content-based` message ID function may be more appropriate.
 
 ## Message Signing
 

pubsub/gossipsub/gossipsub-v1.1.md

@@ -139,7 +139,7 @@ message PeerInfo {
 ### Signature Policy
 
 The usage of the `signature`, `key`, `from`, and `seqno` fields in `Message` is now configurable.
-Initially this could be configured globally, however, because the policies are mutually incompatible, configuration on a per-topic basis will facilitate mixed protocols better.
+> [[ Implementation note ]]: At the time of writing this section, go-libp2p-pubsub (reference implementation of this spec) allows for configuring the signature policy at a global pubsub instance level. This needs to be pushed down to topic-level configuration. Other implementations are encouraged to support topic-level configuration, as the spec mandates.
 
 In the default origin-stamped messaging, the fields need to be strictly enforced:
 the `seqno` and `from` fields form the `message_id`, and should be verified to avoid `message_id` collisions.
@@ -152,7 +152,7 @@ revealing the relationship between `data` and `from`/`seqno`.
 In gossipsub v1.1, these fields are strictly present and verified, or completely omitted altogether:
 - `StrictSign`:
   - On the producing side:
-    - Build messages with the `signature`, `key` (`from` may be enough), `from` and `seqno` fields.
+    - Build messages with the `signature`, `key` (`from` may be enough for certain inlineable public key types), `from` and `seqno` fields.
   - On the consuming side:
     - Enforce the fields to be present, reject otherwise.
     - Propagate only if the fields are valid and signature can be verified, reject otherwise.
@@ -163,16 +163,16 @@ In gossipsub v1.1, these fields are strictly present and verified, or completely
   - On the consuming side:
     - Enforce the fields to be absent, reject otherwise.
     - Propagate only if the fields are absent, reject otherwise.
-  - A `message_id` function will not be able to use the above fields, and may instead rely on the `data` field.
+  - A `message_id` function will not be able to use the above fields, and should instead rely on the `data` field. A commonplace strategy is to calculate a hash.
 
-In gossipsub v1.0, a legacy "lax" signing policy could be configured, to not verify signatures except when present:
-- `LaxSign`: *Defined for completeness, insecure*. Also known as authoring but not verifying.
+In gossipsub v1.0, a legacy "lax" signing policy could be configured, to only verify signatures when present. For security reasons, this is strategy is discarded in subsequent versions, but MAY still be supported for backwards-compatibility. If so, its use should be discouraged through prominent deprecation warnings. These strategies will be entirely dropped in the future.
+- `LaxSign`: *this was never an original gossipsub 1.0 option, but it's defined here for completeness, and considered insecure*. Always sign, and verify incoming signatures, and but accept unsigned messages.
   - On the producing side:
     - Build messages with the `signature`, `key` (`from` may be enough), `from` and `seqno` fields.
   - On the consuming side:
     - `signature` may be absent, and not verified.
     - Verify `signature`, iff the `signature` is present, then reject if `signature` is invalid.
-- `LaxNoSign`: *Previous default for no-verification*
+- `LaxNoSign`: *Previous default for no-verification*. Do not sign nor origin-stamp, but verify incoming signatures, and accept unsigned messages.
   - On the producing side:
     - Build messages without the `signature`, `key`, `from` and `seqno` fields.
   - On the consuming side: