7 min de leitura

Bimbooo and Zion Wallet

Two things I built for different reasons. One became a small place for publishing text on the web. The other stayed on my desk, showing two networks and forcing me to understand what actually happens inside a wallet.
Bimbooo and Zion Wallet
bimbooo's logo

This week I want to show two projects. The first is Bimbooo, a neat service for anyone who wants to publish some text, keep a snippet, or make a tiny site without turning it into an operation. The second is Zion Wallet, a personal Bitcoin and Ethereum terminal I built to study wallets, keys, and signatures with a real device sitting on my desk.

They are very different, but they came from the same impulse: to make tools that are small, understandable, and mine.

Bimbooo, a small pink elephant for a small place on the web.

Bimbooo: a quieter place to put things on the web

I made Bimbooo because the web got loud. I wanted a calm corner where I could paste a snippet, write a page, and keep a tiny site, all at an address that is easy to remember and easy to read out loud over the phone.

That became bimb.ooo. The point is not to compete with a giant publishing platform. It is to offer a simple, friendly, deliberately small place.

T铆tulo: Bimbooo Home - Descri莽茫o: The Bimbooo home page introduces its three ways to publish: pastes, Markdown pages, and small HTML sites.
The Bimbooo home page introduces its three ways to publish: pastes, Markdown pages, and small HTML sites.

Three uses, without a pile of tools

Bimbooo brings together three things that usually live apart.

路    A pastebin for code, notes, and snippets you want to retrieve later.

路    Markdown pages rendered into something pleasant to read.

路    Hosting for a tiny static site written by hand in HTML.

Each person gets an address of their own, such as you.bimb.ooo/notes. There is no build step, no folder to upload, and no dashboard packed with settings. You open your desk, write, pick a name, and publish.

If the name ends in .md, Bimbooo renders Markdown. If it ends in .html, it can be part of your own site. Other names can remain plain text. An index.html, an optional style.css, and an about page are enough to make a small home on the web.

Invitations and human scale

The service is invite-only and kept by hand. There are no ads, trackers, or feeds fighting for attention. The person publishing does not become a metric on a dashboard.

To join, you ask for a seat and answer two short questions. Once I approve the request, you sign in, open the editor, and start publishing. It usually takes a day or two because a person looks at every request, not a machine pretending that this is community.

You can also choose how visible each item should be. A publication can be public, unlisted, or private. Expiration is available for things that should exist briefly. A read-once note destroys itself after it is opened. If an edit goes wrong, Bimbooo keeps the previous copy so you can take one step back.

Small precautions that matter

Bimbooo is one small program with strong walls. Each person's content lives on its own origin and cannot reach into someone else's space. Passwords are hashed, forms are guarded, and pages follow a strict security policy.

Security was not added as a late repair. It has been part of the structure from the beginning. That helps the service stay light, fast, and inexpensive to maintain without using simplicity as an excuse for carelessness.

T铆tulo: Bimbooo Personal Hero - Descri莽茫o: An example of a personal site published on Bimbooo, with its own HTML and visual identity.
An example of a personal site published on Bimbooo, with its own HTML and visual identity.

A site that still feels like yours

The result does not have to look like a Bimbooo product. My own corner at murad.bimb.ooo uses typography, color, humor, and a structure that look nothing like the service's home page. It feels like mine because the HTML and CSS are mine.

That matters to me. A small publishing service should not erase the personality of the person publishing. It should take care of the address, storage, and delivery, then leave the rest alone.

Where to see more

Three addresses show the idea from different angles.

路 docs.bimb.ooo contains the service documentation.

路 murad.bimb.ooo is my personal site on Bimbooo.

路 allhallows.bimb.ooo is Henrique's site and shows another identity built in the same space.

If that sounds useful, visit bimb.ooo. It is a small place for text, kept by people, with room for sites that do not need to justify their existence.

Zion Wallet: a wallet built for my desk

Zion is a different kind of project. It is not a public service or a wallet I am offering for other people to use. It is a personal, experimental terminal made to sit on my desk and help me understand Bitcoin, Ethereum, keys, vaults, and the care that money requires.

