doc: various
This commit is contained in:
@@ -1,6 +1,4 @@
|
|||||||
---
|
---
|
||||||
description:
|
|
||||||
globs:
|
|
||||||
alwaysApply: false
|
alwaysApply: false
|
||||||
---
|
---
|
||||||
# Time Safari / Endorser Search Tech Ecosystem
|
# Time Safari / Endorser Search Tech Ecosystem
|
||||||
|
|||||||
@@ -1,9 +1,7 @@
|
|||||||
---
|
---
|
||||||
description: Endorser-ch API pagination conventions and database migration documentation
|
|
||||||
globs: repos/endorser-ch/src/**
|
globs: repos/endorser-ch/src/**
|
||||||
alwaysApply: true
|
alwaysApply: false
|
||||||
---
|
---
|
||||||
|
|
||||||
# Endorser-ch Development Conventions
|
# Endorser-ch Development Conventions
|
||||||
|
|
||||||
# Pagination Conventions
|
# Pagination Conventions
|
||||||
|
|||||||
Symlink
+1
@@ -0,0 +1 @@
|
|||||||
|
../.cursorrules
|
||||||
@@ -0,0 +1,67 @@
|
|||||||
|
# Endorser.ch Context
|
||||||
|
|
||||||
|
## Project Overview
|
||||||
|
Endorser.ch is an API for creating and querying claims in privacy-preserving ways. The system allows users to make cryptographically signed claims (attestations) and confirmations while maintaining control over their personal identifiers' visibility.
|
||||||
|
|
||||||
|
## Core Principles
|
||||||
|
|
||||||
|
1. **Privacy-Preserving**: Store and retrieve textual data publicly while ensuring identifier visibility is fully controlled by each user.
|
||||||
|
|
||||||
|
2. **Accessibility**: Provide service without cost to users in selected communities, with rate-limiting to manage usage.
|
||||||
|
|
||||||
|
3. **Verification**: Support only cryptographically signed claims and confirmations, ensuring authenticity.
|
||||||
|
|
||||||
|
4. **Discovery**: Enable discovery of other users through visibility networks or users' preferred messaging networks.
|
||||||
|
|
||||||
|
5. **Utility**: Support specific use cases like counting confirmations or aggregating claim totals.
|
||||||
|
|
||||||
|
## Key Technical Concepts
|
||||||
|
|
||||||
|
### Decentralized Identifiers (DIDs)
|
||||||
|
- The system uses DIDs as the primary user identification mechanism
|
||||||
|
- Visibility of DIDs is controlled by the user
|
||||||
|
- Hidden DIDs are represented as `HIDDEN_TEXT` in responses
|
||||||
|
|
||||||
|
### Claims and Confirmations
|
||||||
|
- Claims are attestations made by users about events, actions, or tenures
|
||||||
|
- Confirmations are verification of claims by other users
|
||||||
|
- All claims and confirmations are cryptographically signed using JWTs
|
||||||
|
|
||||||
|
### Merkle-Chained Claims
|
||||||
|
- Claims are chained together using cryptographic merkle hashes
|
||||||
|
- The entire system maintains a most-recent merkle hash of all claims
|
||||||
|
- Each user has their own most-recent merkle hash available
|
||||||
|
- Observers with visibility permissions can verify they have the latest data
|
||||||
|
- This enables data integrity verification for both individual users and the entire system
|
||||||
|
- Supports efficient synchronization and verification of claim histories
|
||||||
|
|
||||||
|
### Visibility Control
|
||||||
|
- Users explicitly control who can see their identifiers
|
||||||
|
- Visibility can be granted or revoked between users
|
||||||
|
- Claims may be visible but with identifiers hidden
|
||||||
|
|
||||||
|
### Location-Based Features
|
||||||
|
- System supports geospatial data for claims and profiles
|
||||||
|
- Location data can be searched and retrieved in privacy-preserving ways
|
||||||
|
- Tile-based location indexing for efficient spatial queries
|
||||||
|
|
||||||
|
### User Profiles
|
||||||
|
- Users can create and update profiles with descriptions and locations
|
||||||
|
- Profiles are searchable by text and location
|
||||||
|
- Visibility rules apply to profile data
|
||||||
|
|
||||||
|
## Implementation Goals
|
||||||
|
|
||||||
|
1. Simple-to-deploy service with minimal dependencies
|
||||||
|
2. Fast response times for common operations
|
||||||
|
3. Well-defined rules for visibility and access control
|
||||||
|
4. Scalable architecture for growing user bases
|
||||||
|
5. Resistance to abuse through rate-limiting and verification requirements
|
||||||
|
|
||||||
|
## Intended Use Cases
|
||||||
|
|
||||||
|
1. Attendance verification for events
|
||||||
|
2. Community participation tracking
|
||||||
|
3. Location-based claim verification
|
||||||
|
4. Peer-to-peer endorsements with privacy controls
|
||||||
|
5. Building trust networks with controlled visibility
|
||||||
+82
-21
@@ -17,39 +17,40 @@ Allow people to attach an emoji onto a record. The main entity to which emojis w
|
|||||||
|
|
||||||
### 2. Database Schema Design
|
### 2. Database Schema Design
|
||||||
**New Field on `give_claim`: `emojiCount`**
|
**New Field on `give_claim`: `emojiCount`**
|
||||||
- [ ] map of emoji character key to numeric count of that emoji
|
- [x] map of emoji character key to numeric count of that emoji
|
||||||
|
|
||||||
**New Table `emoji_claim`**
|
**New Table `emoji_claim`**
|
||||||
- [ ] Standard claim fields: `jwtId`, `issuerDid`, `issuedAt`
|
- [x] Standard claim fields: `jwtId`, `issuerDid`, `issuedAt`
|
||||||
- [ ] Emoji-specific fields: `text`, `parentItemHandleId`
|
- [x] Emoji-specific fields: `text`, `parentItemHandleId`
|
||||||
|
|
||||||
**Database Migration**
|
**Database Migration**
|
||||||
- [ ] Create new `emoji_claim` table following existing patterns
|
- [x] Create new `emoji_claim` table following existing patterns
|
||||||
- [ ] Add `emojiCount` column to `give_claim` tables
|
- [x] Add `emojiCount` column to `give_claim` tables
|
||||||
- [ ] Indexes on `parentItemHandleId` & `issuerDid` for efficient retrieval
|
- [x] Indexes on `parentItemHandleId` & `issuerDid` for efficient retrieval
|
||||||
|
- [x] Update sql/README.md with new schema (following development conventions)
|
||||||
|
|
||||||
### 3. API Endpoint Design
|
### 3. API Endpoint Design
|
||||||
**Submission Endpoint:**
|
**Submission Endpoint:**
|
||||||
- [ ] `POST /api/v2/claim` (reuse existing claim submission)
|
- [x] `POST /api/v2/claim` (reuse existing claim submission)
|
||||||
- [ ] Validate Emoji contents: text, lastClaimId
|
- [x] Validate Emoji contents: text, lastClaimId
|
||||||
- [ ] 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] 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.)
|
||||||
- [ ] Store in `emoji_claim` table
|
- [x] Store in `emoji_claim` table
|
||||||
- [ ] Update `give_claim` `emojiCount`
|
- [x] Update `give_claim` `emojiCount`
|
||||||
- [ ] Return standard claim response with `claimId` and `handleId`
|
- [x] Return standard claim response with `claimId` and `handleId`
|
||||||
- [ ] Add to emoji count of the parent if `give_claim`
|
- [x] Add to emoji count of the parent if `give_claim`
|
||||||
- [ ] 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
|
- [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:**
|
**New Retrieval Endpoints:**
|
||||||
- [ ] `GET /api/v2/report/emoji?parentHandleId=<handleId>` gets all active `emoji_claim` records for an item, paged
|
- [x] `GET /api/v2/report/emoji?parentHandleId=<handleId>` gets all active `emoji_claim` records for an item, paged
|
||||||
|
|
||||||
**Modify existing endpoints:**
|
**Modify existing endpoints:**
|
||||||
- [ ] Update `dbService.getGives*` methods to include emoji counts
|
- [x] Update `dbService.getGives*` methods to include emoji counts
|
||||||
- [ ] Update types and API documentation
|
- [x] Update types and API documentation
|
||||||
|
|
||||||
**API Documentation**
|
**API Documentation**
|
||||||
- [ ] Update Swagger documentation for new endpoints
|
- [x] Update Swagger documentation for new endpoints
|
||||||
- [ ] Document Emoji claim structure
|
- [x] Document Emoji claim structure
|
||||||
- [ ] Provide examples of emoji submission and retrieval
|
- [x] Provide examples of emoji submission and retrieval
|
||||||
|
|
||||||
**Authentication & Authorization**
|
**Authentication & Authorization**
|
||||||
- Emojis require valid JWT authentication (like other claims)
|
- Emojis require valid JWT authentication (like other claims)
|
||||||
@@ -57,7 +58,7 @@ Allow people to attach an emoji onto a record. The main entity to which emojis w
|
|||||||
- Users can retrieve all emoji taggers on a particular GiveAction, though DIDs are subject to visibility constraints
|
- Users can retrieve all emoji taggers on a particular GiveAction, though DIDs are subject to visibility constraints
|
||||||
|
|
||||||
**Test**
|
**Test**
|
||||||
- [ ] Write tests for each case on the back end (multiple emojis, removal, etc) in a new test file
|
- [x] Write tests for each case on the back end (multiple emojis, removal, etc) in a new test file
|
||||||
|
|
||||||
### 5. Client-Side
|
### 5. Client-Side
|
||||||
**Add to UI**
|
**Add to UI**
|
||||||
@@ -67,6 +68,66 @@ Allow people to attach an emoji onto a record. The main entity to which emojis w
|
|||||||
- [ ] Show the previous emojis with their count, with data from GiveSummaryRecord
|
- [ ] Show the previous emojis with their count, with data from GiveSummaryRecord
|
||||||
- [ ] Clicking on an emoji already sent from this person removes it
|
- [ ] 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 TypeScript Interfaces:**
|
||||||
- [ ] New type send to server:
|
- [ ] New type send to server:
|
||||||
```typescript
|
```typescript
|
||||||
|
|||||||
Reference in New Issue
Block a user