1 changed files with 91 additions and 0 deletions
@ -0,0 +1,91 @@ |
|||||
|
# Time Safari Context |
||||
|
|
||||
|
## Project Overview |
||||
|
|
||||
|
Time Safari is a progressive web application designed to foster community building through gifts, gratitude, and collaborative projects. It provides a platform where users can recognize contributions, build trust networks, and organize collective action while maintaining privacy and data sovereignty. |
||||
|
|
||||
|
## Core Purpose |
||||
|
|
||||
|
The primary goal of Time Safari is to help everyday users build meaningful connections and organize collective efforts by: |
||||
|
|
||||
|
1. **Recognizing Contributions**: Creating permanent, verifiable records of gifts and contributions people make to each other and their communities. |
||||
|
|
||||
|
2. **Facilitating Collaboration**: Making it ridiculously easy for people to ask for or propose help on projects that matter to them. |
||||
|
|
||||
|
3. **Building Trust Networks**: Enabling users to develop reputation through verified contributions and references. |
||||
|
|
||||
|
4. **Preserving Privacy**: Ensuring personal identifiers are only shared with explicitly authorized contacts, allowing private individuals and children to participate safely. |
||||
|
|
||||
|
5. **Organizing Collective Action**: Providing tools for people to learn how to organize and act together voluntarily. |
||||
|
|
||||
|
## Technical Foundation |
||||
|
|
||||
|
This application is built on a privacy-preserving claims architecture (via endorser.ch) with these key characteristics: |
||||
|
|
||||
|
- **Decentralized Identifiers (DIDs)**: User identities are based on public/private key pairs stored on their devices |
||||
|
- **Cryptographic Verification**: All claims and confirmations are cryptographically signed |
||||
|
- **User-Controlled Visibility**: Users explicitly control who can see their identifiers and data |
||||
|
- **Merkle-Chained Claims**: Claims are cryptographically chained for verification and integrity |
||||
|
- **Progressive Web App**: Works across devices and can be installed locally |
||||
|
|
||||
|
## User Journey |
||||
|
|
||||
|
The typical progression of usage follows these stages: |
||||
|
|
||||
|
1. **Gratitude & Recognition**: Users begin by expressing and recording gratitude for gifts received, building a foundation of acknowledgment. |
||||
|
|
||||
|
2. **Project Proposals**: Users propose projects and ideas, reaching out to connect with others who share similar interests. |
||||
|
|
||||
|
3. **Collaborative Organization**: Groups form around shared interests, organizing their activities with varying levels of formality. |
||||
|
|
||||
|
4. **Action Triggers**: Offers of help serve as triggers and motivations to execute proposed projects, moving from ideas to action. |
||||
|
|
||||
|
## Context for LLM Development |
||||
|
|
||||
|
When developing new functionality for Time Safari, consider these design principles: |
||||
|
|
||||
|
1. **Accessibility First**: Features should be usable by non-technical users with minimal learning curve. |
||||
|
|
||||
|
2. **Privacy by Design**: All features must respect user privacy and data sovereignty. |
||||
|
|
||||
|
3. **Progressive Enhancement**: Core functionality should work across all devices, with richer experiences where supported. |
||||
|
|
||||
|
4. **Voluntary Collaboration**: The system should enable but never coerce participation. |
||||
|
|
||||
|
5. **Trust Building**: Features should help build verifiable trust between users. |
||||
|
|
||||
|
6. **Network Effects**: Consider how features scale as more users join the platform. |
||||
|
|
||||
|
7. **Low Resource Requirements**: The system should be lightweight enough to run on inexpensive devices users already own. |
||||
|
|
||||
|
## Use Cases to Support |
||||
|
|
||||
|
LLM development should focus on enhancing these key use cases: |
||||
|
|
||||
|
1. **Community Building**: Tools that help people find others with shared interests and values. |
||||
|
|
||||
|
2. **Project Coordination**: Features that make it easy to propose, organize, and track collaborative projects. |
||||
|
|
||||
|
3. **Reputation Building**: Methods for users to develop and showcase their contributions and reliability. |
||||
|
|
||||
|
4. **Knowledge Sharing**: Ways to share skills and information within trusted networks. |
||||
|
|
||||
|
5. **Resource Coordination**: Tools to match needs with available resources (especially time contributions). |
||||
|
|
||||
|
6. **Governance Experimentation**: Features that facilitate democratic decision-making and collective governance. |
||||
|
|
||||
|
## Constraints |
||||
|
|
||||
|
When developing new features, be mindful of these constraints: |
||||
|
|
||||
|
1. **Privacy Preservation**: User identifiers must remain private except when explicitly shared. |
||||
|
|
||||
|
2. **Progressive Web App Limitations**: Features must work within PWA constraints. |
||||
|
|
||||
|
3. **Endorser API Limitations**: Backend features are constrained by the endorser.ch API capabilities. |
||||
|
|
||||
|
4. **Performance on Low-End Devices**: The application should remain performant on older/simpler devices. |
||||
|
|
||||
|
5. **Offline-First When Possible**: Key functionality should work offline when feasible. |
||||
|
|
||||
|
Remember that the ultimate goal is to help people recognize each other's contributions, build trust, and organize meaningful collective action - all while preserving individual agency and privacy. |
Loading…
Reference in new issue