Research-first · Prototype stage

Web 5.0 / Client-Powered Cloud

Web 5.0: a client-powered cloud network

OVRLab is building Web 5.0 — a cloud made of clients — so developers can run truly serverless decentralized applications without traditional servers, using a self-organizing peer network secured by cryptography.

Today’s internet concentrates control and failure in centralized platforms. Web 5.0 explores what the network could look like if it could run itself — with compute, storage, and coordination contributed by peers.

Serverless decentralization

Build certain decentralized apps without owning server fleets.

Resilience by design

No single point of failure; routing and redundancy across many nodes.

Distributed-AI ready

Push computation to the edge and support cooperative peer workloads.

Current stage: experimental prototype. Core components exist and are being refined through rapid iteration.

Context

Why Web 5.0

OVRLab exists to explore a more open, resilient, and user-centered internet.

Today’s internet is primarily built on centralized systems. Most online communication and coordination flows through a small number of servers, platforms, and intermediaries. Centralization makes things convenient, but it also concentrates control, increases the impact of outages, and forces users to trust policies and infrastructure they do not own.

OVRLab exists to explore a different path: a more open, resilient, and user-centered internet. We ask what the network could look like if it could run itself.

Web 5.0 is a step toward infrastructure that behaves more like a shared public utility than a proprietary server farm.

Technology

Technology: How Web 5.0 Works

A client-powered Cloud Network: ordinary devices contribute compute, storage, and networking to run applications across a collaborative peer network.

A “cloud of clients”

Web 5.0 is a decentralized internet foundation where peers communicate and coordinate without a traditional centralized backend controlling the network. It is not meant to replace all traditional clouds; it is designed for applications where distribution across many nodes brings major benefits.

  • • Decentralized internet foundation: peer communication and coordination.
  • • Distributed AI and reduced cloud costs: push computation and logic to the edges.
  • • Self-organizing peer network: deploy production-ready apps without running your own servers.
Diagram: “Cloud of clients” overview

Many peer devices collectively provide routing, coordination, and data channels.

Peer node implementation

Each peer node runs as a Chrome browser extension and a cross-platform Electron app. On startup, the client generates a cryptographic identity (public/private key pair) and participates in discovery and coordination.

Diagram: Peer lifecycle

Identity → Join → Discover → Coordinate → Relay/Direct data channel

Joining, discovery, and liveness

  • • Joining & discovery: peers attempt to occupy a slot and link to others.
  • • Peer index & liveness: peers keep a local index of known peers, exchange heartbeats, and detect replacement.
Diagram: Discovery + local peer index

Heartbeats, indexing, churn handling, and replacement detection.

Security model (trustless by default)

The protocol uses X25519 elliptic-curve cryptography for key exchange, message encryption, and authentication.

Network actions and messages are accepted only when cryptographically valid — no peer relies on implicit trust.

Diagram: Secure message flow

Key exchange → Encrypt → Verify → Accept/Reject

Data channels and throughput

PqP can be used as a signaling layer to establish direct WebRTC data channels between peers. After initial coordination, peers may hand off to direct peer-to-peer channels for higher throughput.

Diagram: Control plane vs data plane

Coordination/signaling vs direct WebRTC data channels.

Research threads & open problems

Moving from a server-based cloud to a cloud of clients introduces new constraints. Web 5.0 focuses on systems problems that matter in the real world:

  • Coordination & consistency: churn-tolerant distributed algorithms; eventual consistency models.
  • Security & trust: cryptographic validation, replication, and defenses against malicious nodes.
  • Performance variability: heterogeneous client devices require adaptive scheduling and fault tolerance.
  • Developer tooling: observability, deployment, updates, and debugging in widely distributed environments.

Current status

  • • Stage: experimental prototype.
  • • Active testing: joining, discovery, relay behavior, and how the system self-organizes over time.
  • • Next: once core pieces are solid, testing expands beyond the team and more updates will be shared publicly.

Open work

