Setting Up Sovereign Nodes (Proof of Concept)

⚠️ Development Status: This is experimental software not intended for production use. The security model and functionality are still evolving.

Sovereign nodes are an experimental CLI application that demonstrates how self-hosted infrastructure could provide always-online services for the Osvauld ecosystem. Nodes serve two primary functions:

1. Collaborative backup and synchronization (Livnote): Always-online P2P infrastructure for document collaboration
2. Content publishing and distribution (Sthalam): Host and serve websites, blogs, forms, and comments to viewers

This is currently a proof-of-concept implementation to test the viability of user-controlled infrastructure.

What Sovereign Nodes Support

Livnote (Collaborative Editing)

Sovereign nodes provide always-online backup and synchronization for collaborative documents:

• P2P infrastructure: Maintain connections when desktop peers go offline
• Document synchronization: Keep real-time copies of shared documents
• Connection brokering: Help peers discover and connect to each other
• CRDT operations: Process conflict-free replicated data type updates

Sthalam (Publishing Platform)

Sovereign nodes host and serve published content:

• Websites and blogs: Publish content from your node—viewers connect directly
• Forms and surveys: Collect submissions from viewers with UCAN-protected access
• Comments: Enable real-time discussions on published content
• Newsletters: Distribute content to subscribers
• UCAN permissions: Control who can view, comment, or submit forms
• Viewer privacy: Viewer identities NOT stored by default—one-way connections only

Publishing flow: Create content on desktop → Publish to your sovereign node → Viewers access via connection string or blockchain name → All interactions happen through your node

Current Proof-of-Concept Model

The current sovereign node implementation operates as a regular peer with full access to shared documents, serving as a technology demonstration for future infrastructure capabilities.

Current Architecture

Full Peer Access: Nodes currently receive the same permissions and data access as any regular collaborator, including persistent access to encryption keys.

Standard Synchronization: Uses the existing P2P synchronization protocols without special infrastructure optimizations.

Experimental Features: Provides a testing ground for concepts like always-online availability, backup storage, and content publishing in a P2P context.

Future Security Model (In Development)

The planned production model will implement session-based key sharing:

Temporary Access: Sovereign nodes will only receive decryption keys when other peers are actively online and grant session-based access.

No Persistent Keys: Nodes will not store long-term access to encrypted data, requiring active peer presence for decryption capabilities.

Session-Based Permissions: Access to document content will be granted temporarily during active collaboration sessions rather than as permanent shares.

Experimental Setup Process

Testing Hardware

For experimental deployment, minimal hardware is sufficient:

Development Boards: Raspberry Pi 4 or similar ARM-based computers work well for testing the concept.

Network Access: Standard internet connection for P2P connectivity testing.

Storage: Basic storage for SQLite database and document testing.

Memory: 2GB RAM sufficient for proof-of-concept operation.

Experimental Installation

Development Setup

Build from source for experimental use:

# Install cross for ARM64 compilation
cargo install cross

# Clone the repository (example path)
git clone https://github.com/osvauld/osvauld
cd osvauld/kunki

# Cross-compile for Raspberry Pi (ARM64)
cross build --target aarch64-unknown-linux-gnu --release

# Copy binary to target device
scp target/aarch64-unknown-linux-gnu/release/kunki pi@raspberrypi.local:/home/pi/
ssh pi@raspberrypi.local "sudo cp /home/pi/kunki /usr/local/bin/ && sudo chmod +x /usr/local/bin/osvauld"

Initialize Test Node

Create an experimental node identity:

kunki init --username "test-node" --passphrase "development_passphrase"

Note: This creates the same cryptographic identity as a regular user. The node will have full access to any documents shared with it.

Start Experimental Service

Run the test node:

kunki start --passphrase "development_passphrase" --print-token

The --print-token flag generates connection information for testing peer connections.

Current Testing Capabilities

What Works Today

Livnote Collaboration:

• Peer connectivity: Nodes establish P2P connections with desktop clients
• Document synchronization: Shared documents sync to nodes and remain available when other peers go offline
• Always-online testing: Demonstrates continuous availability for collaboration
• Connection brokering: Provides stable connection points for peer discovery

Sthalam Publishing:

• Content hosting: Publish websites, blogs, and newsletters from your node
• Viewer access: Viewers connect directly to your node to read content
• Forms and comments: Collect submissions and enable discussions
• UCAN permissions: Control access to published content, forms, and comment threads
• Real-time sync: Comments and form submissions sync via CRDT operations

What’s Experimental

Security Model: Current implementation grants full persistent access to shared documents, which is not the intended production model.

Resource Management: No optimization for server-class operation or resource constraints.

Monitoring: Basic logging without production-level observability features.

Testing with Desktop Clients

Connecting Clients to Test Nodes

Share the generated connection token with desktop Osvauld clients to establish connections and test the peer-to-peer protocols.

Testing Livnote Collaboration

Document Sharing: Desktop users can share documents with the test node like any other collaborator. The node will receive full access and maintain synchronized copies.

Offline Testing: Test offline scenarios by disconnecting desktop peers while keeping the node online, then reconnecting to verify synchronization works correctly.

Testing Sthalam Publishing

Publishing Content: Use the desktop client to create and publish websites, blogs, or newsletters to your test node.

Viewer Connections: Test viewer access by connecting to published content using the node’s connection string.

Forms and Comments: Test form submissions and comment threads—verify real-time CRDT synchronization between publisher and viewers.

Permission Testing: Test UCAN token-based access control for viewing content, submitting forms, and posting comments.

Limitations and Warnings

Current Security Limitations

Full Access Model: Test nodes currently receive the same permanent access to documents as regular users, including persistent decryption keys.

No Session Management: Access is not limited to active collaboration sessions, unlike the planned production model.

Standard Peer Protocols: Uses regular user synchronization without infrastructure-specific optimizations.

Development Status

Proof of Concept: This implementation demonstrates concepts rather than providing production-ready infrastructure.

API Instability: Command-line interface and functionality may change significantly as development continues.

Limited Support: Experimental software without production support or stability guarantees.

Future Development Plans

Session-Based Security Model

Temporary Key Sharing: Production nodes will only receive decryption keys during active peer sessions rather than permanent access.

Active Peer Requirements: Nodes will require at least one authorized peer to be online to access document content.

Session Expiration: Access will automatically expire when collaboration sessions end.

Infrastructure Optimizations

Resource Efficiency: Optimizations for continuous operation on minimal hardware.

Monitoring Integration: Production-ready logging and observability features.

Multi-Tenant Support: Secure isolation for multiple user groups on shared infrastructure.

This experimental implementation provides a foundation for testing the viability of user-controlled infrastructure in peer-to-peer collaborative networks while the security model and production features continue development.