Skip to content

Commit 2bcdcdc

Browse files
QSchlegelQSchlegel
authored
Merge pull request #136 from MeshJS/feature/CBOR-Integration
Add Taskhandling and initial Task
2 parents 8fe216c + beaed6c commit 2bcdcdc

File tree

2 files changed

+390
-0
lines changed

2 files changed

+390
-0
lines changed

‎tasks/Task_template.md‎

Lines changed: 230 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,230 @@
1+
# Task Template
2+
3+
## 1. Task Overview
4+
**Brief description of what needs to be built or implemented**
5+
6+
### Problem Statement
7+
- What problem does this solve?
8+
- Who is affected by this problem?
9+
- What is the current state vs. desired state?
10+
11+
### Solution Overview
12+
- High-level description of the proposed solution
13+
- Key benefits and value proposition
14+
15+
## 2. Requirements
16+
17+
### User Stories
18+
```
19+
As a [user type], I want [functionality] so that [benefit/value]
20+
```
21+
22+
### Functional Requirements
23+
- **FR-1**: [Requirement description]
24+
- **FR-2**: [Requirement description]
25+
- **FR-3**: [Requirement description]
26+
27+
### Non-Functional Requirements
28+
- **NFR-1**: [Performance, security, scalability requirements]
29+
- **NFR-2**: [Usability, accessibility requirements]
30+
- **NFR-3**: [Compatibility, integration requirements]
31+
32+
## 3. Technical Specifications
33+
34+
### Architecture Overview
35+
- High-level system architecture
36+
- Key components and their interactions
37+
38+
### API Specifications
39+
- Endpoints and methods
40+
- Request/response schemas
41+
- Authentication and authorization
42+
43+
### Database Schema
44+
- Entity relationships
45+
- Key tables and fields
46+
- Data migration requirements
47+
48+
### Integration Points
49+
- External services/APIs
50+
- Third-party dependencies
51+
- Internal system integrations
52+
53+
## 4. Implementation Plan
54+
55+
### Development Phases
56+
- **Phase 1**: [Scope and timeline]
57+
- **Phase 2**: [Scope and timeline]
58+
- **Phase 3**: [Scope and timeline]
59+
60+
### Dependencies
61+
- External dependencies
62+
- Internal team dependencies
63+
- Infrastructure requirements
64+
65+
### Risk Assessment
66+
- **High Risk**: [Risk description and mitigation]
67+
- **Medium Risk**: [Risk description and mitigation]
68+
- **Low Risk**: [Risk description and mitigation]
69+
70+
## 5. Testing Strategy
71+
72+
### Test Cases
73+
- **TC-1**: [Test scenario and expected outcome]
74+
- **TC-2**: [Test scenario and expected outcome]
75+
- **TC-3**: [Test scenario and expected outcome]
76+
77+
### Testing Types
78+
- Unit testing
79+
- Integration testing
80+
- End-to-end testing
81+
- Performance testing
82+
- Security testing
83+
84+
### Acceptance Criteria
85+
- Definition of Done
86+
- Quality gates
87+
- Performance benchmarks
88+
89+
## 6. Code Analysis & Implementation Details
90+
91+
### Key Issues Identified
92+
- **Issue 1**: [Description and location]
93+
- **Issue 2**: [Description and location]
94+
- **Issue 3**: [Description and location]
95+
96+
### Code References
97+
- **Files to Modify**: [List of key files]
98+
- **Authentication Integration**: [How to integrate with existing auth]
99+
- **Frontend Integration**: [How to integrate with existing UI]
100+
101+
### Implementation Examples
102+
```typescript
103+
// Example code snippets for key implementations
104+
export function exampleFunction() {
105+
// Implementation details
106+
}
107+
```
108+
109+
## 7. Next Steps
110+
1. **Step 1**: [First action to take]
111+
2. **Step 2**: [Second action to take]
112+
3. **Step 3**: [Third action to take]
113+
114+
---
115+
116+
## Usage Instructions
117+
118+
1. **Fill in each section** with specific details for your task
119+
2. **Remove sections** that are not applicable to your specific use case
120+
3. **Add additional sections** as needed for your project
121+
4. **Focus on implementation details** and code references
122+
5. **Keep it concise** - this is for task explanation, not full PRD
123+
124+
## Developer IDE Workflow
125+
126+
### Getting Started with This Task
127+
128+
**For Developers using this task in their IDE:**
129+
130+
1. **Open the task** in your IDE alongside your code editor
131+
- Use split-screen or multiple tabs to keep the task visible while coding
132+
- Consider using IDE extensions for markdown preview if available
133+
134+
2. **Start with Requirements Analysis**
135+
- Read through the Functional Requirements (FR-1, FR-2, etc.)
136+
- Map each requirement to specific code modules/components
137+
- Create TODO comments in your code referencing requirement IDs
138+
139+
3. **Use the Technical Specifications Section**
140+
- Reference API specifications when implementing endpoints
141+
- Follow the database schema for data modeling
142+
- Use integration points to understand external dependencies
143+
144+
4. **Implement with User Stories in Mind**
145+
- Keep user stories visible while coding
146+
- Write code that directly addresses the "so that [benefit]" part
147+
- Test your implementation against the acceptance criteria
148+
149+
### IDE-Specific Tips
150+
151+
**VS Code Users:**
152+
- Install "Markdown Preview Enhanced" extension for better task viewing
153+
- Use "TODO Tree" extension to track requirements as TODOs in code
154+
- Set up workspace with task and code side-by-side
155+
156+
**JetBrains IDEs (IntelliJ, WebStorm, etc.):**
157+
- Use the built-in markdown preview
158+
- Create TODO comments with requirement references: `// TODO: FR-1 - Implement user authentication`
159+
- Use the TODO tool window to track progress
160+
161+
**Vim/Neovim Users:**
162+
- Use markdown preview plugins like `markdown-preview.nvim`
163+
- Set up split windows with task on one side, code on the other
164+
- Use quickfix lists for TODO tracking
165+
166+
### Code Organization Strategy
167+
168+
1. **Create Feature Branches** based on task sections
169+
- `feature/user-authentication` (from FR-1)
170+
- `feature/api-integration` (from Technical Specifications)
171+
- `feature/ux-implementation` (from Requirements section)
172+
173+
2. **Use Commit Messages** that reference task sections
174+
```
175+
feat: implement user authentication (FR-1)
176+
fix: resolve API integration issue (Technical Specs - API)
177+
test: add test cases for user journey (Testing Strategy - TC-1)
178+
```
179+
180+
3. **Create Code Comments** linking back to task
181+
```typescript
182+
/**
183+
* Implements FR-1: User Authentication
184+
* Supports user stories: "As a user, I want to log in securely"
185+
* Acceptance criteria: User can authenticate with valid credentials
186+
*/
187+
export class AuthService {
188+
// Implementation here
189+
}
190+
```
191+
192+
### Progress Tracking
193+
194+
1. **Mark Requirements as Complete**
195+
- Update the task with implementation status
196+
- Use checkboxes: `- [x] FR-1: User authentication (COMPLETED)`
197+
- Add implementation notes and code references
198+
199+
2. **Track Issues and Blockers**
200+
- Document any deviations from the task
201+
- Note technical constraints discovered during implementation
202+
- Update risk assessment based on actual development experience
203+
204+
3. **Regular Task Reviews**
205+
- Review task weekly during development
206+
- Update requirements based on new insights
207+
- Ensure code implementation aligns with documented requirements
208+
209+
### Integration with Development Tools
210+
211+
**Git Integration:**
212+
- Link task sections to specific commits
213+
- Use task requirements in pull request descriptions
214+
- Reference task in code review comments
215+
216+
**Project Management:**
217+
- Create tickets/tasks based on task sections
218+
- Link development tasks to specific requirements
219+
- Use task as source of truth for sprint planning
220+
221+
**Documentation:**
222+
- Keep task updated as implementation progresses
223+
- Add code examples and implementation details
224+
- Document any architectural decisions made during development
225+
226+
## Notes
227+
- This template should be customized based on your specific needs
228+
- Consider the complexity and scope of your project when deciding which sections to include
229+
- Regular reviews and updates are essential to keep the task current and useful
230+
- **Keep the task as a living document** - update it as you learn more during development

