doc: add task lists for emojis (and starred projects), plus some MDC files

2025-10-05 19:57:34 -06:00
parent 62a0d96661
commit f23534e212
6 changed files with 122 additions and 9 deletions
@@ -0,0 +1,101 @@
+
+# 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 emoji(s) and only emojis - 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 emjoi count of the parent if `give_claim`, `offer_claim`, or `plan_claim`
+
+**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 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
+**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)
+
+**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
+- [ ] Create new `comment_claim` table following existing patterns
+- [ ] Add `emojiCount` column to relevant summary tables (optional optimization)
+- [ ] Update database service methods
+- [ ] Test migration with existing data
+
+### 10. 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
+
+## 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
+
+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.
+
+
@@ -0,0 +1,9 @@
+# Starred projects & change notifications
+
+- ✅ Allow Time Safari users to mark projects with a "star" such that their local app has those projects stored in settings. **COMPLETED**
+
+After that is finished, we'll add this functionality:
+
+- ✅ Use or write an endpoint in endorser-ch to accept a list of project IDs and a "most recent" claim ID (and potentially a date) and retrieve all the projects which have changed since that date. Use both a GET and a POST approach in case there are many IDs. **COMPLETED**
+
+- Add a notification for "starred projects with changes" on the front page of Time Safari, much like the other two notifications that are in the NewActivityList.vue page.