Appearance
Communities & Social
Spec Source: Document 5 — Communities, Sharing & Social | Last Updated: Feb 2026
Overview
A community is a shared space where DoCurious users post what they have done (Track Records), what they want to do (Bucket List items), and general conversation (Discussion posts). Communities are not chat rooms or social media feeds -- they are closer to shared bulletin boards that members check at their own pace. Every piece of content in a community feed was deliberately placed there by the person who created it. Nothing is auto-shared, algorithmically ranked, or pushed via notification.
DoCurious supports six community types, three feed types per community, structured membership and moderation, a deliberate batch-sharing model for Track Records, and passive partner-finding for challenges. The system is designed so that social features motivate real-world activity without ever becoming the primary activity themselves.
STATUS: BUILT
The community system is fully implemented with types, store, mock API, six page components, and ten UI components. Core flows include browse, create (with 6-type selector), join, feed viewing (3 feed types), discussion posting, batch sharing, moderation tools, and structured membership management.
Philosophy
DoCurious is not a social media platform. Social features exist to provide context and motivation for doing real-world challenges, not to become the primary activity. Every social design decision flows from three principles:
Pull, not push. Users check community feeds when they are curious. The platform does not send push notifications for new feed items. There is no doomscrolling, no algorithmic engagement optimization, and no "unread" indicators. Feeds are loaded when a user navigates to them and displayed in reverse chronological order.
Context over connections. People see each other's activity within shared contexts (communities, challenges). There are no follower counts, no public friend lists, and no "following" model. Profile visibility is scoped by relationship -- strangers see only a display name, while shared-community members see activity that has been explicitly shared to mutual communities.
No direct messaging. DoCurious does not have in-platform messaging between users. Communication happens through comments on Track Record entries, challenge discussions, structured contact forms (for premium partner-finding), and off-platform coordination. This is a deliberate structural choice to prevent the platform from becoming a communication tool.
These principles mean DoCurious communities feel like checking a bulletin board at a community center rather than scrolling a social media timeline. Members post what they have done, what they want to do, and general discussion -- and other members check in when they feel like it.
How It Works
Community Types
STATUS: BUILT
All six community types are implemented: Family, Trusted Friends, Casual Friends, Interest/Hobby, Institutional (School/Class), and Other. The CreateCommunityForm includes a card-based type selector with icons and descriptions for all 6 types. Per-type defaults for visibility and join model are configured.
DoCurious has six community types. Each type has distinct defaults for visibility, joining, and gifting, but creators can customize visibility for all types.
| Type | Default Visibility | Default Join Model | Gifting Default | Created By |
|---|---|---|---|---|
| Family | Private | Invite only | Yes | Any user |
| Trusted Friends | Private | Invite only | Yes | Any user |
| Casual Friends | Private | Invite only | No | Any user |
| Interest / Hobby | Public | Requestable (creator can switch to auto-join) | No | Any user |
| Other / General | Creator chooses | Creator chooses | No | Any user |
| Institutional (School) | Private | SA-managed roster | Yes | School Admin only |
How types differ: Family and Trusted Friends communities default to private, invite-only spaces where members can gift challenges to each other. Interest/Hobby communities default to public and discoverable, letting anyone request to join. School communities have their membership managed entirely by the School Admin -- students and teachers are added and removed through the school roster system, not through self-service joining.
Any registered user can create a community (except Institutional, which requires a School Admin). There is no limit on how many communities a user can create or belong to. No approval is required to create a community.
Community Creation
STATUS: BUILT
The CreateCommunityForm component supports name (max 50 chars), description, community type selection (6-type card selector), visibility selection (public/private/invite-only), toggle settings for member posting and post approval, and cover image placeholder. Tier 1 school-only accounts correctly see a blocked state preventing community creation.
The creation flow works as follows:
- User navigates to "Create a Community" from the Communities section of their dashboard.
- Selects community type: Family, Trusted Friends, Casual Friends, Interest/Hobby, or Other/General. (Institutional is created only by School Admins through the school admin flow.)
- Enters basic setup: name (max 100 characters per spec, currently 50 in UI), description (max 500 characters), and optional cover image.
- Chooses visibility: Private or Public/Discoverable. Defaults are based on type but can be changed.
- Chooses join model: Invite only, Requestable, or Auto-join. Defaults are based on type but can be changed.
- Configures discussion posting permissions: all members (default) or creator/moderators only.
- Community is created immediately. Creator becomes the first member with the "creator" (owner) role.
Post-creation settings that the creator can update at any time: name, description, cover image, visibility, join model, discussion posting permissions, gifting default, moderator assignments, ownership transfer, and community deletion.
Community Deletion
STATUS: BUILT
Community deletion is defined in the spec but has not been implemented in the frontend. The store and API do not currently expose a delete operation.
Only the creator can delete a community. Deleting a community:
- Removes the community from all members' community lists
- Removes all community feed items (Bucket List, Track Record, Discussion feeds)
- Does NOT delete any member's Track Records, challenges, or personal content
- Does NOT affect gifting permissions that were individually overridden
- Is permanent and not reversible
Members receive an in-app notification: "[Community Name] has been deleted by its creator."
Membership & Joining
STATUS: BUILT
Join, leave, join-request, and membership management flows are implemented. The JoinRequestFlow component handles the full lifecycle for private communities (request button, pending state, admin approve/deny with confirmation dialogs). The MemberList component shows members sorted by role with search, role management dropdowns, and remove/ban actions. The store supports joinCommunity, leaveCommunity, fetchMembers, and updateMemberRole.
Invitation flow (for invite-only and requestable communities):
- Member opens community settings and clicks "Invite Members."
- Searches for existing DoCurious users by display name or email, or enters email addresses for non-members.
- Invitees receive an in-app notification. If the email does not belong to a DoCurious user, clicking the invite link enters the signup funnel and the community invitation is automatically applied after registration.
- Invitee accepts or declines. Accepting adds them as a member immediately.
Join request flow (for requestable communities):
- Non-member discovers the community through the Discover Communities view or a shared link.
- Clicks "Request to Join." Optionally includes a short message (max 200 characters).
- Creator and moderators see the pending request with approve/deny buttons.
- If approved, the requester is added as a member. If denied, the requester is notified with no reason required.
Auto-join (for public communities set to auto-join): Non-members click "Join" and become members immediately with no approval step.
Leaving a community: Any member can leave voluntarily at any time. Previously shared Track Records are hidden from community feeds (but remain on the user's personal account). The creator cannot leave without transferring ownership first.
Member Roles
STATUS: BUILT
The four-role hierarchy (owner/admin/moderator/member) is implemented in the type system, member list UI, and role management dropdowns. Permission checks are enforced in the mock API for posting, moderation, and role changes.
| Role | Permissions |
|---|---|
| Creator (Owner) | Full control: all settings, delete community, assign moderators, transfer ownership, remove/mute members, manage join requests, post in all feeds. |
| Moderator | Manage join requests, remove/mute members, delete posts in any feed. Cannot change community settings, delete community, or assign other moderators. |
| Member | View all feeds, post to feeds (subject to discussion permissions), share Track Records and Bucket List items to community, invite new members (if invite-only). |
Note: The codebase also includes an "admin" role between owner and moderator that is not in the spec. This provides an additional tier with permission to change some community settings but not delete the community or manage other admins.
Community Feeds
STATUS: BUILT
The three-tab feed system (Bucket List, Track Record, Discussion) is implemented in both CommunityDetail and SchoolCommunity pages. Feed items are filtered by type per tab, with item counts displayed on each tab. The FeedPost component renders individual items with author info, timestamps, like/comment/share actions, threaded comments, pin/announcement badges, and moderator actions (delete, pin). Pagination is supported in the store and API (20 items per page).
Each community has three separate, intent-driven feeds. This separation prevents a single noisy feed and gives members clear navigation to what they are looking for.
| Feed | Content | Purpose |
|---|---|---|
| Bucket List | Challenges that members have added to their Bucket Lists and chosen to share with this community. | What members want to do. Enables partner-finding. |
| Track Record | Track Records that members have shared with this community via Pattern B batch sharing. | What members have accomplished. Social proof and inspiration. |
| Discussion | General text posts and replies. Not attached to any specific challenge. | General community conversation. |
Feed interaction model (pull, not push):
- No notifications for new feed items. Members see new items when they next visit the feed.
- No real-time updates. Feeds are loaded when the user navigates to them.
- Chronological order. All three feeds display items in reverse chronological order. No algorithmic ranking.
- Read position is not tracked. There is no "unread" indicator.
Feed pagination: 20 feed items per page with a "Load More" button (not infinite scroll). Grouped updates count as 1 feed item regardless of how many items they contain.
Discussion Threading
STATUS: BUILT
Discussion posting is implemented with a text composer on the Discussion tab. Comments are threaded with a flat reply model (comment on a post). The FeedPost component renders comments inline with expand/collapse. Author display names and timestamps are shown. The comment input supports Enter-to-submit.
- Who can post: Default is all members. Creator can restrict to "Creator and moderators only" mode, where members can still reply but cannot create new top-level discussions.
- Post structure: Text content (rich text encouraged to be concise), threaded one level deep (top-level post with replies), author display name and timestamp. No attachments or media in discussion posts -- media goes in Track Records.
- Moderation: Creator and moderators can delete posts (removing the post and all its replies), mute members, and remove members.
Grouped Updates (24-Hour Windows)
STATUS: BUILT
Grouped updates are specified in the spec but not yet implemented in the frontend. Currently, each shared item appears as an individual feed card. The data model includes a group_id field on feed items to support future grouping.
To prevent any single user from flooding a feed, the platform groups multiple updates from the same user within a 24-hour window into a single feed card:
- Track Record Feed: If a user batch-shares 5 Track Records, the feed shows a single grouped card: "[User] shared 5 Track Records" with a thumbnail grid (up to 4 thumbnails, "+N more" indicator). Clicking expands to show all individually.
- Bucket List Feed: Same pattern: "[User] added 3 challenges to their Bucket List" with thumbnail grid.
- Discussion Feed: Posts are NOT grouped. Each appears individually since they may be on different topics.
Pattern B: Deliberate Batch Sharing
STATUS: BUILT
The BatchShareModal component implements a two-panel dialog for selecting items (tabbed by Track Records, Saved/Bucket List, Completions) and target communities. The useCommunityStore.batchShare action sends a Track Record to multiple communities in a single operation. The store's batchShareTrackRecord API endpoint creates feed items in each target community and updates post counts. Currently uses mock data for the item and community lists.
DoCurious uses "Pattern B" sharing: users build content privately, then deliberately select what to share and where. This prevents drip-feed notifications and trains intentional sharing behavior.
How it works:
- User creates Track Records privately. All new Track Records default to "Private" sharing scope. Nothing is visible to anyone until the user decides to share.
- User clicks "Share" from their dashboard or a Track Record's detail page.
- Bulk selection interface: User sees a list of their shareable Track Records (verified or in-progress drafts). They can select multiple at once.
- Choose destination: For each selected batch, user picks the sharing scope -- specific communities (multi-select), specific individuals, or public (visible in the challenge's Track Record Gallery).
- Confirm and share: User reviews the summary (e.g., "Share these 5 Track Records with Family, these 3 publicly") and clicks confirm.
- Grouped feed appearance: Shared Track Records appear in each destination community's Track Record Feed as a grouped update.
Sharing behavior rules:
- Sharing is additive: A Track Record shared with Community A can later also be shared with Community B without removing it from A.
- Sharing is revocable: A user can remove a Track Record from a community's feed at any time. It disappears from the feed but is not deleted from the user's account.
- No accidental sharing: The platform never auto-shares anything. Every piece of content in a community feed was deliberately placed there by the content owner.
Partner-Finding
STATUS: BUILT
Passive partner-finding (Bucket List overlap detection in community feeds) is defined in the spec and the types support it, but the overlap highlighting UI ("[User A] and [User B] both want to try [Challenge]") is not yet implemented. Premium partner-finding (structured introduction requests with radius search) is not started.
Passive partner-finding (free): When two or more community members have the same challenge on their Bucket List, the feed can highlight this overlap. Users can also comment on feed items or challenge discussions to express interest in partnering. This is a passive discovery feature, not a matching system.
Premium partner-finding (future): A premium membership feature allowing structured partner-finding beyond community boundaries. Includes radius-based search (5--100 miles), structured introduction requests (not open messaging), and acceptance/decline flows. This feature uses structured forms rather than open messaging to maintain the no-DM principle.
Moderation
STATUS: BUILT
The CommunityModTools component provides a full moderation panel for admins/moderators, including flagged content review, and four action types: remove post, warn user, mute user (with configurable duration: 1h to 30d), and ban user. Each action requires a confirmation dialog with an optional reason field. A moderation log shows recent actions with timestamps. The FeedPost component includes a ReportButton for flagging content. Currently uses mock data for flagged items and log entries.
Community-level moderation (by creator/moderators):
| Action | Effect | Scope |
|---|---|---|
| Delete post | Removes the post and all its replies. Author is notified. | Community only |
| Mute member | Member can view feeds but cannot post or comment. Indefinite until manually unmuted. Member sees a banner. | Community only |
| Remove member | Loses access to all community feeds. Previously shared Track Records hidden from feeds. | Community only |
Platform-level moderation (by DoCurious staff):
- Any user can flag content (discussion posts, Track Record entries, comments, feed items) with a reason: Inappropriate, Spam, Harassment, Dangerous activity, or Other.
- Flagged content enters the staff moderation queue. Content remains visible until reviewed unless it receives 3 unique flags, which triggers auto-hide pending review.
- Staff actions: Approve (dismiss flag), Remove content, Warn user, Suspend user (temporary platform-wide restriction).
Minor-specific protections: Content from under-13 users is auto-held for review before appearing in any public context. Content within school communities is not auto-held. Under-13 sharing is controlled by parent settings (Tier 2) or restricted to school context (Tier 1).
Challenge-Specific Discussions
STATUS: BUILT
Challenge-specific discussions (on the challenge detail page, separate from community discussions) are specified but not yet implemented as a distinct feature. The infrastructure for threaded comments exists and could be extended.
In addition to community feeds, each challenge has a universal discussion section visible to all DoCurious users:
- Located on the challenge detail page below the Track Record Gallery
- Any user who has started or completed the challenge can post
- Threaded one level deep
- Vendors can respond to discussions on their own challenges (posts marked with "Vendor Response" badge)
- Moderated by DoCurious staff via the flagging system
Key distinction: Challenge discussions are universal and about the challenge itself (like product reviews). Community discussions are scoped to a community and can be about anything.
School Communities
STATUS: BUILT
The SchoolCommunity page handles all three school community levels (full_school, grade, class) with level-specific headers, descriptions, and context labels. Class communities support challenge assignments, student progress tracking, teacher submission review, and past assignment history. The AssignmentProgress page shows per-student progress with status badges, progress bars, and inline review capabilities. Auto-membership notices are displayed for roster-managed communities.
School/Institutional communities have a specialized flow:
- Created by School Admins through the school admin interface (not the regular creation flow)
- Three levels: Full School (all students), Grade (grade-level), Class (teacher-managed)
- Membership is managed by the school roster -- students and teachers are automatically added/removed
- Class communities support challenge assignments: teachers can assign challenges, track per-student progress, review submissions, and archive completed assignments
- Teachers see a "Submissions" tab showing pending Track Records awaiting review
Notifications (Community-Specific)
STATUS: BUILT
Community notification delivery is not yet implemented. The notification types are specified but the notification system is still in planning.
Community feeds use a pull model, so there are NO notifications for new feed items. Notifications are limited to membership and moderation events:
| Event | Recipient | Timing |
|---|---|---|
| Community invitation received | Invitee | Immediate (in-app + email) |
| Join request received | Creator / moderators | Immediate (in-app) |
| Join request approved/denied | Requester | Immediate (in-app) |
| New member joined (auto-join) | Creator | Immediate (in-app) |
| Removed from community | Removed member | Immediate (in-app) |
| Muted in community | Muted member | Immediate (in-app) |
| Community deleted | All members | Immediate (in-app) |
| Discussion post removed by moderator | Post author | Immediate (in-app) |
| Content flagged (auto-hidden) | Content author | On auto-hide (in-app) |
Roles & Permissions
This matrix shows what each platform role can do with community features.
| Action | General User | Student (Tier 1) | Student (Tier 2) | Parent | Teacher | School Admin | Platform Admin |
|---|---|---|---|---|---|---|---|
| Create community (non-school) | Yes | No | Yes (with parent permission) | Yes | Yes | Yes | Yes |
| Join public community | Yes | No | Yes | Yes | Yes | Yes | Yes |
| Request to join private community | Yes | No | Yes | Yes | Yes | Yes | Yes |
| View community feeds | Yes | School only | Yes | Yes | Yes | Yes | Yes |
| Post to discussion feed | Yes | School only | Yes | Yes | Yes | Yes | Yes |
| Share Track Records to community | Yes | School only | Yes (parent can revoke) | Yes | Yes | Yes | Yes |
| Share Bucket List to community | Yes | School only | Yes | Yes | Yes | Yes | Yes |
| Create school community | No | No | No | No | No | Yes | Yes |
| Assign challenges (class community) | No | No | No | No | Yes | Yes | Yes |
| Review student submissions | No | No | No | No | Yes | Yes | Yes |
| Moderate community content | Community creator/mods only | No | No | No | Community creator/mods | Community creator/mods | Yes |
| Flag content | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Review flagged content (platform) | No | No | No | No | No | No | Yes |
Constraints & Limits
| Constraint | Value | Rationale |
|---|---|---|
| Community name length | Max 100 characters (50 in current UI) | Keep names scannable in lists and cards |
| Community description length | Max 500 characters | Enough for context without overwhelming browse views |
| Join request message length | Max 200 characters | Brief intro, not an essay |
| Discussion post text | No hard character limit (UI encourages concise) | Rich text, but kept lightweight -- media goes in Track Records |
| Discussion threading depth | 1 level (top-level post + replies) | Prevents deeply nested threads that are hard to follow |
| Feed items per page | 20 | Manageable page size with "Load More" button |
| Grouped update window | 24 hours | Prevents feed flooding while still showing activity |
| Auto-hide flag threshold | 3 unique flaggers | Balances community self-moderation with preventing abuse of flagging |
| Premium partner-finding radius | 5--100 miles (configurable) | Practical for real-world meetups |
| Premium partner-finding message | Max 200 characters | Structured, not open messaging |
| Communities per user | No limit | Users can belong to as many communities as they want |
| Community creation limit | No limit | Any user can create unlimited communities |
Visibility Controls
Who sees what depends on the viewer's relationship to the content owner.
| Viewer | What They See |
|---|---|
| Stranger (no shared communities) | Display name only. No activity, no community memberships, no Track Records. |
| Shared community member | Display name. Track Records shared with mutual communities. Bucket List items shared with mutual communities. Institutional and Interest/Hobby community memberships. Publicly shared challenge completions. |
| Parent of under-13 child | Full visibility: everything. All Track Records (including private), all community memberships, all activity, all gifting, all sharing settings. |
| DoCurious staff | Full visibility for moderation purposes. |
| School SA / Teacher | School-context activity only: school challenges, school community contributions, school-related Track Records. No visibility into personal communities or non-school activity. |
Community membership visibility on profiles:
- Institutional communities: School name is visible (e.g., "Lincoln Elementary")
- Interest/Hobby communities: Visible if the community is public/discoverable
- Private friend communities (Family, Trusted Friends, Casual Friends): NEVER visible to non-members
Design Decisions
Why no direct messaging? DoCurious is built around real-world activities, not online conversations. Adding DMs would shift user behavior toward treating the platform as a communication tool. Instead, structured mechanisms (comments, challenge discussions, premium introduction requests) provide enough coordination capability without creating open communication channels. This also provides structural safety for minors on the platform.
Why three separate feeds instead of one? A single combined feed would quickly become noisy and unfocused. Separating Bucket List (aspirational), Track Record (accomplishment), and Discussion (conversation) lets members find what they are looking for immediately. A member who wants inspiration checks the Track Record feed. A member who wants to find a partner for a challenge checks the Bucket List feed. A member who wants to chat checks the Discussion feed.
Why Pattern B (deliberate batch sharing) instead of auto-sharing? Auto-sharing would undermine the platform's off-screen-first mission. If every Track Record automatically appeared in community feeds, users would feel pressure to document and share immediately. Pattern B trains intentional behavior: do the activity, document it when you are ready, then decide who sees it. This also prevents accidental over-sharing and gives users full control over their visibility.
Why pull-model feeds with no notifications? Push notifications for feed items would turn DoCurious into an engagement platform. The pull model means users check feeds when they are genuinely curious, not because a notification demanded their attention. This supports the "off-screen-first" mission where the platform is a tool for enhancing real-world activity, not a destination for consuming content.
Why indefinite muting instead of timed muting? The spec calls for indefinite muting (until manually unmuted) to keep the moderation model simple for community creators who may not be experienced moderators. The current UI implementation offers timed mute durations (1h to 30d) as a convenience, which is a reasonable enhancement over the spec. This may be revisited based on user feedback.
What to revisit:
- Community type selection during creation (currently all user-created communities are "private" type)
- The name length limit discrepancy (spec says 100, current UI enforces 50)
- Grouped updates (24-hour window) -- not yet implemented
- Premium partner-finding -- deferred until feature is fully designed
- Challenge-specific discussions -- infrastructure exists but feature is not wired up
- Community deletion -- not yet exposed in the UI
- Email invitation flow for non-platform users
Technical Implementation
Type Definitions
| File | Description |
|---|---|
src/types/community.types.ts | Core types: Community, CommunityMembership, FeedItem, FeedComment, FeedLike, CommunityInvitation, CommunityAssignment, CommunityStudentProgress. Enums: CommunityType (8 values), CommunityVisibility, CommunityRole, MembershipStatus, FeedItemType (6 values), SchoolCommunityLevel, AssignmentStatus, StudentAssignmentStatus. |
State Management
| File | Description |
|---|---|
src/store/useCommunityStore.ts | Zustand store managing communities, memberships, feeds, and assignments. Key state: communities, myCommunities, schoolCommunities (by level), privateCommunities, currentCommunity, currentMembers, currentFeed, communityAssignments, assignmentProgress. 20+ actions including fetch, create, update, join, leave, post, like, comment, batch share, and assignment management. Includes 12 memoized selectors. |
src/store/useShareStore.ts | Zustand store for the batch share modal. Manages selected items, target community IDs, optional message, and share execution state. |
API Layer
| File | Description |
|---|---|
src/api/community.api.ts | Mock API with 25+ endpoints covering community CRUD, membership management, feed operations (get/create/delete/like), comments, batch sharing, school community queries, and challenge assignment lifecycle. All operations include auth checks and permission enforcement against the mock database. |
src/api/community.real.api.ts | Placeholder for real backend API integration (not yet connected). |
src/api/communityGoal.api.ts | Mock API for community goals (active/upcoming/completed goals, participation, leaderboards). |
src/api/communityGoal.real.api.ts | Placeholder for real community goal API integration. |
Page Components
| File | Description |
|---|---|
src/pages/communities/Communities.tsx | Main communities browse page. Tabs for "My Communities" and "Discover" with search filtering, community cards showing visibility badges and member counts, and join/view actions. |
src/pages/communities/CommunityDetail.tsx | Full community detail view with sidebar (about, stats, member list), three-tab feed system, discussion composer, quick share actions, teacher submission review (school communities), and moderation tab for admins. |
src/pages/communities/PrivateCommunities.tsx | Dedicated page for user-created (non-school) communities. Same browse/discover/search pattern as the main communities page, scoped to private communities. |
src/pages/communities/SchoolCommunity.tsx | School community page handling all three levels (full_school, grade, class). Level-specific headers, auto-membership notices, challenge assignments, past assignment history, and teacher submission review. |
src/pages/communities/CommunityGoals.tsx | Community goals page with active/upcoming/completed goal lists and goal detail view with participation tracking and leaderboards. |
src/pages/communities/AssignmentProgress.tsx | Detailed assignment progress page showing per-student status table with progress bars, status badges, inline review capability for teachers, and archive functionality. |
UI Components
| File | Description |
|---|---|
src/components/community/CommunityCard.tsx | Card component for community listings (Storybook story available). |
src/components/community/CommunityHeader.tsx | Community header with name, type badge, stats, and join/leave actions (Storybook story available). |
src/components/community/FeedPost.tsx | Individual feed post with author info, timestamps, like/comment/share bar, threaded comments, pin/announcement badges, dropdown menu with delete and report actions (Storybook story available). |
src/components/community/MemberList.tsx | Member list with search, role badges (owner/admin/moderator/member), role management dropdowns, and remove/ban actions (Storybook story available). |
src/components/community/CreateCommunityForm.tsx | Community creation form with name, description, visibility picker, and posting settings. Tier 1 students see a blocked state. |
src/components/community/GoalCard.tsx | Card for community goals (Storybook story available). |
src/components/community/GoalDetail.tsx | Detailed goal view with participation, leaderboard, and recent contributions. |
src/components/community/AssignChallengeModal.tsx | Modal for teachers to assign a challenge to a class community. |
src/components/community/AssignedChallengeCard.tsx | Card showing the currently assigned challenge with due date, progress stats, and teacher actions (update/archive). |
src/components/social/BatchShareModal.tsx | Two-panel batch share dialog. Left panel for selecting items (tabbed: Track Records, Saved, Completions). Right panel for selecting target communities. Summary line and optional message. Currently uses mock data. |
src/components/social/JoinRequestFlow.tsx | Full join request lifecycle: "Request to Join" button for non-members, "Request Pending" state, admin view with pending request cards (approve/deny with confirmation dialogs). |
src/components/social/CommunityModTools.tsx | Moderation panel with flagged content review, four action types (remove post, warn, mute with duration, ban), confirmation dialogs with reason fields, and a moderation action log. |
src/components/social/ShareButton.tsx | Reusable share button component. |
src/components/social/BlockUserButton.tsx | User blocking action component. |
src/components/social/SafetyResources.tsx | Safety resources display component. |
Data Model (Backend)
The spec defines these PostgreSQL tables for the communities feature:
| Table | Purpose |
|---|---|
communities | Core community record with type, visibility, join model, discussion settings, gifting default |
community_memberships | User-community relationship with role, status (active/muted/removed/invited/requested), gifting override |
community_invitations | Invitation records for email and in-platform invites |
community_feed_items | Feed content across all three feed types, with threading support and 24h grouping |
community_feed_item_flags | Content flagging with reason categories and review status |
track_record_community_shares | Junction table tracking which Track Records are shared to which communities (revocable) |
bucket_list_community_shares | Junction table tracking Bucket List shares to communities (revocable) |
partner_finding_requests | Structured introduction requests for premium partner-finding |
moderation_actions | Log of all moderation actions (community-level and platform-level) |
Related Features
- Challenges -- Challenges are the content that communities share, discuss, and coordinate around. Track Records from completed challenges appear in community Track Record feeds.
- Track Records -- Track Records are shared to communities via Pattern B batch sharing. The Track Record feed is one of three community feed types.
- Explore Page -- The Discover Communities view on the Explore page is how users find public and discoverable communities to join.
- Gifting -- Community type determines the default gifting permission. Family and Trusted Friends communities default to allowing gifts; others default to not allowing them. Individual members can override the community default.
- Accounts -- User roles, age-based restrictions (Tier 1/Tier 2), and COPPA compliance rules determine what community features are available to each user. Parent accounts have full visibility into their child's community activity.