nip29: clarify group relay migration and forks.

29.md

@@ -14,11 +14,37 @@ There is no way to create a group, what happens is just that relays (most likely
 
 Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms -- still using the same _id_ -- across different relays.
 
+## Group identity, migration and forking
+
+A group is held together by two things: the group _id_ and the relay that currently enforces access rules over that _id_ on behalf of one or more group owners or admins. Because enforcement is tied to a specific relay, the group is only as durable as that relay's willingness and ability to keep hosting it.
+
+### Moving a group to another relay
+
+If the relay hosting a group becomes unresponsive, goes offline permanently, or simply becomes untrustworthy, the group can be migrated by copying the existing events to a different relay, as long as that new relay agrees to receive the old group and to continue enforcing the same rules and acknowledging the same admins.
+
+### Forking a group
+
+Another situation in which it might be desirable to move a relay to a different group is that of a disagreement between members of the original group.
+
+A dissident faction within a group can take the group's history to a different relay that agrees to _change_ the rules of that group and assign admin powers to a different set of users. This is a group _fork_: the new relay keeps the same _id_ but enforces a different set of moderation policies and a different admin roster than the original relay.
+
+Forks are not bugs. It's a feature of this NIP that the same _id_ can simultaneously identify different communities with different governance, hosted by different relays, each with their own `kind:39000` metadata event, their own `kind:39001` admin list and their own message history.
+
+### Detecting migrations and forks
+
+In order to check whether a group has migrated or whether a fork exists, clients SHOULD periodically -- and MUST, if their primary relay for a group is offline or unreachable -- look at the `kind:10009` event of the group's admins and of trusted friends. The pubkeys of the admins of the groups the user is in SHOULD be cached locally so this check can be performed even when the original relay is down.
+
+If a `kind:10009` entry for a group now points to a different relay hint than the one the client was previously using, the client SHOULD notify the user that the group may have moved or been forked, and offer to fetch the group's events from the new relay and, if the user wishes, to migrate their participation to that relay as well, updating the current user's `kind:10009` in the process.
+
+### Replicating a group for resilience
+
+Groups that do not want to lose history in case their primary relay goes down SHOULD set up a live backup/replica of all of the group's events on a second relay. The replica relay does not need to enforce any moderation rules of its own -- it exists only to preserve the event history so that, if the primary relay disappears, a new authoritative relay can be chosen and the historical events copied over from the replica.
+
 ## Relay-generated events
 
 Relays are supposed to generate the events that describe group metadata and group admins. These are _addressable_ events signed by the relay keypair directly, with the group _id_ as the `d` tag.
 
-## Group identifier
+## Group referencing
 
 A group may be identified by a `naddr1...` code to its `kind:39000` metadata event, with the public key set to the relay `self` public key, the `d` identifier set to the group id, the kind set to `39000` and a relay hint to the relay that is hosting the group.