Rewrite issues.

proposals/4104-auth-lock-soft-failure-be-gone.md

@@ -72,7 +72,7 @@ Considering the event's `auth_events`:
 
 ## Potential issues
 
-### Conflicting auth-lock events
+### Multiple auth-lock events
 
 Imagine that there are two admins in a room, Alice and Bob.
 Imagine that there is a malicious user Chelsea.
@@ -83,46 +83,102 @@ Alice and Bob both issue auth_lock events for Chelsea's prior membership.
 Alice's `extremities` field includes `B`, but excludes `C`.
 Bob's `extremities` field includes `C`.
 
+#### Solution
+
 The receiving server must combine the `extremities` from both events
 such that the canonical history becomes C -> B -> A.
+This is already explicitly written within the authorization rules
+in this MSC.
+
+### Diverging `extremities`
+
+Imagine Bob's server receives an `m.auth_lock` event and Bob's server
+has authorized events referencing the `locked_event_id` that are not
+present within any relevant `m.auth_lock`'s `extremities`.
+Bob's server must decide what to do with the events it has already
+authorized.
+
+This is a problem that occurs in the following scenarios:
+
+#### Scenario A: Alice deliberately encodes less `extremities` than Bob has
+Alice issues an `m.auth_lock` to deliberately encode less or no
+extremities, in an attempt permanently to diverge Bob's DAG.
+Joining user David would then also not be able to see a large portion
+of the history that Bob can, because it wouldn't be authorized in
+David's DAG when David backfills.
+
+#### Scenario B: Alice issues a lock quickly after changing an auth event
+
+Imagine that Alice issues an `m.room.power_levels` event P.
+Alice revises this event so that it becomes P'.
+Alice issues an auth_lock for P, Lock-P.
+Imagine that Alice receives an event B from Bob that references P.
+Alice and every other server with Lock-P is forced to reject event B.
+
+#### Scenario C: Bob's events are mixed with Chelsea's
+
+Chelsea has sent `X -> A` to Alice, but `Y -> A` to Bob.
+Bob has then appended `B -> Y -> A` and in turn Chelsea
+has appended `Z -> B -> Y -> A` and sent `Z` to Bob.
 
-### Issuing `m.auth_lock` to deliberately encode less or no extremities
+Alice has banned Chelsea and locked Chelsea's prior membership.
+Only now has Bob received this `m.auth_lock` event, and it only
+contains the extremity `X`.
+
+Alice can get `B` if Bob sends it to her,
+but new joiner David will probably be unable to by backfilling `B`,
+at least if David's server doesn't have special code to account
+for the connected events being rejected.
 
 #### Effects on participating servers 
 
-We counteract this issue by requiring that servers maintain all
-existing `extremities` and their `prev_events`, regardless of
-whether they are missing from the `extremities` field of
-an `m.auth_lock` event.
+Servers are required to maintain all their existing `extremities`
+and their `prev_events`, regardless of whether they are missing from
+the `extremities` field of any `m.auth_lock` event.
+
+These servers should still incorporate these diverged `extremities`
+into `prev_events` so that they can be discovered and repaired later.
 
 #### Effects on joining servers
 
 Joining servers will no longer be able to authorize large parts of the
 room's history.
 
-### Split history for unprivileged users on unprivileged servers
+#### Solution A: Dedicated API for showing diverged events to room admins
 
-Imagine that Alice issues an `m.room.power_levels` event P.
-Alice revises this event so that it becomes P'.
-Alice issues an auth_lock for P, Lock-P.
-Imagine that Alice receives an event B from Bob that references P.
-Alice is forced to reject event B.
+A room administrator could be made aware of all the extremities that
+are diverged. This can be done because a server can detect when
+authorized events contain references to unauthorized events
+within `prev_events` of authorized events in the DAG.
 
-#### Resolution
+A room administrator can then preview the effects of incorporating
+diverged extremities and make a decision to do so via the
+`extremities` field of `m.auth_lock`.
 
-Bob receives Lock-P, and notices that B is absent from the chain
-specified in Lock-P's `extremities`.
+#### Solution B: Room administrators on other servers issue their own `m.auth_lock`
+
+Room admins residing on different servers with diverged extremities
+can issue their own `m.auth_lock` event to include diverged extremities.
+When this event is received by other servers, the diverged extremities
+can be authorized and the DAG will converge again.
+
+#### Solution C: Unprivileged users propose changes to the `extremities` of `m.auth_lock`
+
+Participants in the room can propose changes to the `extremities`
+contained within `m.auth_lock` via a dedicated event. Room administrators
+can then review the effects and merge them.
+
+#### Solution D: Recrafting PDUs
+
+Take scenario B. Bob receives Lock-P, and notices that B is absent
+from the chain specified in Lock-P's `extremities`.
 
 We would need a new MSC for bob to resend B as B' such that servers who
 have accepted B would recognise B' to be a duplicate that references
 more recent authorization events.
 
-### Redaction of `m.auth_lock`
-
-We probably do want the lock to be redactable.
-But how can you be sure that you're not opening Pandora's box by
-allowing hidden malicious events residing on participating servers
-to suddenly be incorporated into the DAG?
+This would allow Alice to see `B` in Scenario C. But it wouldn't
+allow Alice to redact `Z` or `Y`, which Bob my find harmful.
 
 ### Locking all current auth events