I keep coming back to a simple frustration: a capable computer can be sitting in front of us, with memory, storage and processing power available, while an application waits for a connection to do something useful.
With Jungle Computing, I want to give that computer more responsibility. Let someone keep working locally, then share their changes when the right connections are available. JungleBase is the browser database prototype I am using to explore the idea.
In my earlier Jungle Computing article, I explored the broader opportunity of different kinds of computers working together. This takes that idea into a specific setting: a group of browser sessions with useful data of their own.
Give each browser useful work
PGlite provides a concrete starting point. It is PostgreSQL compiled to WebAssembly, with a JavaScript interface and the option to keep data in the browser through IndexedDB. That puts a relational database inside the application, without asking the user to install a conventional database server.
I want to use that capability for ordinary work: searching project information, updating a task or adding a note. Those actions should have a useful local result, with a clear indication of whether the change has also been shared.
My initial ambition was a Supabase-like experience in the browser. Supabase's architecture includes authentication, APIs, storage, realtime communication and functions alongside its database. PGlite supplies the local database component; identity, permissions and the other services need their own place in the design.
Start with three computers
The starting design is a group of three primary computers, with other browser sessions joining and exchanging the data they are permitted to share.
Three gives me somewhere manageable to begin. One person can make a change, another can be disconnected and a third can still be working with an older version. Following that sequence should tell us much more than filling a screen with connected machines.
The application needs clear rules for what may happen while someone is away. A personal draft could stay editable. A shared decision might need to wait for its owner. On reconnection, the returning person should see what changed and any decisions that still need their attention.
Those rules should follow the work people are doing. Choosing them is as much a product decision as a technical one.
Teach the application what a change means
WebRTC data channels can carry data between connected browsers. The application then has to turn those messages into a reliable account of the work.
I want each change to have its own identifier and a record of what it affects. The receiving browser would check the change, apply it and send a confirmation. If that confirmation gets lost, the sender could try again. Recognising the identifier would let the receiver confirm the same change without applying it twice.
There is still a human decision inside some updates. If two people rewrite the same project note while disconnected, successfully delivering both versions does not tell us which one they intended to keep. Preserving both for review may be more useful than silently choosing one.
WebRTC also needs a way to exchange connection details, and some networks require a relay. The official peer connection guide explains those supporting services. I would include their operation and cost in the design from the beginning.
Make sharing a deliberate choice
Each workspace should have explicit rules about who can read and change its information, enforced when updates are shared and received. Someone joining a project would receive the information needed for that project. Because recipients may retain copies, I want the sharing decision to be clear before the data leaves its original workspace.
This would also make the interface easier to understand. A person should be able to see where their work is kept, who it is shared with and whether the latest changes have reached those people.
Give the network a useful picture
The network observatory is the part I am particularly keen to bring to life: a three-dimensional view of participating computers and their connections, with an event feed alongside it.
I want it to show, at a glance, who is connected, what is waiting to be shared and where a message stopped making progress.
A node would represent a browser session and a line would show a connection. Selecting either would reveal its recorded state, last contact and waiting changes. Node size could represent a measured quantity, such as queued updates, with a legend explaining it. A growing node would then give an administrator something specific to investigate.
The event feed should make it possible to follow one change from creation to confirmation. That is the view I would want when someone says, “I updated it, but the other person cannot see it.”
Demonstration activity would be visibly labelled, and observations would show their source and freshness. The visual could then be both engaging to explore and useful for understanding what the application actually knows.
Design for the return journey
The next milestone I care about is completing a small piece of work through interruptions: disconnect a computer, edit a shared record, reconnect and follow the outcome on all three machines.
That experiment should include closing a browser during a transfer and recovering a session whose local data is gone. A useful design needs both the freedom to work locally and a dependable way to return to the shared work.
The possibility keeps drawing me back: computers already on our desks taking a more active role, while the people using them can understand what has been saved, shared and resolved.
Which part of your working day would improve most if the application could keep going when its connection disappeared?