Sealing the Sighting: Verifiable Bird Records from Nairobi, Powered by Gemma

Vickrey: A Birdwatcher’s Journal That Can’t Be Quietly Rewritten

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I'm from Kenya, where birdwatching is a beloved pastime. BirdLife International's country profile counts about 1,059 bird species here, 49 of them globally threatened and 10 found nowhere else. Kenya also sits on the African-Eurasian flyway, so roughly 170 species arrive each year from Europe and Asia, according to reporting on a UN migratory species report.

Thousands of people already watch these birds, and what they see is valuable: where a bird was, on what day, in what numbers. But most of it lives in notebooks, WhatsApp groups and memory. When a record does get shared, there's no easy way to know whether it was changed afterwards.

Vickrey is a field journal that makes sightings verifiable. You take a photo, an open-weight model suggests what the bird is, and you confirm or correct it, because the observer's judgment is the record. Then you seal the entry. If anyone edits it later, the seal cracks, and the journal refuses to sync until the original is restored.

The goal is crowdsourced insight you can trust: many ordinary birders contributing to a shared picture of how birds move, without needing to trust whoever holds the spreadsheet. Identifying a species and preserving what the observer actually recorded are different problems, and Vickrey is built around the second.

It's for birders, field naturalists and small survey groups. The screen should be the shortest part of the experience: look up, snap, confirm, seal, keep watching.

Did it get me outside? Yes. I took it to a park in Nairobi and used it to identify a robin. It was one bird, an easy and well-photographed one, so it says little about how the model handles harder Kenyan species. The suggestion ran on my own server and the ledger was simulated, as the video says. What I can say is that the loop worked in the field: photo, suggestion, confirmation, seal, with very little time spent looking at the phone.

Demo

• Showcase site: https://sneldao.github.io/vickrey/
• 92-second film: https://youtu.be/9BmpLblSHUM

What you're seeing, and what you're not:

• The model suggestion comes from Gemma running on my own server, not on the phone.
• Everything ran simulated on my server because of space constraints on my devices. Ledger verification uses a mock Hornet ledger, not a real public-chain anchor, and the film says so.
• The interactive field client isn't hosted on GitHub Pages, which is static. It runs locally; instructions are in the repo.
• The robin photo in the film is illustrative. Credit to its photographer: European robin on a branch, Wikimedia Commons. My Nairobi park test was a separate, real run.

Code

sneldao / vickrey

Vickrey — Prove What You Saw

A sealed bid on what you saw. Vickrey is an offline, open-source AI field identifier with a tamper-evident ecological logbook — for Hacktoberfest 2026, Week 1: Touch Grass.

The name is the metaphor: Vickrey is named for William Vickrey's sealed-bid auction — a mechanism that makes truth the winning strategy. We point the same mechanism at the world: your phone seals what you saw, the network countersigns it, and tampering cracks the seal. See docs/BRAND.md.

The vision: point your phone at a bird, a plant, or a fall tree with no signal. An open-weight model running on the device names what you saw Vickrey signs the observation, chains it into a tamper-evident log, and — when you are back in range — anchors the commitment to a shared ledger. The result is a field record you can later prove nobody…

View on GitHub

Disclosure under the new-project rules: the repo began on October 6. I reused the ledger and incident-evidence explorer from an earlier project, Veles. The older explorer is still running at http://45.76.242.245/ and is not the new field client. What's new this week is the field client, the human-review step, the persistent journal, and the outbox.

How I Built It

The path of one sighting:

1. Suggest. A photo goes to gemma3:4b, an open-weight Gemma model on my own server, which proposes an identification.
2. Confirm or correct. The observer's decision is what gets recorded. The model only suggests.
3. Seal. The entry is linked into a SHA-256 hash chain and signed with Ed25519.
4. Journal. The sealed entry goes into a durable, signed local journal that survives restarts and sync. This is the observer's permanent record.
5. Outbox and verify. A separate outbox queues entries for sync. If an outbox copy has been edited, verification fails and sync is refused until it's restored. Restored entries sync to the mock ledger.

The suite has 78 Node tests and 54 ledger tests. The test I trust most is the tamper test: edit an entry, watch it get refused, restore it, watch it pass.

The bug that taught me the design. With storage tight on my devices, I was running everything simulated on one server. After the first successful sync, the screen said "VERIFIED, but 0 sealed." The queue had emptied, and the observer's sighting had vanished from the UI. The sync had worked, and it looked like it had eaten the record.

The mistake was mine: the outbox was doing double duty as the journal. An outbox is meant to drain once its contents are delivered, so when it emptied, the observer's own record went with it. In a project about not losing what an observer recorded, that is exactly the wrong failure.

The fix was to split them. The journal is durable and signed, and it only grows. The outbox is disposable and drainable, a to-do list for sync rather than a place where records live. Syncing now empties the outbox and leaves the journal untouched. The reasoning is written at the top of journal.js.

Why Does Open Innovation Matter?

For birdwatching in Kenya, openness isn't a nice-to-have.

• Swappable model. The identification step is gemma3:4b today. A general model will be weaker on African species than on a robin, and with open weights the path forward is a model fine-tuned on regional data, slotted in without touching the sealing logic. I haven't done this yet; it's the obvious next step.
• Infrastructure the community controls. Photos go to a server I run, not a third-party API, and never to the ledger. The locations of threatened species are sensitive, so keeping them out of systems I don't control matters.
• Trust in the right place. The point is that a record can't be quietly rewritten. That's hard to promise if the model that suggests the record sits behind someone else's closed API.
• Cost. Community projects rarely have budgets, and open models don't charge per photo.

There is a local organisation to build with, too: Nature Kenya is BirdLife's partner here and works on 69 Important Bird and Biodiversity Areas, covering about 12% of Kenya's land. Verifiable community sightings from those sites are the kind of data conservation work can use.

For scale beyond Kenya, GBIF's 2025 guide to publishing survey data describes more than 3 billion occurrence records from roughly 2,300 institutions. That's context for how big biodiversity data is, not a claim about Vickrey's market or about gaps in those records.

What I haven't done: run inference on the phone itself. Offline, on-device identification, which is what a trail with no signal needs, is the next step, not a result I'm claiming.

Prize Categories

• Best Use of Gemma: gemma3:4b powers the identification suggestion in the field client.
• Best Use of ElevenLabs: the film's narration, music and sound effects were made with ElevenLabs.