3. Development Blueprint¶

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:

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.
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.
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.

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.	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`.	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.	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.