Compare commits
3 Commits
048c766ac7
...
master
| Author | SHA1 | Date | |
|---|---|---|---|
| 678eae1d9e | |||
| 61610fa678 | |||
| 6f8414f6a6 |
@@ -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 [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 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
|
||||
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 |
|
||||
|
||||
Reference in New Issue
Block a user