docs: add explanations for isAppSender/isBroadcast across spec and shared state chapters

Author: hpk42

src-docs/shared_state/conflicts.md

@@ -29,6 +29,13 @@ both a Total Order of messages and a "single source of truth" can not be assumed
 Many webxdc applications are incapable of producing conflicts,
 either because they do not use the network communication APIs,
 or because any given data structure can only have one writer.
+Alternatively, an application can designate a "central" authority
+by checking [`webxdc.isAppSender`](../spec/selfAddr_and_selfName.html#isappsender)
+to identify whether it is running for the user who shared the app.
+This peer could then authoritatively resolve conflicts or coordinate state updates.
+However, developers should be aware that if the app depends entirely on the sender being online,
+the app's availability will be limited when the sender is offline.
+
 For example, many of the available [webxdc games](https://webxdc.org/apps/) offer a high-score table
 and how users scored will typically be reported back to the chat.
 Such a gaming app will simply post their user's highscore

src-docs/shared_state/crdts.md

@@ -148,6 +148,8 @@ While this behaviour can be very helpful for application developers,
 it may not free you entirely from having to think about network conditions.
 _Eventually-consistent_ application state should generally be treated as
 subjective, which can be a significant shift if you are used to having a server acting as an authority.
+While you can use [`webxdc.isAppSender`](../spec/selfAddr_and_selfName.html#isappsender) to nominate a peer
+(the app sender) to act as a kind of server, this introduces a dependency on that peer being online.
 That means that conditional behaviour that you'd usually treat as _yes_ and _no_,
 may instead behave more like _currently_ and _not yet_.
 

src-docs/shared_state/practical.md

@@ -473,6 +473,25 @@ As for the matter of duplicate ids in the `order` array,
 the rendering code which constructs the app's UI from this data
 could ignore repeated elements when iterating over them.
 
+## Centralized coordination
+
+While CRDTs are designed for peer-to-peer operation,
+you may sometimes want to designate one client as a "coordinator".
+By checking [`webxdc.isAppSender`](../spec/selfAddr_and_selfName.html#isappsender),
+an app can identify whether it is running for the peer
+that initially shared the app.
+This "sender" instance can then take on special roles,
+such as authoritatively resolving state conflicts,
+for example by letting the app sender's updates always win.
+
+However, use this model with care:
+if your app logic requires the sender to be online to function,
+it will be unusable whenever the sender is offline or has left the chat.
+One further complication occurs if the app sender
+has multiple devices running the app simultaneously,
+with each device possibly regarding itself as the central coordinator
+and producing conflicting application states.
+
 ## Learning more
 
 Many more examples can be found throughout

src-docs/spec/selfAddr_and_selfName.md

@@ -42,6 +42,10 @@ window.webxdc.isAppSender
 who initially shared the webxdc application in the chat.
 If it is `false`, the user is a receiver.
 
+This supports a common development model where a "central" app instance
+(the sender's) processes all updates and distributes the resulting state
+back to all peers.
+
 ## isBroadcast
 
 ```js
@@ -51,6 +55,12 @@ window.webxdc.isBroadcast
 `isBroadcast` is a boolean value that is `true` if the webxdc
 application is shared in a broadcast chat context.
 
+On some platforms, such as "broadcast channels," it is technically impossible
+for subscribers to discover or send updates to each other directly.
+In those cases, [updates](./sendUpdate.md) sent by a non-sender
+will only be seen by the app sender,
+who alone can distribute updates globally.
+
 
 ## Example using selfAddr and selfName
 

src-docs/spec/sendUpdate.md

@@ -4,9 +4,12 @@
 window.webxdc.sendUpdate(update, descr);
 ```
 
-Send an update to all peers.
+Send an update to peers.
+If `webxdc.isBroadcast` is false, the update is sent to all peers.
+If `webxdc.isBroadcast` is true and `webxdc.isAppSender` is false,
+the update is only sent to the app sender.
 
-All peers, including the sending one,
+All receiving peers, including the sending one,
 will receive the update by the callback given to [`setUpdateListener()`](./setUpdateListener.html).
 
 There are situations where the user cannot send messages to a chat,