Layer 1 introduced the foundational data and application layer of the Safebox ecosystem. Communities coordinate work, run markets, hold votes, and distribute resources through embeddable applications built on streams.
Layer 2 introduced the assistant interface, implemented through the Groups app. This assistant summarizes activity, delivers notifications, requests approvals, and allows users to interact with Safebox through chat or voice.
Layer 3 expands the system further. It introduces the browser participation layer, where users interact with Safebox servers through a web interface and contribute resources to the network.
This layer is known as the Safebox Site.
While the assistant focuses on user interaction and decision-making, the Safebox Site handles:
- participation in organizations
- management of integrations and credentials
- contribution of distributed storage
- access to local files for artifact exchange
The Safebox Site runs in the browser and connects users to the Safebox servers that power communities and organizations.
Homesites and Hubsites
Safebox distinguishes between two types of servers and their corresponding web interfaces.
A homeserver hosts personal data belonging to an individual user.
A hubserver hosts communities, organizations, or projects.
When users access these servers through a browser, they encounter corresponding interfaces:
- a homesite for personal servers
- a hubsite for community servers
A user may interact with many Safebox servers simultaneously. For example:
- their personal homeserver
- the hubserver of a company they work for
- several community servers where they participate in projects
The Safebox Site acts as a gateway between the user and these servers.
Organizational Participation
One of the primary roles of Layer 3 is enabling users to participate in organizations.
Users can log into Safebox servers where they may hold different roles, such as:
- participant
- contributor
- moderator
- project manager
- administrator
Permissions depend on the role assigned by the organization.
A participant may simply view updates or contribute artifacts to a project. An administrator may configure integrations and manage credentials used by the organization.
The Safebox Site therefore acts as a control interface for organizational participation, allowing users to move between projects and communities while maintaining proper access control.
Managing Organizational Integrations
Organizations frequently rely on many external services to communicate with customers and partners.
Examples include:
- email systems
- messaging platforms
- social networks
- payment systems
- blockchains
- third-party APIs
Safebox centralizes these integrations inside the Safebox infrastructure.
Through the Safebox Site, administrators can configure credentials and connections for services such as:
- SMTP email servers
- DKIM signing keys
- Apple Business Messages
- Google Business Messages
- Telegram bots
- Facebook Messenger integrations
- Web3 blockchain keys
- API credentials for external services
Importantly, these secrets are not stored on personal devices. They are stored securely inside Safebox servers.
The browser interface allows administrators to manage them without exposing the secrets to the user’s local environment.
This approach provides several advantages:
- centralized auditing
- controlled access
- easy credential rotation
- improved organizational security
Distributed Storage Participation
In addition to providing access to organizations, Layer 3 allows browsers to contribute resources to the Safebox network.
Browsers can act as lightweight storage nodes.
Using the browser’s IndexedDB storage system, Safebox can store encrypted data chunks locally.
These chunks contribute to a distributed storage system known as the Safecloud.
Users who provide storage can earn Safebux through trustline-based accounting. These rewards can later be redeemed on-chain.
The storage system works transparently in the background. Data stored in the browser is encrypted, ensuring that participants cannot read the contents of the chunks they store.
Service Workers and Background Participation
The browser’s service worker mechanism allows storage participation to continue even when a webpage is not actively open.
Through web push notifications, the browser can wake a service worker and perform small tasks such as:
- storing encrypted chunks
- responding to replication requests
- maintaining availability of stored data
This allows users to support organizations and earn Safebux without actively interacting with the Safebox Site.
The browser essentially becomes a micro storage node that contributes to the resilience of the network.
Access to Local Files
Layer 3 also provides a bridge between Safebox systems and the user’s local filesystem.
Users may grant the Safebox Site permission to access specific folders on their device.
This capability enables workflows such as:
- uploading artifacts to projects
- downloading files generated by Safebox workflows
- synchronizing documents
- importing data into streams
For example, a user might allow a Safebox project to access a specific folder where design files are stored. When new files appear in that folder, they can be uploaded to the project automatically.
This mechanism is separate from Safecloud chunk storage.
IndexedDB storage is used for distributed encrypted chunks, while filesystem access is used for user-visible artifacts and documents.
Artifact Exchange
Many Safebox workflows produce artifacts such as:
- reports
- media files
- datasets
- documents
The Safebox Site allows users to retrieve these artifacts and store them locally.
Similarly, users can upload files that become artifacts in Safebox streams.
This allows seamless exchange of files between:
- local devices
- Safebox servers
- collaborators
The browser becomes a convenient gateway for moving data between environments.
Security Model
Layer 3 follows a security model where sensitive credentials remain inside Safebox infrastructure rather than on user devices.
The browser interface allows administrators to configure integrations and permissions, but the secrets themselves remain on the server.
This approach protects organizations from risks associated with:
- compromised personal devices
- accidental exposure of credentials
- loss of control when employees leave
Users can therefore manage integrations without directly handling the underlying secrets.
Relationship to the Other Layers
Layer 3 builds on the lower layers and prepares the system for deeper automation.
Layer 1 provides the application primitives:
- users
- streams
- markets
- governance systems
Layer 2 provides the human interface through the assistant.
Layer 3 provides:
- browser-based participation
- organizational integration management
- distributed storage nodes
- file exchange capabilities
The next layers will extend the system further into the browser environment and eventually into the operating system itself.
Layer 4 will introduce browser extensions capable of automating interactions with external websites, personalizing pages, and verifying trusted Safebox infrastructure.
These capabilities open the door to powerful automation workflows that operate across the web while remaining under the control of the user and the Safebox assistant.