§2 Selected work

CivicLens

Civic issue archive and public dashboard

Status
Deployed static prototype
Role
Sole public repository contributor; implemented the archival utility and static dashboard.
Domain
Civic Technology / Data Archival
Figure 1Shows the archival path from the source PostgreSQL/Supabase rows through a credentialed exporter to content-addressed IPFS storage, and the static browser view that reads the exported archive. No volumes, timings, or availability figures are represented.
§1Brief

The problem this had to solve.

Export civic issue rows from Supabase to content-addressed Storacha storage and make an archived dataset inspectable without requiring the source database.

The repository contains a credentialed Node.js exporter that fetches filtered civic issue rows from Supabase, serializes the data with archive metadata, and uploads it to Storacha content-addressed storage.

A separately deployed static dashboard reads an IPFS archive with gateway fallbacks, computes summary counts, and lets visitors search and filter the archived issue records. The evidence supports this archive-and-explore workflow, not a full municipal case-management platform.

Constraints

  1. The public dashboard is a static HTML, CSS, and JavaScript interface backed by archived/sample JSON, not the issue-submission application.
  2. The Node.js archival utility requires Supabase and Storacha credentials and an interactive Storacha email-authentication flow.
  3. Filtering and status statistics are client-side operations over the fetched archive.
§2Architecture

How the system is put together.

Supabase issue rows

Credentialed, filterable PostgreSQL source data

source

Archive exporter

Transforms issues and adds schema/source metadata

process

Storacha / IPFS

Content-addressed JSON archive

process

Static dashboard

Gateway fetch, statistics, search, and filters

output
§3Decisions

What was chosen, and what it cost.

Separate archival from presentation

Choice
Use a Node.js utility to fetch and transform Supabase rows, then upload a JSON archive that a static dashboard can read.
Rationale
The published dashboard can remain simple and read-only while the credentialed export process runs separately.
Cost
The repository does not implement report creation, assignment, SLA enforcement, or authenticated resolution workflows.

Use content-addressed storage

Choice
Persist exported issue collections to Storacha and expose their CID/IPFS URL as the archive reference.
Rationale
An export can be referenced independently of the mutable source database.

Keep exploration in the browser

Choice
Calculate status counts and apply search, status, priority, and category filters in the static page.
Rationale
The deployed view needs no application server for basic archive exploration.
§4Validation

How it was checked.

  • The repository includes a connection script that exercises Storacha initialization, Supabase statistics, and an archive upload when valid credentials are supplied.
  • The deployed Vercel homepage returns HTTP 200 and presents the static dashboard.
  • The checked-in dashboard can fall back across multiple public IPFS gateways before using bundled data.
§5Limits

Where this stops being true.

  • No automated unit, integration, accessibility, or end-to-end test suite is present; test.js is a live credentialed smoke script.
  • Archive freshness depends on rerunning the credentialed exporter; the static dashboard does not continuously synchronize with Supabase.
  • The static page bundles issue data, so repository contents must be reviewed for privacy before publishing new archives.
  • Storacha availability, public gateway behavior, and source-database permissions remain external dependencies.
§6Technology

What it is built with.

Runtime & interface

  • JavaScript
  • Node.js
  • HTML/CSS

Data & evaluation

  • Supabase
  • PostgreSQL

Infrastructure & providers

  • Storacha
  • IPFS
Next documentIndian IPO Analytics