refactor progress-file structures, flesh out Gift Economies events
This commit is contained in:
@@ -0,0 +1,159 @@
|
||||
|
||||
# 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:**
|
||||
- **Context**: Optional, with default of `"@context": "https://endorser.ch"`
|
||||
- **Type**: `"Emoji"`
|
||||
- **Text**: Contains one emoji - e.g., `"👍"`, `"❤️"`, or `"🚀"`
|
||||
- **ParentItem**: Object with `lastClaimId` field containing the handleId of the target action (e.g., GiveAction)
|
||||
|
||||
- Why not multiple emojis (eg. to optimize bandwidth & storage when using many)?
|
||||
Because there's a possibility of removing an emoji, and then the communication and logic (on both client & server) for determining which is off and which is on becomes more complicated. It's also not a very typical action: people usually attach one at a time. It's possible, so it's an optimization worth considering someday.
|
||||
|
||||
### 2. Database Schema Design
|
||||
**New Field on `give_claim`: `emojiCount`**
|
||||
- [x] map of emoji character key to numeric count of that emoji
|
||||
|
||||
**New Table `emoji_claim`**
|
||||
- [x] Standard claim fields: `jwtId`, `issuerDid`, `issuedAt`
|
||||
- [x] Emoji-specific fields: `text`, `parentItemHandleId`
|
||||
|
||||
**Database Migration**
|
||||
- [x] Create new `emoji_claim` table following existing patterns
|
||||
- [x] Add `emojiCount` column to `give_claim` tables
|
||||
- [x] Indexes on `parentItemHandleId` & `issuerDid` for efficient retrieval
|
||||
- [x] Update sql/README.md with new schema (following development conventions)
|
||||
|
||||
### 3. API Endpoint Design
|
||||
**Submission Endpoint:**
|
||||
- [x] `POST /api/v2/claim` (reuse existing claim submission)
|
||||
- [x] Validate Emoji contents: text, lastClaimId
|
||||
- [x] Ensure there is no "agent". (The issuer is the "agent" attaching the emojis; it doesn't make sense to attach an emoji on behalf of someone else.)
|
||||
- [x] Store in `emoji_claim` table
|
||||
- [x] Update `give_claim` `emojiCount`
|
||||
- [x] Return standard claim response with `claimId` and `handleId`
|
||||
- [x] Add to emoji count of the parent if `give_claim`
|
||||
- [x] Allow for a removal of a previous emoji: if they sent it before, it gets toggled (like in Slack) and entry in `emoji_claim` for this `issuerDid` + `parentHandleId` + `text` is erased
|
||||
|
||||
**New Retrieval Endpoints:**
|
||||
- [x] `GET /api/v2/report/emoji?parentHandleId=<handleId>` gets all active `emoji_claim` records for an item, paged
|
||||
|
||||
**Modify existing endpoints:**
|
||||
- [x] Update `dbService.getGives*` methods to include emoji counts
|
||||
- [x] Update types and API documentation
|
||||
|
||||
**API Documentation**
|
||||
- [x] Update Swagger documentation for new endpoints
|
||||
- [x] Document Emoji claim structure
|
||||
- [x] Provide examples of emoji submission and retrieval
|
||||
|
||||
**Authentication & Authorization**
|
||||
- Emojis require valid JWT authentication (like other claims)
|
||||
- Any authenticated user can add emojis to any public GiveAction
|
||||
- Users can retrieve all emoji taggers on a particular GiveAction, though DIDs are subject to visibility constraints
|
||||
|
||||
**Test**
|
||||
- [x] Write tests for each case on the back end (multiple emojis, removal, etc) in a new test file
|
||||
|
||||
### 5. Client-Side
|
||||
**Add to UI**
|
||||
- [x] Add the button for adding emojis, and a click sends it
|
||||
- See https://www.npmjs.com/package/emoji-mart-vue-fast
|
||||
- [x] UI should show new emoji quickly
|
||||
- [x] Show the previous emojis with their count, with data from GiveSummaryRecord
|
||||
- [x] Clicking on an emoji already sent from this person removes it
|
||||
|
||||
**Sample of emoji-mart-vue-fast***
|
||||
|
||||
We expect the emoji-mart-vue-fast library will be the best one to allow users to choose an emoji. Here is exsample usage:
|
||||
|
||||
```
|
||||
<template>
|
||||
<div class="row">
|
||||
<Picker :data="emojiIndex" set="twitter" @select="showEmoji" />
|
||||
</div>
|
||||
|
||||
<div class="row">
|
||||
<div>
|
||||
{{ emojisOutput }}
|
||||
</div>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<script>
|
||||
// Import data/twitter.json to reduce size, all.json contains data for
|
||||
// all emoji sets.
|
||||
import data from "emoji-mart-vue-fast/data/all.json";
|
||||
// Import default CSS
|
||||
import "emoji-mart-vue-fast/css/emoji-mart.css";
|
||||
|
||||
// Vue 2:
|
||||
import { Picker, EmojiIndex } from "emoji-mart-vue-fast";
|
||||
// Vue 3, import components from `/src`:
|
||||
import { Picker, EmojiIndex } from "emoji-mart-vue-fast/src";
|
||||
|
||||
// Create emoji data index.
|
||||
// We can change it (for example, filter by category) before passing to the component.
|
||||
let emojiIndex = new EmojiIndex(data);
|
||||
|
||||
export default {
|
||||
name: "App",
|
||||
components: {
|
||||
Picker
|
||||
},
|
||||
|
||||
data() {
|
||||
return {
|
||||
emojiIndex: emojiIndex,
|
||||
emojisOutput: ""
|
||||
};
|
||||
},
|
||||
|
||||
methods: {
|
||||
showEmoji(emoji) {
|
||||
this.emojisOutput = this.emojisOutput + emoji.native;
|
||||
}
|
||||
}
|
||||
};
|
||||
</script>
|
||||
|
||||
<style>
|
||||
.row { display: flex; }
|
||||
.row > * { margin: auto; }
|
||||
</style>
|
||||
```
|
||||
|
||||
**New TypeScript Interfaces:**
|
||||
- [ ] New type send to server:
|
||||
```typescript
|
||||
export interface EmojiClaim extends ClaimObject {
|
||||
// the "@context" for this is implicitly "https://endorser.ch"
|
||||
"@type": "Emoji";
|
||||
text: string;
|
||||
lastClaimId: string;
|
||||
}
|
||||
export interface EmojiSummaryRecord {
|
||||
issuedAt: string; // date
|
||||
issuerDid: string;
|
||||
jwtId: string;
|
||||
parentItemHandleId: string;
|
||||
text: string;
|
||||
}
|
||||
```
|
||||
- [x] Add `emojiCount` field (map of emoji to count) to `GiveSummaryRecord` interface
|
||||
|
||||
### 6. Test
|
||||
- [ ] Write tests for the front end
|
||||
|
||||
## 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
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user