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. |
Loading…
Reference in new issue