docs: Add future steps for user verification system design
parent
da659f2130
commit
3b8f8552f8
@ -1 +1,64 @@
|
|||||||
# Task WhatsApp Chatbot
|
# Task WhatsApp Chatbot
|
||||||
|
|
||||||
|
## Future Steps: User Verification System
|
||||||
|
|
||||||
|
### Core Principles
|
||||||
|
1. **Trust-but-Verify Approach**: Leverage WhatsApp's message metadata to minimize API calls while maintaining security
|
||||||
|
2. **Progressive Validation**: Verify users naturally through interactions rather than upfront checks
|
||||||
|
3. **Background Reconciliation**: Use periodic syncs to maintain data accuracy without impacting real-time performance
|
||||||
|
|
||||||
|
### Message Processing Flow
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[Webhook Received] --> B{Valid Payload?}
|
||||||
|
B -->|No| C[Ignore]
|
||||||
|
B -->|Yes| D{From Known Group?}
|
||||||
|
D -->|Yes| E[Update User Last Seen]
|
||||||
|
D -->|No| F{Private Chat + Known User?}
|
||||||
|
F -->|No| C
|
||||||
|
F -->|Yes| E
|
||||||
|
E --> G{/tarea Command?}
|
||||||
|
G -->|No| C
|
||||||
|
G -->|Yes| H{New User?}
|
||||||
|
H -->|Yes| I[Add to DB]
|
||||||
|
H -->|No| J[Process Command]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Database Enhancements
|
||||||
|
- **Users Table Additions**:
|
||||||
|
- `first_seen`: Timestamp of first interaction
|
||||||
|
- `last_seen`: Timestamp of most recent activity
|
||||||
|
- `last_confirmed`: Timestamp of last API verification
|
||||||
|
- `active_groups`: JSON array of groups user was seen in
|
||||||
|
- `verification_status`: Enum (unverified/verified/flagged)
|
||||||
|
|
||||||
|
### Periodic Sync Strategy
|
||||||
|
1. **Rotating Group Check**:
|
||||||
|
- Verify 1-2 groups per sync cycle
|
||||||
|
- Prioritize recently active groups
|
||||||
|
2. **User Reconciliation**:
|
||||||
|
- Add newly discovered users
|
||||||
|
- Update `last_confirmed` for active users
|
||||||
|
- Flag inactive users after N days of no activity
|
||||||
|
3. **Optimizations**:
|
||||||
|
- Cache active group IDs in memory
|
||||||
|
- Batch database writes
|
||||||
|
- Exponential backoff for API failures
|
||||||
|
|
||||||
|
### Security Considerations
|
||||||
|
- Reject messages from:
|
||||||
|
- Non-community groups
|
||||||
|
- Unknown private chats
|
||||||
|
- Implement rate limiting
|
||||||
|
- Maintain audit logs of verification events
|
||||||
|
|
||||||
|
### Future Extensibility
|
||||||
|
1. **User Profiles**:
|
||||||
|
- Store names/profile pictures when available
|
||||||
|
- Track interaction history
|
||||||
|
2. **Reputation System**:
|
||||||
|
- Activity scoring
|
||||||
|
- Trust levels
|
||||||
|
3. **Notification Preferences**:
|
||||||
|
- Per-user settings
|
||||||
|
- Do-not-disturb periods
|
||||||
|
Loading…
Reference in New Issue