nexus-go — Communities
Communities are Blurt's governance and organization layer over the flat tag system: a named group accounts can post into, with owners, moderators, members, and per-community moderation. nexus-go implements them by indexing on-chain custom_json operations (id: "community") into its nexus_* tables — the chain is the permanent record, nexus-go builds the queryable state.
Canonical reference
This page is a summary. The full, code-accurate contract lives in the nexus-go repository: docs/communities.md.
Identity and types
A community is an on-chain account matching ^(blurt|hive)-([1-3])[0-9]{4,6}$. The first digit is the type, stored as type_id:
| Digit | Type | Intended model |
|---|---|---|
1 | Topic | anyone posts and comments |
2 | Journal | anyone comments; only members post |
3 | Council | only members post and comment |
Types are UX, not a hard wall
nexus-go stores the type but does not enforce Journal/Council posting rules; neither does the chain. A post that names a community is associated with it regardless of the author's role. Any "only authorized authors" guarantee must come from the consuming view — this is exactly why Core Updates relies on an author allowlist in its view rather than on the community type.
Roles
One role per account per community, stored as a numeric role_id:
| Role | role_id |
|---|---|
| owner | 8 |
| admin | 6 |
| mod | 4 |
| member | 2 |
| guest | 0 |
| muted | -2 |
Operations nexus-go recognizes
custom_json with id: "community" and exactly one posting auth; the payload is ["<action>", { "community": "...", ... }].
| Action | Effect | Authority checked? |
|---|---|---|
subscribe / unsubscribe | manage the actor's subscription | no (self) |
setRole | set an account's role_id | no |
setUserTitle | set an account's community title | no |
updateProps | update community properties | yes (role_id >= 6) |
mutePost / unmutePost | mute a top-level post (is_muted) | no |
pinPost / unpinPost | pin a top-level post (is_pinned) | no |
What is actually enforced
Only updateProps checks the actor's authority (admin/owner). setRole, setUserTitle, mutePost, and pinPost are indexed as broadcast — the role hierarchy is enforced by front-ends, not by the indexer. Mute/pin apply to top-level posts only (comments are ignored).
Properties and moderation
updateProps accepts normalized, length-capped properties: title (≤32), about (≤120), lang (≤2), is_nsfw, description/flag_text (≤5000), reward_share (JSON ≤8 KB), settings (JSON ≤16 KB), and banner_url (a nexus-go extension; absolute http/https, ≤1024). avatar_url is read from settings.avatar_url. URL props reject non-http(s) schemes to prevent stored XSS in front-ends.
Muted posts are excluded from bridge.get_ranked_posts and bridge.get_forum_posts; a direct read still returns the post with moderation state in the bridge stats object.
Not in nexus-go
Compared with the classic Nexus/Hive communities spec, nexus-go has no setRewardShare (reward share is set via updateProps) and no flagPost / moderation queue, and it does not enforce community types or the role hierarchy at index time. See the canonical reference for the complete list of differences.
Reading communities
Front-ends read community state through the bridge API, routed to nexus-go by the RPC proxy: bridge.get_community, bridge.get_community_context, bridge.list_communities / list_pop_communities / list_top_communities, bridge.list_community_roles / list_community_titles, bridge.list_subscribers, and bridge.list_all_subscriptions. See the Reference.