# :material-hammer: 3. Development Blueprint

!!! info "What is this section?"
    This document is the official **Development Blueprint** for Smartup Zero's ONLIFE project. It outlines the technical plan for building **Deckpack**, the first application ('browser') for the Onlife network. It is the primary responsibility of the **`3_3_development_team`**.

    - **Attacker (A):** The members of the `3_3_development_team` are the "attackers" who build the application and propose the technical solutions.
    - **Defender (D):** The `4_1_3_tc_development_team` (the Team Captain) is the "defender," responsible for code reviews and ensuring the implementation aligns with the Science and Design blueprints.
    - **Midfielder (M):** The `Engelbot` is the "midfielder," automating builds, tests, and deployments.

## 1. Mission Summary

Our mission is to build the first stable, secure, and cross-platform version of Deckpack, successfully implementing the Onlife protocol to create a functional lifeline for citizens in emergencies.

## 2. Main Part: The Deckpack Application Architecture

Deckpack is the application layer that makes the Onlife network's power accessible. While the **Science Blueprint** defines the protocol theory, this document defines how we will *implement* that theory in a functional mobile application.

### 2.1. The Deckpack Application: The First "Browser" for Onlife
Deckpack is a mobile app that allows groups of people in a disaster area or communication blackout to form temporary, self-sustaining networks. Within these secure `Groups`, citizens can use crisis-specific tools (`Plugins`) to share vital information (`Cards`).

The development focus is on creating a modular and scalable architecture that can be extended by our partners in the future, while ensuring the initial MVP is robust and reliable for its core life-saving mission.

### 2.2. MVP App Architecture Principles
The application will be built on three core architectural principles:

1.  **Protocol-Centric:** The app's primary function is to be a faithful and efficient implementation of the **Onlife Mesh Protocol** as defined in the Science Blueprint. All networking logic will be handled by a dedicated, sandboxed service layer that runs the UDP-based protocol.
2.  **Modular & Scalable:** The architecture will clearly separate the core protocol service from the UI and the `Plugin` framework. This allows us to update the UI without touching the network code, and allows new plugins to be added without destabilizing the core application.
3.  **Cross-Platform by Design:** While the initial MVP will likely target Android due to its hardware accessibility, the architecture will be designed with iOS compatibility in mind from day one, using clean interfaces between the protocol layer and the platform-specific UI.

```mermaid
graph TD
    subgraph Smartphone
        A[Hardware - Wi-Fi]
        B[Operating System - Android/iOS]
        C[Deckpack Application]
        D[Onlife Protocol Service]
    end

    C -- "Talks to" --> D
    D -- "Controls" --> A
    C -- "Runs on" --> B
    B -- "Manages" --> A
```
*Figure: The relationship between the Deckpack App, the Onlife Protocol Service, and the underlying device hardware.*

### 2.3. Core Components to Be Built
The development work is broken down into these key functional components:

#### Group Management
The app must manage a citizen's membership in local `Groups`.
-   **Discovery:** Implement the network scanning logic from the Science Blueprint to find nearby `Onlife Groups` by matching the predefined SSID pattern.
-   **Connection:** Build the connection logic that allows a user to securely join a `Group`.
-   **Host Functions:** For the MVP, the "Group Host" is abstract. The core app must simply connect to the default, public `Onlife Group`. The framework for third-party `Context Groups` will be built in a later version.

#### Plugin Framework (SDK)
This is a critical component for long-term success.
-   **Plugin Loader:** Develop a mechanism to automatically discover and install the `Plugins` that are designated for a specific `Group`.
-   **Sandboxed Environment:** Ensure plugins run in a secure, isolated context. They must not have access to the core protocol service or data from other plugins unless explicitly permitted.
-   **API Definition:** Create the clear API that allows a `Plugin` to request network actions (like creating and publishing a `Card`) from the core Deckpack application.

#### Card-Based Interactions
The Development Team will build the UI systems to support the "Card Game" metaphor from the Design Blueprint.
-   **Card Renderer:** Create a flexible UI component that can display different types of `Cards` based on the data provided by a `Plugin`.
-   **Interaction Logic:** Implement the `Hand` and `Stage` concepts, allowing a user to manage their private cards and view the shared, public cards of the group.
-   **Gesture Engine:** Build the gesture handlers (swipe up, down, left, right) for interacting with cards, as defined by the Design Team.

#### Security & Data Control
Security is not a feature; it is a foundational requirement.
-   **Encryption:** While the Onlife protocol is insecure by design, the Deckpack application **must** ensure that all sensitive `Card` data is end-to-end encrypted before it is passed to the protocol layer for transmission.
-   **Secure Storage:** User-generated `Cards` and private keys must be stored in the device's most secure storage (e.g., Android Keystore).
-   **Permissions:** A `Plugin` must explicitly declare what data and permissions it needs, and the user must grant consent.

## 3. Submissions: The Development Roadmap
To build the MVP, we will complete the following major technical submissions.

| Objective ID | Submission Title | Core Goal | Status |
| :--- | :--- | :--- | :--- |
| `5_1_3_3...` | **Build the Core Protocol Service** | To create a stable, background Android service that successfully implements the Onlife protocol for discovering and connecting to nodes. | :material-calendar: Planned |
| `5_2_3_3...` | **Build the MVP Application Shell** | To develop the basic Deckpack UI, including the `Group` discovery screen, the shared `Stage`, and the private `Hand`. | :material-calendar: Planned |
| `5_3_3_3...` | **Implement the First Plugin Pack** | To integrate the `SOS` and `Aid` plugins, allowing users to create, publish, and view live `SOS` and `Aid` cards on the network. | :material-calendar: Planned |

## 4. Role Management: Call for Contributions
To build a platform of this complexity, we need a diverse and skilled development team.

| Role ID | Role Title | Your Mission If You Join |
| :--- | :--- | :--- |
| `4_4_3` | **Android Developer** | You will build the core Deckpack application shell and UI components in Kotlin, bringing the design to life. |
| `4_6_3` | **iOS Developer** | You will lead the effort to port the Deckpack architecture and Onlife service to the iOS platform, ensuring we can reach all citizens. |
| `4_10_3` | **Network Protocol Engineer** | You will specialize in the low-level implementation of the Onlife protocol, optimizing routing, connection, and discovery. |
| `4_5_3` | **QA & Test Engineer** | You will build the automated testing suites that simulate network chaos to ensure Deckpack is truly resilient when it's needed most. |

## 5. Team Budget

| Item | Value (SC) | Status |
| :--- | :--- | :--- |
| **Total Phase 1 Budget:** | 0 | Awaiting initial crowdfunding |
| **SC Minted to Date:** | 0 | - |
| **Remaining Budget:** | 0 | Our first goal is to meet the Validation Phase crowdfunding target. |