The device uses an Orange Pi CM4 with a Rockchip RK3566 processor, four ARM64 cores, and Debian. On the front is a 400 by 1280 pixel display mounted vertically and treated as a 160 by 25 character console. Behind it is a web interface for tasks that need more room.

A hot wallet, called what it is

Zion is a hot wallet. It stays powered on and connected to the network. Keys are protected while stored, the vault can be locked and unlocked, and the device reboots into a locked state. None of that turns a connected computer into cold storage.

I wanted that distinction to be explicit because security language can create confidence a system has not earned. Encryption at rest, a vault password, and a locked reboot are useful mitigations. They are not a change of category.

Zion separates the protections of a hot wallet from guarantees that require a truly offline device.

One core, two interfaces

At the center of the project is a single ZionRuntime. Both the terminal interface and the WebGUI talk to the same core through coordinators, so both screens show the same state and enforce the same rules.

Money never travels through the system as a floating-point number. Bitcoin is stored as satoshis, Ethereum as wei, and conversion for display uses Decimal. It is a small decision in the code, but an important one in any program that handles monetary values.

The physical display works as a persistent cockpit. The web interface handles actions that would be awkward in 160 by 25 characters. This split does not create two wallets. It creates two ways to operate the same wallet.

The architecture keeps one shared core behind both the terminal interface and the web interface.

How the project grew

In the first phase, everything was mocked. I needed to find the shape of the product before connecting the interface to real networks.

In the second phase, Bitcoin started talking to Electrum Signet through JSON-RPC over a Unix socket. The wallet file path and password behavior became explicit. Phase 2.2 then turned the experience into a small appliance: a cockpit, an ambient screen, blocks made with half characters, and ZION appearing at boot.

Phase 2.3 brought the WebGUI. The page is static and served by Python because this Orange Pi does not run Node. The web administration password is separate from the vault password, and the browser never receives private keys.

The third phase added Ethereum on Sepolia. The wallet starts from a 12-word phrase, uses an encrypted keystore, and signs EIP-1559 transactions on the device. JSON-RPC communication is asynchronous. At that point I froze version 0.1.0 and treated it as a stable base for continued testing.

The path of a transaction

Sending is not a matter of pressing a button and hoping. The flow is split into visible steps.

1.  The transaction is prepared.

2.  Its details are presented for review.

3.  The person authenticates again.

4.  The vault is unlocked only when needed.

5.  The transaction is signed inside the device.

6.  A physical confirmation can be required on the 160 by 25 character display.

7.  Only then is the signed transaction broadcast.

The browser never signs. Signing and broadcasting are separate operations. Keys never leave the device. There is also an honest limitation: in Python, deleting an object does not guarantee that every copy of a secret immediately disappears from memory. The project reduces exposure, but it does not promise a kind of memory wiping the language cannot guarantee.

The flow separates preparation, review, local signing, physical confirmation, and broadcast. In use, Zion consumes roughly 40 percent of one core, or less than 10 percent of the processor when all four cores are considered. Memory use stays close to 100 MB on a board with nearly 8 GB, and load normally remains below 0.4. Without a cooler, temperatures above 60 degrees Celsius are expected, still below the thermal throttling point.

For now, everything remains on test networks. Bitcoin uses Signet and Ethereum uses Sepolia. Mainnet is disabled. I have not yet completed the entire path with funded transactions, from sending to final confirmation, or restored a funded wallet. I also want a better receipt confirmation flow and an easier way to scan a QR code with a phone. There is no invented success message hiding those gaps. If a step has not been proven from end to end, the interface should not pretend that it has.

Bimbooo and Zion solve different problems. Bimbooo is a service for other people to publish small things without entering a growth machine. Zion is personal, experimental, and stays on my desk. What they share is the desire to understand what I am building. I like tools that show their limits, leave room for personality, and do not need to be enormous to be useful.

Bimbooo became a quiet place for text. Zion became the device I wanted: two live networks, a console display that looks as if it came from another era, and a web interface for everything else. Neither one needs to pretend to be bigger than it is. To me, that is part of the charm.