From 1d75ab34ef74e435e819bdecf073f6d1c56b1554 Mon Sep 17 00:00:00 2001
From: Trent Larson <trent@trentlarson.com>
Date: Mon, 6 Oct 2025 20:57:16 -0600
Subject: [PATCH] doc: refine the emoji plan

---
 progress/TASK-emojis.md | 44 +++++++++++++----------------------------
 1 file changed, 14 insertions(+), 30 deletions(-)

diff --git a/progress/TASK-emojis.md b/progress/TASK-emojis.md
index bea6eaa..aaafc3c 100644
--- a/progress/TASK-emojis.md
+++ b/progress/TASK-emojis.md
@@ -8,9 +8,9 @@ Allow people to attach an emoji onto a record. The main entity to which emojis w
 ### 1. Data Structure Design
 **Emoji Claim Structure:**
 - [ ] **Type**: `"Comment"` 
-- [ ] **Text**: Contains emoji(s) and only emojis - e.g., `"👍"`, `"❤️🎉"`, or `"🚀"`
+- [ ] **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?)
+- [ ] **Context**: Follow existing claim pattern with `"@context": "https://schema.org"` (optional)
 - [x] The issuer is the "agent" attaching the emojis.
 
 ### 2. Database Schema Design
@@ -26,7 +26,8 @@ Allow people to attach an emoji onto a record. The main entity to which emojis w
 - [ ] Validate Comment claim structure
 - [ ] Store in `comment_claim` table
 - [ ] Return standard claim response with `claimId` and `handleId`
-- [ ] Add to emjoi count of the parent if `give_claim`, `offer_claim`, or `plan_claim`
+- [ ] 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
@@ -51,44 +52,31 @@ export interface CommentClaim extends ClaimObject {
 ### 6. Authentication & Authorization
 - [ ] Emojis require valid JWT authentication (like other claims)
 - [ ] Any authenticated user can add emojis to any public GiveAction
-- [ ] Users can only retrieve emojis they have permission to see (follow existing visibility rules)
-- [ ] Consider rate limiting for emoji submissions
-
-### 7. Validation Rules
-**Content Validation:**
-- [ ] Text length limit (e.g., 280 characters like Twitter)
-- [ ] Unicode emoji validation (optional - could allow any text)
-- [ ] Prevent empty or whitespace-only submissions
-- [ ] Sanitize text input for security
-
-**Business Rules:**
-- [ ] One emoji submission per user per item (or allow multiple?)
-- [ ] Prevent self-emoji on own GiveActions (optional business rule)
-- [ ] Consider moderation capabilities for inappropriate content
-
-### 8. Performance Considerations
+- [ ] Users can retrieve all emojis
+
+### 7. Performance Considerations
 **Counting Strategy:**
-- [ ] Option A: Real-time COUNT queries (simple, always accurate)
-- [ ] Option B: Cached counts with periodic updates (faster, eventual consistency)
-- [ ] Option C: Trigger-based count maintenance (complex but efficient)
+- [ ] Real-time COUNT queries (simple, always accurate)
 
 **Indexing:**
 - [ ] Index on `parentItemIdentifier` for emoji retrieval
-- [ ] Composite index on `(parentItemIdentifier, issuerDid)` if preventing duplicates
 - [ ] Consider pagination for items with many emojis
 
-### 9. Database Migration
+### 8. Database Migration
 - [ ] Create new `comment_claim` table following existing patterns
-- [ ] Add `emojiCount` column to relevant summary tables (optional optimization)
+- [ ] Add `emojiCount` column to relevant summary tables
 - [ ] Update database service methods
 - [ ] Test migration with existing data
 
-### 10. API Documentation
+### 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:
@@ -96,7 +84,3 @@ This design follows the existing Endorser Server patterns:
 - 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
-
-The emoji feature will integrate seamlessly with the existing GiveAction display system, showing emoji counts alongside other give information and providing a separate endpoint for detailed emoji retrieval when users want to see who reacted and with what emojis.
-
-