TRIVE is betting on vibe coding for mini apps that live inside social networks
TRIVE builds mini apps from plain-language descriptions and deploys them on Web4 infrastructure. GLACIER is the first route today, with identity, storage, and hosting already handled underneath.
TRIVE is being built around vibe coding as its core method for creating mini apps and small applications — software described in plain language instead of written line by line. The method itself is not the interesting part. What matters is what happens next: a mini app built this way is meant to be dropped into a social network or an everything app and simply work.
GLACIER is the part that exists today. It is TRIVE’s AI vibe-coding studio. A description goes in, a working mini app or website comes out, deployed directly on Web4 infrastructure with no separate hosting to configure. TRIVE and DEV.UNITY are working on further ways to build these mini apps beyond what GLACIER covers today.
Standalone web apps are the wrong output
The industry has spent two years learning that describing software to an AI produces working software surprisingly often. What most of that work still produces is a standalone artifact: a web app on its own URL, with its own login, its own user list, its own island.
That is the part we think is wrong. Almost nothing built for a community wants to be a separate website. A booking tool for a workshop, a referral board for freelancers, a resource library, a lightweight marketplace, a members-only calculator — these belong inside the place where the community already is. On the traditional internet they cannot be, so each one becomes another link, another account, another thing nobody signs into twice.
A mini app that lives inside the network solves that. It is the model that made the large everything apps successful in the first place: not one enormous application, but a shell hosting hundreds of small ones. What Web4 changes is who is allowed to build them and who owns the result.
How GLACIER and ATRIUM fit together
TRIVE is Layer 5 of the Web4 stack — software and tools. ATRIUM is Layer 6 — application delivery, or Social Networks as a Service. The relationship between the two layers is the whole idea.
| GLACIER (in TRIVE) | ATRIUM | |
|---|---|---|
| What it produces | One working mini app or website | A whole social network or super app |
| Input | A plain-language description | A single AI prompt |
| Scale | One specific tool | The platform that tool lives inside |
| Where it runs | Web4 infrastructure, no hosting setup | Web4 infrastructure, no hosting setup |
These are not an either/or choice. A mini app built with GLACIER can be integrated directly into a super app built with ATRIUM. A community can start with an ATRIUM network and then add its own custom, GLACIER-built tools as additional features, rather than being limited to what the platform ships with out of the box.
One specific tool starts at glacier.linkspreed.com. A whole community platform starts at web4.community. For both, the sensible order is to build the tools first and add them to the network afterwards.
What the layers underneath already handle
Three things separate a Web4 mini app from a vibe-coded web app, and all three come from the layers below it.
- Identity is already solved. Users sign in with their UIID — a self-owned, device-based, biometric-secured identity. A mini app does not need to build registration, password storage, password resets, or login, and it does not inherit the liability of holding credentials. Everyday sign-ins run through anonymous aliases, so a mini app dropped into a network does not become a new tracking surface for the person using it.
- Storage can live on the user, not in a database. UIID lets an application store structured data directly on a user’s identity — on an alias for anything context-specific, on the Core ID for anything genuinely central. For a small tool, that frequently removes the entire backend. It also means the data is portable and travels with the user instead of being locked inside the app.
- Deployment is not a separate project. Apps built with GLACIER deploy directly on Web4 infrastructure. There is no hosting to procure, no pipeline to configure, no domain to point.
Taken together, the distance between an unmet need in a community and a tool that meets it collapses from a project to an afternoon.
Where TRIVE and DEV.UNITY go next
GLACIER is the first route to a mini app, not the only one we intend to offer. TRIVE and DEV.UNITY are working on further solutions for building them — TRIVE owning the tooling and the software layer, DEV.UNITY owning developer relations and the practical question of how people outside the company actually build on this.
Four design goals guide that work. Integration is a first-class outcome: a mini app should be built with its destination in mind, an ATRIUM network or an everything app, rather than retrofitted into one afterwards. There should be more than one on-ramp — plain-language description is the right entry point for a non-developer, while developers want the API, the reference, and worked examples, and both should reach the same result. Composability matters: communities should be able to accumulate a set of small tools over time instead of commissioning one monolith and living with it. And whatever is built should inherit the ownership properties of the stack it runs on. A tool that cannot be taken elsewhere is a tool being rented.
Developers who want to start today can use the UIID API reference at uiid.linkspreed.com/api-docs. The UIID Cookbook — worked examples plus a runnable Demo Suite, Apache-2.0 licensed — is on GitHub at github.com/Web4-Organisation.
What this does not do yet
Some limits are worth stating plainly, because setting expectations beats managing disappointment.
What comes out of a vibe-coding prompt is a working starting point, not a finished product. The prompt is the step that rewards effort: “a booking tool for a photography community that handles deposits and sends reminders” produces a far better result than “a booking app.”
TRIVE and GLACIER are free, and that is structural rather than promotional. LINKSPREED is self-funded, with no outside investors and no external funding rounds, so there is no mandate to introduce platform fees. The one exception: AI features that call metered AI APIs, and paid third-party APIs connected to something built on the platform, are billed by the API provider rather than by us.
Removing the technical barrier is also not the same as removing the work. Building a mini app is easy now. Knowing which one a community actually needs is still the hard part, and no amount of tooling answers it.
The mini app economy without the landlord
Every large platform of the last fifteen years eventually reached the same conclusion: the value is not in the app, it is in the ecosystem of small things running inside it. Every one of them then made that ecosystem a place to rent — subject to review, to revenue share, to policy changes, and to removal.
TRIVE’s version is the same architecture with the ownership put back. The tool belongs to whoever built it. It runs on infrastructure that can be left. It plugs into a network its operator runs, keeping 100% of what it earns.
That is what vibe coding is for, in our view. Not making it slightly faster to produce another standalone web app, but making it realistic for a community of any size to build the specific tools it needs, inside the place it already lives.
Getting started
| Goal | Where to go |
|---|---|
| Build a mini app | glacier.linkspreed.com |
| The TRIVE suite — CRM, project management, accounting, free | trive.web4.one, signed in with a UIID |
| Build the network to put it in | web4.community |
| Create a UIID first — about thirty seconds, free | uiid.me |
| Developer and partnership enquiries | [email protected] |