Public User Profiles & Activity Feed

Public User Profiles implement Phase 2 of the Handle System — giving every Visitor with a claimed @handle a shareable, discoverable profile page at /u/{handle}. The system bridges two subgraphs (nodes for identity resolution, community for activity aggregation) and enforces strict privacy controls.

Architecture Overview

Data Flow

┌─────────────────────────────────────────────┐
│  Frontend: /u/meekdenzo                     │
│                                             │
│  1. userByHandle("meekdenzo") → nodes       │
│  2. isFollowing(userId) → nodes             │
│  3. followerCount(userId) → nodes           │
│  4. userActivity(userId) → community        │
│  5. myFollowing(MALET) → nodes              │
│                                             │
│  All queries via Hive Gateway (port 30000)  │
└─────────────────────────────────────────────┘

Handle Resolution (`nodes` subgraph)

The userByHandle query resolves a Visitor's handle to their public profile. It is the entry point for all profile page loads.

GraphQL API

query UserByHandle($handle: String!) {
  userByHandle(handle: $handle) {
    id
    displayName
    handle
    avatarUrl
    bio
    createdAt
    profileVisibility
  }
}

Behavioral Rules

Implementation Notes

The resolver uses a case-insensitive regex for MongoDB lookups:

const user = await this.userModel
  .findOne({ handle: { $regex: new RegExp(`^${handle}$`, 'i') } })
  .select('id handle displayName avatarUrl bio createdAt profileVisibility')
  .lean()
  .exec();

Activity Feed (`community` subgraph)

The Activity Feed provides a chronological list of a Visitor's public contributions — Reviews, Issues, and Discussions. It uses read-time aggregation from existing collections rather than maintaining a separate activity log.

GraphQL API

query UserActivity($userId: ID!, $limit: Int) {
  userActivity(userId: $userId, limit: $limit) {
    id
    type          # REVIEW | ISSUE_OPENED | DISCUSSION
    entityId
    entityTitle
    targetName
    createdAt
  }
}

Activity Types

Architecture Decision: Read-Time Aggregation

The Activity Feed performs parallel MongoDB queries across three collections and merges/sorts in memory:

const [reviews, issues, discussions] = await Promise.all([
  this.reviewModel.find({ createdBy: userId, status: 'APPROVED' })
    .sort({ createdAt: -1 }).limit(limit).lean().exec(),
  this.issueModel.find({ createdBy: userId })
    .sort({ createdAt: -1 }).limit(limit).lean().exec(),
  this.discussionModel.find({ createdBy: userId })
    .sort({ createdAt: -1 }).limit(limit).lean().exec(),
]);
// Merge → sort by createdAt desc → slice to limit

Why read-time instead of a materialized activity collection:

• Data consistency: Activity is always current — no sync lag or orphaned entries
• Zero write overhead: No event handlers, no dual-writes, no eventual consistency bugs
• Simple rollback: If a Review is un-approved, it instantly disappears from the feed
• Acceptable latency: Three parallel .lean() queries with .select() projections are fast at current data volumes

When to reconsider: If activity feed queries become a latency bottleneck (>200ms p95), introduce a denormalized user_activity collection with write-through from entity creation hooks.

Module Registration

@Module({
  imports: [
    TypegooseModule.forFeature([Review, Issue, Discussion]),
  ],
  providers: [ActivityService, ActivityResolver],
  exports: [ActivityService],
})
export class ActivityModule {}

Frontend Integration

Route Structure

The public profile lives at /u/[handle]:

src/routes/u/[handle]/
├── +page.ts          # SvelteKit load — extracts handle param
└── +page.svelte      # Profile page component

Profile Page Tabs

Social Integration

The profile header includes follow/unfollow functionality via the ActorBadge component:

Follow errors display as an inline toast that auto-dismisses after 4 seconds.

Error Handling

The profile page uses a parseGraphQLError() utility that classifies graphql-request ClientError responses into human-friendly messages:

Discussion Create DTO

As part of this feature, the DiscussionInputDTO was extended with subjectId and subjectType fields:

export class DiscussionInputDTO {
  @IsString()
  @MaxLength(20)
  @Field()
  name!: string;

  @IsString()
  @Field({ description: 'ID of the subject entity (e.g. Malet, Order)' })
  subjectId!: string;

  @IsOptional()
  @Field(() => SubjectType, {
    nullable: true,
    defaultValue: SubjectType.MALET,
  })
  subjectType?: SubjectType;
}

Previously, subjectId was required on the Mongoose schema but not exposed in the GraphQL input — causing every createOneDiscussion mutation to fail with a Mongoose validation error.

Testing

Backend

# Community E2E (14 tests — includes activity module validation)
make test-e2e PATTERN=community

# TypeScript type check
cd apps/community && npx tsc --noEmit

Frontend

# Unit tests (28 tests)
npx vitest run tests/public-profile.test.ts

# E2E tests (5 tests)
npx playwright test tests/public-profile.spec.ts

File Reference

Related

• Handle System & Sigil Taxonomy — Phase 1 handle infrastructure that this feature builds on
• Social Graph — Collections, Follows & Murchaser Dashboard — Follow system powering the profile follow/unfollow buttons
• Community Features — Reviews, Q&A, and Issues that populate the activity feed
• Community Orchestration — Assignment workflows for Issues and Discussions referenced in activity items
• Privacy & Security APIs — profileVisibility field that controls public profile access