Kunekt - JAM-Native Real-Time Collaboration Protocol

[olanod]

Kunekt Protocol

JAM-Native Real-Time Collaboration for Kusama

Very early stage idea with lots of refinement ahead

---

Introduction

Kunekt introduces a novel approach to decentralized collaboration by treating JAM as a unified computational backend for peer-to-peer applications. Rather than building another federated protocol or relying on traditional blockchain storage, Kunekt leverages JAM’s unique properties to create a seamless bridge between browser-based real-time collaboration and the broader Kusama ecosystem.

The protocol enables communities to create persistent collaborative spaces that maintain state both locally through peer-to-peer connections and globally through JAM’s data availability layer, while providing rich integration capabilities with parachains and other JAM services.

---

Core Architecture

Three-Layer Design

Browser P2P Layer    ←→  Space Coordinator  ←→  Polkadot Ecosystem
(Real-time collab)       (JAM-based VOS)        (Parachains, Services)

Browser P2P Layer: Direct peer connections for real-time CRDT synchronization and encrypted collaboration

Space Coordinator: A VOS instance running on JAM that acts as the persistent backbone for each collaborative space

Ecosystem Integration: Seamless communication with parachains and other JAM services through the coordinator

---

JAM Integration Overview

VirtoOS: Multi-Program Runtime for JAM

VirtoOS (VOS) serves as the abstraction layer enabling seamless collaboration across browser and JAM environments. Similar to CoreVM which runs single PolkaVM programs, VOS would manage multiple small async programs that compose together.

Browser VOS Instance

• Runs “wink!” programs (WASM+WASI apps inspired by ink! for familiar developer experience)

• Abstracts P2P networking and CRDT synchronization through simple file and messaging APIs

• Enables wink! programs to read/write collaborative documents as regular files

JAM VOS Instance (Space Coordinator)

• Identical runtime environment running on JAM’s PolkaVM cores

• Same wink! programs execute in both browser and JAM environments

• Provides persistent file system backed by JAM’s Data Availability layer

Data Availability as Distributed File System

Storage Strategy

• Real-time changes stored directly in DA layer during active collaboration

• 30-day retention managed through automatic snapshot compression

• Space Coordinators handle data lifecycle and snapshot creation

Integration Flow

Browser Peers ←→ Real-time P2P ←→ Space Coordinator ←→ JAM DA Layer

JAM Ecosystem Integration

Service Communication

• VOS provides standard networking APIs for discovering JAM services

• Coordinators communicate with parachains and custom services through familiar interfaces

• Cross-service interactions abstracted as simple API calls for wink! programs

Shared Infrastructure

• Multiple Kunekt spaces efficiently share JAM cores

• Common services (identity, governance) accessible to all coordinators

• Maintains space isolation while reducing infrastructure redundancy

---

How Collaboration Actually Works

Document Synchronization Without Conflicts

Many traditional collaborative tools work by sending your changes to a central server that decides the “correct” order and resolves conflicts. Kunekt uses a different approach called Conflict-free Replicated Data Types (CRDTs) - special data structures that let multiple people edit the same document simultaneously without conflicts, even when working offline or with poor connections.

Key Insight: CRDT operations are designed so that no matter what order they arrive in, everyone ends up with the same final document. It’s like having a set of rules that automatically resolve conflicts in a predictable way.

Matrix-Style Encrypted Messaging

Kunekt borrows heavily from the Matrix protocol’s approach to secure group communication. Each collaborative space uses the Megolm group ratchet - the same encryption system that powers Matrix rooms.

How Megolm Works in Kunekt:

1. Session Keys: Each document editing session gets its own encryption key

2. Ratcheting: Keys automatically rotate to provide forward secrecy

3. Group Efficiency: One key encrypts messages for all participants (unlike Signal’s multiple keys)

4. Key Distribution: New members receive keys through secure channels, can’t decrypt old history

Privacy Guarantee: The Space Coordinator on JAM only sees encrypted data blobs. It can store and relay information but cannot read the actual document contents.

Leader Election and JAM Coordination

Since peers work together directly but need someone to coordinate with JAM, Kunekt uses a leader election system based on the Raft consensus algorithm.

How Raft Leader Election Works:

Leader Responsibilities:

• Collect Changes: Gather CRDT operations from all peers in the space

• Create Snapshots: Bundle changes into efficient packages for JAM storage

• Coordinate with JAM: Send encrypted changesets to the Space Coordinator

• Handle Failures: If the leader goes offline, a new election happens automatically

Why This Works:

• Decentralized: No single point of failure - any peer can become leader

• Efficient: Only one peer talks to JAM, reducing costs and complexity

• Resilient: Elections happen quickly when leaders fail

• Secure: JAM coordinator can’t decrypt content, only coordinate storage

The Complete Flow

---

Real-World Workflow Example

Collaborative PrivateGov

Consider a Kusama DAO using Kunekt for private governance workflows:

1. Proposal Creation

• Members collaborate on proposal documents in real-time

• CRDT ensures no conflicts even with simultaneous editing

• Draft proposals remain encrypted until ready for submission

2. Private Discussion Phase

• Members leave comments and feedback visible only to DAO participants

• Rich discussion threads with encrypted real-time updates

• Stakeholder concerns addressed before public submission

3. Zero-Knowledge Private Voting

• Members generate ZK proofs of their DAO membership without revealing identity

• Proofs sent to Space Coordinator’s inbox for on-chain verification

• Voting happens privately while maintaining verifiable legitimacy

