# Emojis

Allow people to attach an emoji onto a record. The main entity to which emojis will be attached is the "GiveAction", ie. items that show on the front page (though technically we won't limit attachment entity types).

## Feature Design Checklist

### 1. Data Structure Design
**Emoji Claim Structure:**
- [ ] **Type**: `"Comment"` 
- [ ] **Text**: Contains one emoji - e.g., `"👍"`, `"❤️"`, or `"🚀"`
- [ ] **ParentItem**: Object with `identifier` field containing the handleId of the target action (e.g., GiveAction)
- [ ] **Context**: Follow existing claim pattern with `"@context": "https://schema.org"` (optional)
- [x] The issuer is the "agent" attaching the emojis.

### 2. Database Schema Design
**New Table: `comment_claim`**
- [ ] Standard claim fields: `jwtId`, `handleId`, `issuerDid`, `issuedAt`, `claimType`
- [ ] Emoji-specific fields: `text`, `parentItemIdentifier`, `parentItemType`, `emojiOnly` (boolean)
- [ ] Indexes on `parentItemIdentifier` for efficient retrieval
- [ ] Consider emoji count aggregation strategy (computed vs. cached)

### 3. API Endpoint Design
**Submission Endpoint:**
- [ ] `POST /api/v2/claim` (reuse existing claim submission)
- [ ] Validate Comment claim structure
- [ ] Store in `comment_claim` table
- [ ] Return standard claim response with `claimId` and `handleId`
- [ ] Add to emoji count of the parent if `give_claim`, `offer_claim`, or `plan_claim`
- [ ] Allow for a removal of a previous emoji: if they sent it before, it gets erased (like in Slack)

**Retrieval Endpoints:**
- [ ] `GET /api/v2/report/comments?parentItemId=<handleId>` - Get all emojis for an item
  - Consider storing all emojis in a record for quick retrieval for any particular entity.

### 4. GiveAction Enhancement
**Modify existing endpoints:**
- [ ] Add `emojiCount` field to `GiveSummaryRecord` interface
- [ ] Update `dbService.getGives*` methods to include emoji counts

### 5. Client-Side Interface Design
**New TypeScript Interfaces:**
```typescript
export interface CommentClaim extends ClaimObject {
  "@context": "https://schema.org";
  "@type": "Comment";
  text: string;
  parentItem: { identifier: string };
}
```

### 6. Authentication & Authorization
- [ ] Emojis require valid JWT authentication (like other claims)
- [ ] Any authenticated user can add emojis to any public GiveAction
- [ ] Users can retrieve all emojis

### 7. Performance Considerations
**Counting Strategy:**
- [ ] Real-time COUNT queries (simple, always accurate)

**Indexing:**
- [ ] Index on `parentItemIdentifier` for emoji retrieval
- [ ] Consider pagination for items with many emojis

### 8. Database Migration
- [ ] Create new `comment_claim` table following existing patterns
- [ ] Add `emojiCount` column to relevant summary tables
- [ ] Update database service methods
- [ ] Test migration with existing data

### 9. API Documentation
- [ ] Update Swagger documentation for new endpoints
- [ ] Document Comment claim structure
- [ ] Provide examples of emoji submission and retrieval
- [ ] Document rate limits and validation rules

### 10. Performance Considerations
- [ ] Cached counts with periodic updates (faster, eventual consistency)

## Implementation Notes

This design follows the existing Endorser Server patterns:
- Reuses the proven JWT claim submission system
- Follows the established database and API patterns
- Maintains consistency with existing visibility and authentication rules
- Supports the distributed/P2P vision by storing emojis as signed claims