This is the app icon
Nearby sharing starts here.
One Space. One QR. Let people join.
The network stays complex. The experience stays simple.
What if the room became the network?
One file. Hundreds of downloads.
Receive. Then help.
One QR. Everyone gets the file.
Different platforms. One CLOVI network.
Monetize organizing, not participating.
The network gives back.
Built in public.
Working ≠ finished.

CLOVI

What if the room became the network?

CLOVI is a nearby, offline-first file distribution app designed for moments when many people need the same content but the Internet is weak, overloaded, or simply unnecessary.

For personal sharing:

Send files nearby, even without Internet.

For groups and events:

One QR. Everyone gets the file.

Inspiration

CLOVI started from a problem I experienced at AABW 2026.

A speaker showed a QR code so everyone in the room could download the same material.

The idea was simple.

The network was not.

Hundreds of phones were effectively asking the Internet for their own copy of the exact same file. In a crowded venue, the connection itself became the bottleneck.

That led to the question that started CLOVI:

What if the room itself could help distribute the file?

What CLOVI does

CLOVI turns nearby devices into participants in a local distribution network.

Instead of requiring every copy of a file to come from the Internet — or even from one original sender — devices that have already received useful data can help move it to other nearby peers.

The product experience stays intentionally simple:

Choose. Show one QR. Join. Receive.

Underneath that experience, CLOVI can deal with different platforms, local transports, secure sessions, recovery, integrity, and peer-assisted distribution.

The person using CLOVI should not have to understand any of it.

One QR. Everyone gets the file.

An organizer creates a Space and shares one invitation QR.

Nearby participants scan it and join.

CLOVI handles the local connectivity and transfer path underneath while the interface reduces the experience to things people actually care about:

who joined
which files are being shared
transfer progress
recovery
completion

No networking vocabulary should be required to use the product.

Built for the real differences between platforms

CLOVI is not built on the assumption that every operating system exposes the same networking capabilities.

They do not.

The architecture separates the product experience, platform-specific networking, and shared transfer logic.

Today, the project combines:

Flutter for the product experience and orchestration.

Swift for Apple-native networking.

Kotlin for Android-native networking.

Rust for the shared protocol, security, integrity, recovery, relay, and peer-assisted transfer logic.

Bulk file bytes do not move through Dart.

Flutter owns the experience.

Native platform code owns the transports.

Rust owns the correctness of the transfer path.

Today, CLOVI is published on iOS.

Android is part of the working cross-platform development and real-device testing environment, but has not yet been published to Google Play.

The longer-term architecture is designed to extend the same shared distribution core toward macOS, Windows, and Linux through platform-appropriate transports.

The architectural direction is:

Different platforms underneath. One CLOVI network above them.

The difficult part was not making a file arrive

Early in the project, success meant:

“Can I transfer a file between these two devices?”

That stopped being enough very quickly.

The real questions became:

What happens when a peer disappears?
Can the transfer recover?
Who owns the network resource?
Does the received file still verify correctly?
Does the system remain bounded as more peers participate?

At one point I had a real cross-platform transfer working, but an architecture review revealed that part of the data path could bypass the secure session design I intended.

The demo worked.

The architecture was wrong.

So I rebuilt it.

That became one of the most important lessons from CLOVI:

Working is not the same as finished.

RevenueCat and the business model

CLOVI does not monetize the basic act of receiving a nearby file.

The product boundary is:

Monetize organizing the network, not participating in it.

Personal nearby sharing and receiving remain separate from the paid organizer experience.

RevenueCat powers CLOVI Pro, including the subscription purchase and restore lifecycle.

The paid value is the organizer layer: creating larger organized sharing sessions and coordinating an audience while attendees can simply join and receive.

This model also fits the economics of the product.

CLOVI does not pay cloud bandwidth every time another local copy of a file moves between nearby devices, so charging per file, per gigabyte, or per receiver would be artificial.

The value being monetized is orchestration, not local bandwidth.

For occasional organizers, the product direction can extend toward an Event Pass: one time-limited event rather than one payment per file or transfer.

For frequent organizers, CLOVI Pro provides recurring organizer access.

The network gives back

CLOVI's business model carries the same cooperative idea as the network itself.

For every two CLOVI Pro purchases, one Community Credit is created.

That Community Credit can help enable another community event, allowing value created by paying organizers to extend beyond their own account.

The idea mirrors the technology underneath:

A peer with bandwidth can help another peer.

A paying organizer can help another community.

This creates a simple loop:

2 Pro purchases → 1 Community Credit → another event → more participants → more people experiencing CLOVI.

Instead of making social access something separate from the business model, CLOVI makes it part of the same cooperative system.

Editorial Network Utility

CLOVI's design direction combines editorial structure with the personality of a consumer product.

I call it:

Editorial Network Utility.

The interface uses warm off-white surfaces, near-black typography, CLOVI green as a deliberate accent, generous whitespace, and thin network lines as a recurring visual language.

I intentionally avoid turning the app into a networking dashboard.

The more complex the system underneath becomes, the more important it is that the interface stays calm.

CLOVI also has its own four-leaf mascot and motion language. Animation communicates connection, loading, transfer progress, recovery, and completion rather than acting only as decoration.

The networking concept itself becomes part of the visual language through paths, movement, and relationships between nearby devices.

The design challenge is not making networking look technical.

It is making networking disappear.

Built in public

CLOVI has been documented publicly throughout Shipaton.

That changed both how I explain the product and how I build it.

Public discussion forced me to explain the idea without hiding behind networking terminology.

People challenged whether CLOVI was simply reinventing BitTorrent.

That question was useful.

It forced me to clarify the actual product boundary: peer-assisted distribution is only one part of CLOVI.

The product also includes QR-based admission, heterogeneous mobile transports, secure local sessions, recovery, and an experience specifically designed for people sharing in the same physical space.

I also shared failures and architecture changes rather than only polished demos.

Building in public changed the question from:

“Does it work?”

to:

“Can I explain why it works, where it fails, and why the architecture deserves to exist?”

That public accountability helped turn CLOVI from a networking experiment into a product story I can explain, defend, and keep improving.

Why this could matter

CLOVI began with conferences, but the same problem appears elsewhere:

classrooms distributing the same material
workshops sharing large resources
hackathons moving files locally
community events with overloaded Wi-Fi
places where connectivity is weak, expensive, or unavailable

The goal is not to replace the Internet.

It is to let nearby devices cooperate when asking the Internet to move the same information repeatedly is unnecessary, inefficient, or impossible.

Where CLOVI is going

Today, CLOVI is live on iOS.

Android is already part of the cross-platform development and physical-device testing environment.

Beyond mobile, the longer-term direction is a common local distribution layer spanning phones, tablets, laptops, and desktops across iOS, Android, macOS, Windows, and Linux.

A device with useful data can become a source.

A device with useful connectivity can become a bridge.

A device that has already received data can help another peer.

But none of those concepts should become another thing the user has to manage.

The experience should still feel like:

Scan. Join. Receive.

CLOVI started from one small observation:

hundreds of people wanted the same file, but every phone was asking the Internet for its own copy.

That led to the question that still defines the project:

What if the room became the network?