4. Cross-Chain Execution

• Finalized proposals automatically submitted to parachain governance pallet

• Voting results synchronized back to Kunekt space

• Implementation progress tracked in collaborative project documents

5. Persistent History

• All governance discussions preserved through snapshot system

• Members can reference historical context and decisions

• Audit trails maintained for transparency when needed

---

Brainstorming and Development Invitation

Kunekt is designed to grow with the Kusama ecosystem. We’re actively exploring how to best leverage JAM’s unique properties for decentralized collaboration. This document represents our current thinking, but we’re eager to refine these ideas with the Kusama community.

Open Questions We’re Exploring

• Optimal DA Usage: How can we most efficiently use JAM’s 30-day DA window for collaborative workloads?

• Cross-Service Integration: What are the most valuable integrations between Kunekt spaces and existing JAM services?

• Privacy Trade-offs: Where should we draw the line between encrypted collaboration and public verifiability?

• Developer Experience: How can we make WASM+WASI collaborative applications easy to build and deploy?

How You Can Contribute

We’re looking for collaborators across multiple areas:

Protocol Design

• Help refine the CRDT synchronization and leader election mechanisms

• Contribute to VOS integration patterns and API design

• Explore novel privacy-preserving collaboration patterns

Implementation

• Browser-based VOS runtime development

• JAM service integration and coordination logic

• WASM+WASI application framework design

Use Case Development

• Identify compelling applications for JAM-native collaboration

• Design governance and community management workflows

• Explore cross-chain and cross-service integration scenarios

Research and Documentation

• Formal protocol specification development

• Security analysis and privacy model refinement

• Performance modeling and optimization strategies

Join us in reimagining what decentralized collaboration can look like in the JAM era. Whether you’re a parachain developer, JAM core contributor, or simply excited about the possibilities, we’d love to hear your thoughts and ideas.

---

Interested in contributing? Reach out to discuss how Kunekt can serve your collaboration needs and the broader Kusama ecosystem.

---

Conclusion

Kunekt represents a new category of JAM-native applications that blur the line between off-chain collaboration and on-chain execution. By treating JAM as a computational backend rather than just a settlement layer, we can create rich, persistent collaborative experiences that seamlessly integrate with the broader Polkadot ecosystem.

The protocol’s design around JAM’s unique properties - from the 30-day DA retention to the PolkaVM execution environment - creates opportunities for innovation that aren’t possible with traditional blockchain or federated approaches.

As JAM launches and the Kusama ecosystem continues to evolve, Kunekt aims to be the collaboration infrastructure that enables more effective governance, development, and community building across the entire network.

[driemworks]

This is a cool idea! One thing to consider is a Merkle Clock DAG instead of Raft (https://arxiv.org/pdf/2004.00107). It lets you accomplish eventual consistency even with a weak messaging layer and without formal consensus or leader elections. It lets you get a convergent system where the DAG can be used as a logical clock without coordination between replicas. It also allows dynamic membership in the replica set, where you can use things like a DHT or even pubsub for peer discovery without needing to identify replicas beforehand.

[olanod]

Thanks for the tip, Merkle-CRDTs sounds very interesting indeed and probably better suited for this kind of protocol, I do think raft might not be the best in this case with hundreds or thousands of nodes with unreliable connectivity, it’s also good if we avoid the network usage overhead of elections to save on user’s data plan.
If Kusama goes for a fast block producing JAM instance and every user submits workpackages directly after each edit I think this will simplify things and makes the system more scalable.
I like the built-in content addressing as well, syncing and fetching data looks like it could be simpler. And now I wonder if we can use ZK-friendly hashing for the Merkle DAG to enable other kind of privacy use cases that I yet not see(e.g. proving I made an edit?).

[olanod]

Everything is a Document

Hey everyone, let’s continuing the Kunekt brainstorming session!
My initial idea of VOS was to have a very general purpose embedded OS that can run WASI programs, but now that it will be used as the substrate for Kunekt I think it’s worth making it a more specialized engine for the real-time use cases.

Just like with the Unix principle of everything is a file, a similar concept can be applied to VOS and Kunekt by extension, let’s make (almost) everything a (CRDT) document, instead of thinking in terms of files, folders, and traditional hierarchies, we can build everything around the concept of a “Document”.

Think about it: your messages, your code, your settings, even the “folders” themselves… all just Documents.

Side note. I’m thinking of renaming wink! to folio to be more aligned with the document theme.

Why?

Because it unlocks a ton of power! Here’s the gist:

• CRDT Magic: Every Document is built on Conflict-free Replicated Data Types (CRDTs). This means real-time collaboration is built-in, offline editing is seamless, and merging changes is automatic.
• Universal Structure: Everything is represented in the same way, making it incredibly flexible and extensible. Want to add a new feature? Just define a new Document type!(as a folio program).
• Linked Data: Documents can link to other Documents, creating a web of interconnected information. Think of it like a super-powered wiki, but everything is live and collaborative.
• VOS Handles the Complexity: You, as the app developer, don’t need to worry about networking, persistence, or conflict resolution. Let VOS take care of all that behind the scenes.

What does this mean for Kunekt?

It means a unified experience. Your discussions are documents, editable and shareable. Your code is a document, collaboratively developed in real-time. Your settings are a document, synced across all your devices, etc.
A Kunekt space is also a document, defined as a simple folio program that lists other documents as its children, it defines properties and rules for access control, like what users or roles can edit what and so on.