cmt: Write down how bans (and other things) might propagate

xep-xxxx-communities.md

@@ -3,7 +3,7 @@
 In different instant messaging services, users have the options to create collections of group chat venues that are logically linked
 together.
 
-This XEP is designed in a modular way, similar to [Mediated Information Exchange]. As such, this XEP only provided the basics for such
+This XEP is designed in a modular way, similar to [Mediated Information Exchange](https://xmpp.org/extensions/xep-0369.html). As such, this XEP only provided the basics for such
 groupings.
 
 ## Design Requirements
@@ -13,12 +13,36 @@ To aid adoption, the following requirements are considered while creating this X
 - Basic communities, i.e. grouped links to other JIDs with additional metadata, should work without server support
 - The protocol should be extensible for future evolution
 
-## Basics
+## Discovery
 
-A community in XMPP is identified by a JID that "owns" the community. This may be a bare JID or a server's JID. This JID must provide
+A community in XMPP is identified by a JID that "owns" the community. This may be a bare JID or a server"s JID. This JID must provide
-a [PubSub](https://xmpp.org/extensions/xep-0060.html) service on which the community's metadata is stored. This XEP proposes a couple of basic nodes, but other XEPs may extend
+a [PubSub](https://xmpp.org/extensions/xep-0060.html) service on which the community"s metadata is stored. This XEP proposes a couple of basic nodes, but other XEPs may extend
 this set and provide custom extensions.
 
+Whether a JID hosts a community is discovery by using a [Service Discovery](https://xmpp.org/extensions/xep-0030.html) items query:
+
+```xml
+<iq type="get"
+    to="community.example.org"
+    id="nodes1">
+  <query xmlns="http://jabber.org/protocol/disco#items"/>
+</iq>
+```
+
+The response MUST contain at least the `proto:urn:xmpp:community:0:info` node:
+
+```xml
+<iq type="result"
+    from="community.example.org"
+    id="nodes1">
+  <query xmlns="http://jabber.org/protocol/disco#items">
+    <item jid="community.example.org" node="proto:urn:xmpp:community:0:info" />
+  </query>
+</iq>
+```
+
+## Basics
+
 A community may be either public, meaning that anyone who knows the JID may join and query information about, or private, meaning that users
 wishing to join MUST be added by an administrator of the community. To accomplish this, public communities SHOULD set all their [PubSub](#) nodes
 to have an access model of "open", while private communities SHOULD set all of their nodes to "whitelist". A future XEP may define a way for
@@ -26,7 +50,7 @@ administrators to pre-authenticate users such that "invite URLs" to users.
 
 ### Description
 
-A community's information is described by a `<information />` element containing information about the community.
+A community"s information is described by a `<information />` element containing information about the community.
 
 ```xml
 <information xmlns="proto:urn:xmpp:community:0">
@@ -116,6 +140,82 @@ have to.
 </iq>
 ```
 
+## State Synchronization (Maybe new XEP?)
+
+There may be some state that should be synchronized across different channels, like ban lists, ACLs, hats, and so on. To accomplish this, XEPs may define
+new [PubSub](#) nodes that supporting channels within a community should subscribe to. Upon receiving a [PubSub](#) notification, the channels should
+react appropriately in regard to the payload.
+
+Care must be taken when storing bare or full JIDs in these [PubSub](#) nodes as to not leaking them. Thus, The recommendations of
+[Persistent Storage of Private Data via PubSub](https://xmpp.org/extensions/xep-0223.html) apply.
+
+### Linking
+
+Each channel must be configured to listen to [PubSub](#) events for every bit of synchronized state it cares about. The actual mechanism for it is out of scope,
+but for MUC, it may include a field in the configuration data form that refers to the community's JID.
+
+Example:
+
+```xml
+<iq from='crone1@shakespeare.lit/desktop'
+    id='create2'
+    to='coven@chat.shakespeare.lit'
+    type='set'>
+  <query xmlns='http://jabber.org/protocol/muc#owner'>
+    <x xmlns='jabber:x:data' type='submit'>
+      <field var='FORM_TYPE'>
+        <value>http://jabber.org/protocol/muc#roomconfig</value>
+      </field>
+      <field var='muc#community_link'>
+        <value>community.example.org</value>
+      </field>
+    </x>
+  </query>
+</iq>
+```
+
+### Banning
+
+Every channel inside a space that supports banning users, should be configured to subscribe to the `proto:urn:xmpp:community:0:ban` [PubSub](#) node. When a JID is put there,
+the supporting channels will be notified of the new ban and SHOULD apply it locally. This node MUST be configured with an access model of whitelist such that only administrators
+can see the bare JIDs of banned users.
+
+Banning a JID:
+
+```xml
+<iq type="set" to="community.example.org">
+  <pubsub xmlns="http://jabber.org/protocol/pubsub">
+    <publish node="proto:urn:xmpp:community:0:ban">
+      <item id="malicious-user@example.org" />
+    </publish>
+  </pubsub>
+</iq>
+```
+
+### Power Levels
+
+Every channel inside a space that supports power levels, like "Moderator", "Admin", and so on, should subscribe to the `proto:urn:xmpp:community:0:power` [PubSub](#) node. Each item in it
+describes a bare JID and its power level. When a notification is received, supporting channels SHOULD keep their internal power levels in sync with the payload.
+
+Making a JID an administrator:
+
+```xml
+<iq type="set" to="community.example.org">
+  <pubsub xmlns="http://jabber.org/protocol/pubsub">
+    <publish node="proto:urn:xmpp:community:0:power">
+      <item id="admin@example.org">
+        <power xmlns="proto:urn:xmpp:community:0:power" level="admin" />
+      </item>
+    </publish>
+  </pubsub>
+</iq>
+```
+
+# Notes
+
+- Using just this XEP, one can implement Gajim-like workspaces: Create a private community on your own bare JID and create a channel group per workspace.
+  - For pinning, each pinned `<channel />` could get a `<pinned />` child that indicates that it is pinned. The pinned items could then either have a different sorting or the same.
+
 # Info
 
 | Key | Value |