Research & Open Output

OVRLab operates with open innovation: nearly all code and research output is intended to be public, enabling collaboration, scrutiny, and community contribution.

Recommended blocks

Repositories (protocol / peer client / example apps) — placeholders until public
Quickstart (Chrome extension + Electron node) — placeholder
Contributing (issues, discussions, security reports) — placeholder
Publications(in progress)

This section will grow over time. Planned outputs include:

  • • Protocol specification (versioned)
  • • Technical notes and experiments (short, readable)
  • • Benchmarks & measurements (repeatable)
  • • Security notes (threat model, assumptions, mitigations)
  • • Case studies (e.g., lessons from deMail)

If you want to collaborate or review early materials, contact us.

Where it fits

What you can build on Web 5.0

Designed for developers and researchers building truly decentralized applications without owning server fleets.

Applications that fit well

The best fit is work that can partition compute, replicate data, or coordinate across many nodes without requiring a permanent centralized server — and that can tolerate churn (clients joining/leaving).

  • • Content sharing and delivery with redundancy.
  • • Collaborative or federated services where each client hosts part of the service.
  • • Compute-intensive distributed tasks (rendering, data analysis, scientific computation).
  • • Peer-to-peer privacy-first tools: secure messaging, personal data vaults.

Applications that may not fit

  • • Apps requiring real-time global consistency or centralized control.
  • • Transaction systems where centralized authority is inherent.
  • • Workloads tied to specialized hardware or centralized databases that cannot be distributed effectively.

deMail is an early-stage prototype of a decentralized email application built on Web 5.0. It illustrates how a familiar service can work without relying on central email servers.

  • • Messages travel through the Web 5.0 client network and are delivered directly.
  • • No central company or authority stores user emails; only sender/recipients access content.
  • • Proof of concept to validate viability and refine the platform.

Why it matters

  • • Resilience: no single point of failure; route around outages.
  • • Independence: reduced reliance on major cloud providers; reduced vendor lock-in.
  • • Performance potential: geographic distribution can reduce latency by running close to users.
  • • Cost efficiency: use shared spare capacity across many devices.
  • • Lower barriers: deploy decentralized apps without owning server infrastructure.

Engineer honesty

Distributed systems trade-offs still apply: coordination, security, performance variability, and tooling are harder in a widely distributed environment.

Team

Netherlands-based, virtual-first

A startup-led research and engineering lab working at the intersection of decentralized computing and distributed systems.

Mission

We are an independent research and engineering company with a mission to stretch the shape of the internet.

Who we are

Systems researchers and distributed systems engineers with expertise spanning computing infrastructure and algorithms, drawing from diverse backgrounds across academia and industry.

Culture

  • • Curiosity, collaboration, and rigor
  • • Humility and continuous learning
  • • Research curiosity + startup execution

How we work

We combine fundamental research with hands-on engineering: develop algorithms and scalable architectures, build prototypes to test ideas, and iterate quickly based on measurement and real-world feedback.

  • • Open innovation: nearly all code and research output is public.
  • • Virtual-first: coordinate online; use existing infrastructure when it speeds learning.
  • • Pragmatic engineering: leverage available tools while reimagining what needs it.

Careers

Help build the cloud of clients

If you’re excited by distributed systems, protocol security, and edge-native compute, we’d like to hear from you.

What you’ll work on

  • • Peer discovery, coordination, and churn-tolerant distributed systems
  • • Secure networking and cryptographic validation (X25519)
  • • WebRTC data channels and performance-oriented P2P communication
  • • Reliability, observability, and developer tooling for widely distributed deployments
  • • Distributed AI infrastructure experiments (edge compute + cooperative peers)

Introduce yourself

Send a short note describing what you want to build or explore, and include links to GitHub, papers/notes, or distributed systems projects.

Contact

Contact

Contact

Reach us through the channels below.

Reach out through the channels below. We’ll connect you with the right person.

Web 5.0: A client-powered cloud network