‎tasks/wishlist/Task_01_Integration.md‎

Lines changed: 160 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,160 @@
1+
# Task: Summon Platform Ejection Integration
2+
3+
## 1. Task Overview
4+
**Ejection system for users from Summon platform with staking key-based payment credentials**
5+
6+
### Problem Statement
7+
- **What problem does this solve?**: Users from the Summon platform (being shutdown) need to eject their multisig wallets that sometimes reuse staking keyhashes as payment credentials, breaking our current logic that expects separate payment keys
8+
- **Who is affected by this problem?**: Users ejecting from Summon platform, governance participants, DeFi users with staking-integrated wallets
9+
- **What is the current state vs. desired state?**: Current state has incompatible wallet validation and creation logic; desired state supports seamless ejection with staking key compatibility
10+
11+
### Solution Overview
12+
- **High-level description**: Create an ejection integration that handles staking key-based payment credentials with a redirect endpoint that prefills the wallet creation flow
13+
- **Key benefits**: Seamless user ejection, preserved wallet functionality, enhanced platform compatibility
14+
15+
## 2. Requirements
16+
17+
### User Stories
18+
```
19+
As a user on Summon platform, I want to eject my multisig wallet so that I can continue using it on the Mesh multisig platform.
20+
21+
As a user with staking key-based payment credentials, I want the system to recognize and properly handle my wallet configuration so that all features work correctly.
22+
23+
As a user ejecting from Summon, I want the wallet creation flow to be prefilled with my existing wallet data so that the transition is seamless.
24+
25+
As a platform administrator, I want to validate ejected wallet data against Summon's records so that only legitimate wallets are created.
26+
```
27+
28+
### Functional Requirements
29+
- **FR-1**: Redirect endpoint that accepts ejection parameters and prefills wallet creation flow
30+
- **FR-2**: Staking key detection and validation system
31+
- **FR-3**: Payment credential logic that handles both traditional and staking key-based credentials
32+
- **FR-4**: Ejection validation and error handling with Summon data verification
33+
- **FR-5**: Locked wallet creation flow (no adding new signers) to preserve existing multisig structure
34+
- **FR-6**: Wallet address validation against Summon's original data
35+
36+
### Non-Functional Requirements
37+
- **NFR-1**: Ejection process must complete within 5 minutes, system must handle concurrent ejections without performance degradation
38+
- **NFR-2**: Full accessibility for ejection flow, WCAG 2.1 AA compliance, screen reader support
39+
- **NFR-3**: All existing functionality must remain unaffected, comprehensive logging and monitoring
40+
41+
## 3. Technical Specifications
42+
43+
### Architecture Overview
44+
- **Ejection Service**: Handles wallet validation and data transformation from Summon
45+
- **Redirect Handler**: Processes incoming ejection requests and prefills wallet creation data
46+
- **Key Compatibility Layer**: Manages different credential types and their interactions
47+
- **Validation Engine**: Ensures ejected wallets meet system requirements and match Summon data
48+
49+
### API Specifications
50+
- **Endpoints and methods**: POST `/api/v1/ejection/redirect`
51+
- **Request/response schemas**: JSON with wallet_data, summon_validation_token, rate_limit_info, wallet_connection_required fields
52+
- **Authentication and authorization**: Rate limiting with wallet connection requirement for wallet creation
53+
54+
### Database Schema
55+
- **Entity relationships**: No schema changes needed - existing Wallet model supports ejection
56+
- **Key tables and fields**: signersAddresses, signersStakeKeys, scriptCbor, stakeCredentialHash
57+
- **Data ejection requirements**: Populate both payment and staking key arrays appropriately, mark as ejected from Summon
58+
59+
### Integration Points
60+
- **External services/APIs**: Summon platform API for ejection validation, rate limiting service for request throttling
61+
- **Third-party dependencies**: Mesh SDK for address resolution, wallet connection libraries
62+
- **Internal system integrations**: Wallet connection system, wallet management, staking infrastructure
63+
64+
## 4. Implementation Plan
65+
66+
### Development Phases
67+
- **Phase 1**: Compatibility layer and address resolution (Week 1)
68+
- **Phase 2**: Ejection redirect endpoint and prefill system (Week 2)
69+
- **Phase 3**: Core logic updates and locked wallet creation flow (Week 3-4)
70+
- **Phase 4**: Testing and validation with Summon integration (Week 5)
71+
- **Phase 5**: Deployment and monitoring (Week 6)
72+
73+
### Dependencies
74+
- **External dependencies**: Summon platform API access for validation, rate limiting service configuration, wallet connection libraries
75+
- **Internal team dependencies**: Frontend team for UI updates, backend team for API development
76+
- **Infrastructure requirements**: Database access, API gateway updates
77+
78+
### Risk Assessment
79+
- **High Risk**: Breaking existing wallet functionality during compatibility updates
80+
- **Medium Risk**: Performance impact of additional validation logic, Summon API dependency
81+
- **Low Risk**: User experience issues with ejection flow
82+
83+
## 5. Testing Strategy
84+
85+
### Test Cases
86+
- **TC-1**: Successful ejection of staking key-based wallet from Summon
87+
- **TC-2**: Validation of incompatible wallet configurations
88+
- **TC-3**: Redirect endpoint with various parameter combinations from Summon
89+
- **TC-4**: Error handling for rate limit exceeded and wallet connection failures
90+
- **TC-5**: Performance testing with concurrent ejections
91+
- **TC-6**: Locked wallet creation flow (no adding new signers)
92+
- **TC-7**: Wallet address validation against Summon's original data
93+
94+
### Testing Types
95+
- **Unit testing**: Individual component validation
96+
- **Integration testing**: End-to-end ejection flow
97+
- **End-to-end testing**: Complete user journey testing from Summon to Mesh
98+
- **Performance testing**: Concurrent ejection load testing
99+
- **Security testing**: Rate limiting validation and wallet connection security
100+
101+
### Acceptance Criteria
102+
- **Definition of Done**: All staking key-based wallets successfully eject from Summon, no regression in existing functionality
103+
- **Quality gates**: Ejection success rate >95%, error rate <1%
104+
- **Performance benchmarks**: Ejection completion within 5 minutes
105+
106+
## 6. Code Analysis & Implementation Details
107+
108+
### Key Issues Identified
109+
- **Issue 1**: Payment credential resolution fails for staking key addresses (`src/utils/common.ts:35`)
110+
- **Issue 2**: Address validation functions reject staking key-based addresses (`src/utils/multisigSDK.ts:303-310`)
111+
- **Issue 3**: Native script generation assumes payment key hashes exist (`src/utils/common.ts:97-103`)
112+
- **Issue 4**: Multisig wallet building doesn't handle staking key as payment credential (`src/utils/common.ts:20-81`)
113+
- **Issue 5**: Wallet creation flow needs to be locked to prevent adding new signers for ejected wallets
114+
115+
### Code References
116+
- **Files to Modify**:
117+
- `src/utils/common.ts` - Core wallet building logic
118+
- `src/hooks/common.ts` - Hook-based wallet building
119+
- `src/utils/multisigSDK.ts` - Address validation functions
120+
- `src/pages/wallets/new-wallet-flow/` - UI components
121+
- `src/pages/api/v1/` - New ejection endpoint
122+
- **Rate Limiting Integration**: Implement rate limiting middleware, follow CORS pattern from `src/lib/cors.ts`
123+
- **Frontend Integration**: Extend existing wallet flow state management in `src/components/pages/homepage/wallets/new-wallet-flow/shared/useWalletFlowState.tsx`
124+
125+
### Implementation Examples
126+
```typescript
127+
// src/utils/addressCompatibility.ts
128+
export function resolveKeyHash(address: string): { keyHash: string; role: number; type: 'payment' | 'staking' } {
129+
try {
130+
const paymentHash = resolvePaymentKeyHash(address);
131+
return { keyHash: paymentHash, role: 0, type: 'payment' };
132+
} catch {
133+
try {
134+
const stakeHash = resolveStakeKeyHash(address);
135+
return { keyHash: stakeHash, role: 0, type: 'staking' }; // Use as payment credential
136+
} catch {
137+
throw new Error('Invalid address format');
138+
}
139+
}
140+
}
141+
142+
// src/pages/api/v1/ejection/redirect.ts
143+
export default async function handler(req: NextApiRequest, res: NextApiResponse) {
144+
// 1. Apply rate limiting (e.g., 10 requests per minute per IP)
145+
// 2. Validate Summon ejection token
146+
// 3. Extract wallet configuration data from Summon
147+
// 4. Detect staking key compatibility issues
148+
// 5. Validate wallet address against Summon's original data
149+
// 6. Generate prefill data for locked wallet creation flow
150+
// 7. Return redirect URL: /wallets/invite/{inviteId} with prefill parameters
151+
// 8. Require wallet connection before allowing wallet creation
152+
}
153+
```
154+
155+
## 7. Next Steps
156+
1. **Create Compatibility Layer**: Implement enhanced address resolution functions
157+
2. **Build Ejection Endpoint**: Create API endpoint with rate limiting and wallet connection requirements
158+
3. **Update Core Logic**: Modify wallet building and validation functions
159+
4. **Frontend Integration**: Update UI components to handle staking key addresses and locked wallet creation
160+
5. **Testing**: Comprehensive testing with real ejection scenarios from Summon

0 commit comments

Comments
 (0)