As described in the *[Steemit 2017 Roadmap](https://steem.io/2017roadmap.pdf)*:
> We believe that high-quality content and communities of content producers and their
> We believe that high-quality content and communities of content producers and their
audiences are the primary driver of growth of the steemit.com site, and in turn the wider
audiences are the primary driver of growth of the steemit.com site, and in turn the wider
...
@@ -31,17 +27,20 @@ Ratio (SNR) for a quality content experience free of spam and low-value comments
...
@@ -31,17 +27,20 @@ Ratio (SNR) for a quality content experience free of spam and low-value comments
whilst simultaneously preventing any type of censorship.
whilst simultaneously preventing any type of censorship.
> It is our hope and design goal for our services (all of which are published with full source code
> It is our hope and design goal for our services (all of which are published with full source code
for easy deployment by anyone) to be replicated by others, displaying content according to
> for easy deployment by anyone) to be replicated by others, displaying content according to
the wishes and whims of each individual website operator, giving readers ultimate choice
> the wishes and whims of each individual website operator, giving readers ultimate choice
over the set of moderation opinions they wish to heed.
> over the set of moderation opinions they wish to heed.
>
> *[source](https://steem.io/2017roadmap.pdf)*
Any user can create a new community, and each becomes a tuned 'lens' into the blockchain. Currently, there is one large window into the Steem blockchain and that is the global namespace as shown on Steemit.com. This is not ideal because everyone effectively has to share a single sandbox while having different goals as to what they want to see and what they want to build.
Today, most Steem frontends rely on the global tags system for organization. In this sense Steem has many "communities" already but they are entirely informal; there is no ownership and no ability to formally organize. Tag usage standards are not possible to enforce, and users have different goals as to what they want to see and what sort of communities they want each tag to embody.
Many members want to see long-form, original content while many others just want to share links and snippets. We have a diverse set of sub-communities though they share a global tag namespace with no ownership and little ability to formally organize.
Hive communities add a governance layer which allows users to organize around a set of values, and gives them the power to do so effectively. It introduces a new system of moderation which is not dependent on users' steem power. By making it easier to organize, this system can be far more effective at connecting creators and curators. Curators will be attracted to communities which are well-organized: focused, high-quality, low-noise. Making it easier to find the highest quality content will make it easier to reward high quality content.
The goal of the community feature is to empower users to create tighter groups and focus on what's important to them. For instance:
Many people want to see long-form, original content while many others just want to share links and snippets. The goal of the community feature is to empower users to create tighter groups and focus on what's important to them. Use cases for communities may include:
@@ -49,55 +48,126 @@ The goal of the community feature is to empower users to create tighter groups a
...
@@ -49,55 +48,126 @@ The goal of the community feature is to empower users to create tighter groups a
- funny youtube videos
- funny youtube videos
- etc
- etc
Posts either "belong" to a single community, or are in the user's own blog (not in a community).
## Overview
#### Community Types
All communities and posts are viewable and readable by all, and there is a governance mechanism which can affect visibility and prioritization of content for the purpose of decreasing noise and increasing positive interactions (however a community wishes to define it) and discourse. By default, communities are open for all to post and comment ("topics"). However, an organization may create a restricted community ("journal") for official updates: only members of the organization would be able to post updates, but anyone can comment. Alternatively, a professional group or local community ("council") may choose to limit all posting and commenting to approved members (perhaps those they verify independently).
1.**Topic**: anyone can post or comment
2.**Journal**: guests can comment but not post. only members can post.
3.**Council**: only members can post or comment
#### User Roles Overview
1.**Owner**: can assign admins.
2.**Admin**: can edit admin settings, display settings, and assign mods.
3.**Mod**: can mute posts/users, add/remove members, pin posts, set user titles.
4.**Member**: in restricted (journal/council) communities, an approved member.
5.**Guest**: can post/comment in topics and comment in journals.
#### User Actions
**Owner** has the ability to:
-**set admins**: assign or revoke admin priviledges
**Admins** have the ability to:
## Specifications
-**set moderators**: grant or revoke mod priviledges
-**set payout split**: control reward sharing destinations/percentages
-**set display settings**: control the look and feel of community home pages
Communities are created by designating an account as a community. Each community has a set of admins and moderators who maintain it and control settings over the look and feel.
**Moderators** have the ability to:
### Member Types
-**set user roles:** member, guest, muted
-**set user titles**: ability to add a label for specific users, designating role or status
-**mute posts**: prevents the post from being shown in the UI (until unmuted)
-**pin posts**: ability for specific posts to always show at the top of the community feed
1. Owner: holder of the community account's private keys. Assigns admins.
**Members** have the ability to:
2. Admin: can edit admins and mods. Has mod powers.
3. Mod: can remove posts, block users, add/remove contributors
4. Contributor: in closed communities, an approved poster.
5. Guest: a poster in a public community and a commenter in a restricted community
-**in an topic**: N/A (no special abilities)
-**in a journal: post** (where guests can only comment)
-**in a council: post and comment** (where guests cannot)
### Community Types
**Guests** have the ability to:
1. Public: anyone can post a topic
-**post in a topic**: as long as they are not muted
2. Restricted: only mods and approved members can post topics
-**comment in a topic or journal**: as long as they are not muted
-**flag a post**: adds an item and a note to the community's moderation queue for review
-**follow a community**: to customize their feed with communities they care about
Either type of community can be "followed" by any user.
## Registration
### Community parameters (editable by mods)
##### NCI: Numerical Community Identifier
Admin settings
Communities are registered by creating an on-chain account which conforms to `/^hive-[1-3]\d{4,6}$/`, with the first digit signifying the *type*. Type mappings are outlined in a later section. Thus the valid range is `hive-10000` to `hive-3999999` for a total of 1M possible communities per type. This ensures the core protocol has stable ids for linking data without introducing a naming system.
-`type`
##### Custom URLs
-`public`
-`open-comment`: guests can comment but not post
-`restricted`: only approved members can post/comment
-`payment_split`: % of rewards which go to the community account. implement in 1.0, don't enforce until 1.1
-`admins`
Mod settings
Name registration, particularly in decentralized systems, is far from trivial. The ideal properties for registering community URLs include:
-`name`: the name of this community (32 chars)
1. ability to claim a custom URL based on a subjective capacity to lead that community
2. ability to reassign a URL which has ceased activity (due to lost key or inactivity)
3. ability to reassign a URL due to trademark issues
4. decentralization: no central entity is controlling registration or collecting payments
Name reassignments result unpredictable and/or complex behavior, which is why internal identifiers are not human-readable. This approach does not preclude anyone from developing a standardized naming system. Such a system may be objective and automated or subjective and voting driven. For subjective approaches, starting with just a numerical id is particularly useful as it allows a community to demonstrate its prowess before making a case to claim a specific human-readable identifier.
## Considerations
- Operations such as role grants and mutes are not retroactive.
- This is to allow for consistent state among services which can also be replayed independently, as well as for simplicity of implementation. If it is needed to batch-mute old posts, this can be still be accomplished by issuing batch `mutePost` operations.
- Example: If a user is muted, the state of their previous posts is not changed. If the user attempts to post in a community during this period (e.g. from a UI which does not properly enforce roles), their posts will be marked "invalid" since they did not have the correct priviledge at the time. Likewise, if they are unmuted, any of these "invalid" posts remain so.
- Example: payout split changes cannot be retroactive, otherwise previously valid posts may be considered invalid.
- A post's `community` cannot be changed after the post is created. This avoids a host of edge cases.
- A community can only have one account named as the owner.
- Each user in a community is assigned, at most, 1 role (admin, mod, member, guest, muted).
- Anybody could be promoted to member, mod, or admin of any community, but they will be shown as inactive unless they are subscribed to the community.
## Community Metadata
##### Editable by Admins - Core Settings
Core settings which will influence community logic and validation rules.
-`reward_share`: (v1.5) dictionary mapping `account` to `percent`
- specifies required minimum beneficiary amount per post for it to be considered valid
- can be blank or contain up to 8 entries
##### Editable by Admins - Display Settings
Can be stored as a JSON dictionary.
-`name`: the display name of this community (32 chars)
-`about`: short blurb about this community (512 chars)
-`about`: short blurb about this community (512 chars)
-`description`: a blob of markdown to describe purpose, enumerate rules, etc. (5000 chars)
-`description`: a blob of markdown to describe purpose, enumerate rules, etc. (5000 chars)
-`feed_display`: specify graphical layout in communities
## Registration
Register an onchain account name which conforms to `/hive-[1-3]\d{4,6}$/`. This is the owner account. From this account, submit a `setRole` command to set the first admin.
- Topics: the leading digit must be `1`
- Journals: the leading digit must be `2`
- Councils: the leading digit must be `3`
## Operations
## Operations
Communities are not part of blockchain consensus, so all actions make use of standard operations. Standalone services will monitor the blockchain for relevant ops to build and maintain state.
Communities are not part of blockchain consensus, so all operations take the form of `custom_json` operations which are to be monitored and validated by separate services to build and maintain state.
The standard format for `custom_json` ops:
The standard format for `custom_json` ops:
...
@@ -105,7 +175,7 @@ The standard format for `custom_json` ops:
...
@@ -105,7 +175,7 @@ The standard format for `custom_json` ops:
{
{
required_auths: [],
required_auths: [],
required_posting_auths: [<account>],
required_posting_auths: [<account>],
id: "com.steemit.community",
id: "hive.community",
json: [
json: [
<action>,
<action>,
{
{
...
@@ -121,65 +191,28 @@ The standard format for `custom_json` ops:
...
@@ -121,65 +191,28 @@ The standard format for `custom_json` ops:
-`<community>` required parameter for all ops and names a valid community.
-`<community>` required parameter for all ops and names a valid community.
-`<params*>` is any number of other parameters for the action being performed
-`<params*>` is any number of other parameters for the action being performed
### Admin actions
### Setting Roles
Must be submitted by an *admin* or the community *owner* account.
#### Designate account as a community
```
```
["create", {
["setRole", {
"community": <account>,
"community": <community>,
"type": <type>,
"account": <account>,
"admins": [<admins>]
"role": admin|mod|member|none|muted
"notes": <comment>
}]
}]
```
```
- type is either `restricted` or `public`
*Owner* can set any role.
- must name at least 1 valid admin
#### Add admin
```
["addAdmins", {
"community": <community>,
"accounts": [ <account>, ... ]
}]
```
#### Remove admin
```
["removeAdmins", {
"community": <community>,
"accounts": [ <account>, ... ]
}]
```
- there must remain at least 1 admin at all times
#### Add moderators
```
["addMods", {
"community": <community>,
"accounts": [ <account>, ... ]
}]
```
#### Remove moderators
*Admins* can set the role of any account to any level below `admin`, except for other *Admins*.
```
*Mods* can set the role of any account to any level below `mod`, except for other *Mods*.
["removeMods", {
"community": <community>,
"accounts": [ <account>, ... ]
}]
```
### Admin Operations
### Moderator actions
In addition to editing user roles (e.g. appointing mods), admins can define the reward share and control display settings.
#### Update settings
#### Update display settings
```
```
["updateSettings", {
["updateSettings", {
...
@@ -188,48 +221,20 @@ Must be submitted by an *admin* or the community *owner* account.
...
@@ -188,48 +221,20 @@ Must be submitted by an *admin* or the community *owner* account.
}]
}]
```
```
Valid keys are `name`, `about`, `description`, `language`, `nsfw`.
Valid keys are `name`, `about`, `description`, `language`, `nsfw`, `flag_text`.
#### Add approved posters
In restricted communities, gives topic-creation permission to the named accounts.
```
["addPosters", {
"community": <community>,
"accounts": [ <account>, ... ]
}]
```
#### Remove approved posters
```
["removePosters", {
"community": <community>,
"accounts": [ <account>, ... ]
}]
```
#### Mute user
#### Set reward share (v1.5)
Muting a user prevents their topics and comments from being shown in the community.
```
```
["muteUser", {
["setRewardShare", {
"community": <community>,
"community": <community>,
"account": <account>
"reward_share": { <account1>: <percent1>, ... }
}]
}]
```
```
#### Unmute user
### Moderator Operations
```
In addition to editing user roles (e.g., approving a member or muting a user), mods have the ability to set user titles, mute posts, and pin posts.
["unmuteUser", {
"community": <community>,
"account": <account>
}]
```
#### Set user title
#### Set user title
...
@@ -241,7 +246,7 @@ Muting a user prevents their topics and comments from being shown in the communi
...
@@ -241,7 +246,7 @@ Muting a user prevents their topics and comments from being shown in the communi
}]
}]
```
```
#### Mute a post
#### Mute/unmute a post
Can be a topic or a comment.
Can be a topic or a comment.
...
@@ -254,8 +259,6 @@ Can be a topic or a comment.
...
@@ -254,8 +259,6 @@ Can be a topic or a comment.
}]
}]
```
```
#### Unmute a post
```
```
["unmutePost", {
["unmutePost", {
"community": <community>,
"community": <community>,
...
@@ -265,6 +268,7 @@ Can be a topic or a comment.
...
@@ -265,6 +268,7 @@ Can be a topic or a comment.
}]
}]
```
```
Any posts muted for spam should contain simply the string `spam` in the `notes` field. This standardized label will help train automated spam detection.
#### Pin/unpin a post
#### Pin/unpin a post
...
@@ -287,12 +291,23 @@ Stickies a post to the top of the community homepage. If multiple posts are stic
...
@@ -287,12 +291,23 @@ Stickies a post to the top of the community homepage. If multiple posts are stic
}]
}]
```
```
### Public operations
### Guest Operations
#### Un/subscribe to a community
#### Un/Following a community
Allows a user to signify which communities they want shown on their personal trending feed and to be shown in their navigation menu.
Following and unfollowing communities is performed identically to following and unfollowing any other user.
```
["subscribe", {
"community": <community>
}]
```
```
["unsubscribe", {
"community": <community>
}]
```
#### Flag a post
#### Flag a post
...
@@ -307,13 +322,13 @@ Places a post in the review queue. It's up to the community to define what const
...
@@ -307,13 +322,13 @@ Places a post in the review queue. It's up to the community to define what const
}]
}]
```
```
### Posting in a community
#### Posting in a community
To mark a post as belonging to a community, set the `community` key in `json_metadata`. Do not use an `@` prefix.
To mark a post as belonging to a community, set the `community` key in `json_metadata`. Do not use an `@` prefix.
```
```
{
{
"community": "steemit",
"community": "hive-192921",
"app": "steemit/0.1",
"app": "steemit/0.1",
"format": "html",
"format": "html",
"tags": ["steemit", "steem"],
"tags": ["steemit", "steem"],
...
@@ -321,37 +336,50 @@ To mark a post as belonging to a community, set the `community` key in `json_met
...
@@ -321,37 +336,50 @@ To mark a post as belonging to a community, set the `community` key in `json_met
}
}
```
```
If a post is edited to name a different community, this change will be ignored. If a post is posted "into" a community that the user does not have permission to post into, the json will be interpreted as if the "community" key does not exist, and the post will be posted onto the user's own blog.
If a post is edited to name a different community, this change will be ignored. If a post is posted "into" a community which does not exist, or one that the user does not have permission to post into, the json will be interpreted as if the "community" key does not exist, and the post will be posted onto the user's own blog.
