DEV Community: Naveen Alavilli

I built a trail accessibility surveyor that runs with the radio off

Naveen Alavilli — Sun, 11 Oct 2026 11:18:36 +0000

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

What I Built

Trailworthy turns a walk down a trail into an accessibility report a parks department can act on.

Public trails are supposed to meet the Architectural Barriers Act Accessibility Standard. Most have never been checked against it, and the reason is boring: a survey means a clipboard, a tape measure, a copy of the standard, and someone willing to type it all up afterwards. So the surveys do not happen. And the trails nobody surveys are the trails nobody complains about, because the people who would complain gave up on them a long time ago.

Trailworthy makes the field half of that job take no more effort than talking.

At the trailhead you name the trail. On the trail the screen goes dark and there is exactly one button. Hold it, say what you see, let go, put the phone back in your pocket. Nothing is transcribed, nothing is uploaded, nothing asks you to look at it. The only number the app tracks while you walk is how long your screen stayed off.

Back home you hit develop. Whisper transcribes each note on your device. A sentence embedding model routes each note to the right accessibility criterion. Any measurement you spoke gets checked against the actual threshold. What comes out is a cited report:

1. Tread obstacles - Blocking

Citation ABAAS F247.6 / FSTAG 7.7
Requirement Tread obstacles may not exceed 2 in high.
Measured 4 in (100% outside the limit)
Location 29.77860, -95.55140 (±6 m)

a root crosses the trail about four inches high right at the bend

It is for the people who already do this work: accessibility advocates, trail volunteers, parks staff with eleven other jobs, and anyone who has turned around on a trail that was advertised as accessible and wants to say so in a form that is hard to ignore.

Demo

Try it: https://naveenalavilli.github.io/trailworthy/

Load the models once (about 70 MB), then put the device in airplane mode and the whole survey still works. It installs as a PWA.

A full generated report from a scripted set of notes is in the repo at examples/sample-report.md, if you want to see the output without walking anywhere.

Code

https://github.com/naveenalavilli/trailworthy

src/criteria.js    ABAAS/FSTAG criteria, thresholds, citations, prototype phrasings
src/measure.js     pulls spoken measurements out of a transcript
src/analyze.js     routing, polarity, compliance and severity
src/report.js      the Markdown and printable report
src/worker.js      both models, off the UI thread
scripts/           icon generation, threshold calibration, the polarity experiment
tests/             runs against the real embedding model, not mocked vectors

How I Built It

Two open-weight models, both in the browser through transformers.js, both in a web worker:

Piece	Model	Licence
Speech to text	`Xenova/whisper-tiny.en`	MIT
Note classification	`Xenova/all-MiniLM-L6-v2`	Apache-2.0

Classification is the interesting half. People do not talk in the language of a standard. Nobody stands on a trail and says "the cross slope exceeds 1:20". They say "it leans toward the creek", or "off camber here", or "water's cut a channel across the path". Those share no keywords with each other or with the standard, but they sit close together in embedding space. Each criterion carries a handful of example phrasings, everything gets embedded once on load, and each note goes to its nearest neighbour.

Three things about that turned out to be less obvious than they looked.

The classifier needed a floor, and the floor needed data

Nearest-neighbour routing always returns a nearest neighbour. Without a floor, "my daughter found a turtle by the pond" gets filed as a tread obstacle, and the report is junk.

So I wrote scripts/calibrate.mjs, which scores a labelled set of real observations against a set of ordinary trail chatter and prints the gap:

lowest real observation : 0.576
highest chatter         : 0.458
separable               : yes
suggested MATCH_FLOOR   : 0.517

The threshold is the midpoint, and it is in the repo as a script rather than a magic number in a comment, so anyone editing the phrasings can re-derive it instead of guessing.

Embeddings are bad at negation, and that is dangerous here

"Nothing on the sign about the grade" and "the sign lists the grade" are near neighbours. They are topically identical and mean opposite things. The first was being filed as compliant.

Think about what that means for this particular app. A barrier with no number attached, a missing curb ramp, no bench on a long climb, nothing on the trailhead sign, would land in the "meets the standard" pile precisely because there was nothing to measure. The report would be confidently, quietly wrong in the one direction it must never be wrong in.

I split the decision in two. Routing picks the criterion. A separate step decides whether the note describes that criterion being wrong or being fine, by giving each criterion two sets of phrasings, one for each. Then I tested three ways of making that call on hand-labelled notes:

nearest prototype:               25/29
mean per side:                   27/29
mean + negation flip:            22/29
shipped (flip unless reassured): 28/29

The fix averages similarity across each side rather than trusting the single closest phrase, then treats absence wording ("no", "nothing", "nowhere", "without") as its own signal. It only ever flips toward "barrier", and never for criteria whose compliant wording is itself negative, like "no noticeable cross slope". The experiment is in the repo.

That first version scored 18/18 on its original set, and it was still wrong. Any "no" or "not" flipped a note, so "the gate is fine, no trouble getting a chair through" became a blocking barrier. Adding notes where the negation lands on the problem ("not a problem", "no low branches") dropped it to 22/29. Those phrasings now switch the flip off, but never flip a note toward "fine" on their own, so the one remaining miss errs toward a barrier a human strikes out rather than one nobody sees.

WebGPU built perfectly and then hung

The obvious setup is WebGPU with a WASM fallback, and the obvious place to catch failure is where the pipeline is constructed. Neither survived a real browser.

The session built. The warm-up inference returned. Every call after that hung forever. Nothing ever threw, so the fallback never fired, and the progress bar just sat at 100% looking healthy.

Two changes came out of it. The fallback is now driven by a timed warm-up inference, because a backend that builds is not a backend that works. And WASM is the default: these models are small and the work is many short sequential calls, which WASM does in 1.4 s for the whole prototype set and 31 ms for four notes. WebGPU is behind ?gpu=1.

There was a fourth, more embarrassing one. I spent a while debugging a fix that had already shipped, because my service worker cached same-origin assets cache-first and was serving my own stale code back to me. That is the standard offline recipe and it pins every user to whatever build they first loaded. Everything the app ships itself is now network-first with a cache fallback, which is still completely offline on a trail but can be fixed afterwards. Two quieter holes turned up in review: a first visit cached almost nothing, because the service worker registers after the scripts load, and the ONNX runtime's 21 MB of wasm came from a CDN by default. The build now hands the service worker a full precache list, and the runtime loads from the app itself.

Why Does Open Innovation Matter?

A closed API would transcribe audio more accurately than whisper-tiny.en. It still could not do this job.

The trails that most need surveying are the ones with no signal. That is not a coincidence. Remote and under-maintained trails are both less likely to have coverage and less likely to have ever been assessed. Every note becomes a failed request exactly where the work matters most. Running the model on the device is not an optimisation here, it is the difference between the app working and not existing.

The data is unusually personal. A survey is a precise record of where a disabled person went, how long they took, where they struggled and where they turned around. Shipping that to someone's servers to get it typed up is a bad trade. On-device inference means I am not asking anyone to trust me, because there is nothing for me to be trusted with. I do not have a server. There is no account.

Nobody is funding this. This work gets done by volunteers and small advocacy groups. A per-minute transcription bill is one of the reasons it does not happen. Zero marginal cost is not a nice-to-have, it is the thing that makes a hundred surveys possible instead of three.

The thresholds are arguable, and should be. ABAAS has conditions and exceptions, and reasonable people disagree about how a given trail should be read. Everything that encodes judgment here, the thresholds, the phrasings, the severity defaults, lives in one readable file. Fork it, change a number, re-run npm run calibrate, and see what moved. A hosted classifier would make that an argument with a vendor instead of a pull request.

The honest summary: open weights are what made the hard constraint (no signal, no server, no cost) satisfiable at all, and open source is what makes the judgment calls contestable by the people who actually use the trails.

What it deliberately does not do

It will not tell you a trail is compliant. It reports what it heard you say, against the criterion it thinks you meant, with a confidence number attached, and the report says in plain language that a human has to verify every finding before it goes to an agency. Measurements come from a person and a tape measure, not from a model. An accessibility report that overstates its own certainty is worse than no report, because it gets one person dismissed and then everyone after them.

Prize Categories

Entering the overall category. The project uses open-weight models and an open-source runtime rather than any partner's technology, so I am not claiming a partner category I did not use.

Built in the open for Hacktoberfest Week 1. If you work for a parks department and want a survey of a specific trail, open an issue and I will go walk it.

Access Revoked. Why Can Your RAG App Still Answer?

Naveen Alavilli — Sun, 04 Oct 2026 17:09:32 +0000

At 09:00, a user asks an internal assistant about Project Cedar. The retriever checks access, finds the document, and the model produces an accurate answer.

At 09:05, the user loses access to that project.

At 09:06, the same question returns the same answer. The request never reaches the retriever: the answer cache handles it.

Every retrieval check can be correct while the application still serves restricted information.

This is a hypothetical design scenario, not a report of a production incident. It exposes a question worth asking during a RAG review: which copies of source information remain usable after permission changes?

Follow the information past retrieval

A document can leave several descendants:

Source document
  -> indexed chunks
  -> retrieved context
  -> generated answer
  -> answer cache
  -> conversation history or summary
  -> exported report

A permission check on the first retrieval does not automatically protect those descendants.

A citation is also an incomplete dependency record. A generated answer may use a chunk without citing it. Removing the link later does not remove what the answer learned from that chunk.

For application-controlled artifacts, record the sources supplied to generation, including context inherited from earlier turns. Treat the full supplied set as dependencies unless you have a sound way to establish a smaller set. This is conservative: it may invalidate some answers unnecessarily, but avoids treating a model's citation choices as an access-control decision.

Specify what revocation means

Before selecting a cache TTL, decide the product contract.

Does removing a user from a project stop new retrieval only? Does it also stop replay of stored answers and reuse of old conversation context? What happens to requests already running?

For this example, assume the requirement is: once revocation becomes effective in the application's authorization system, subsequent requests must not serve or reuse protected content from that project.

Previously downloaded files and information already seen by the user cannot be recalled. Historical conversations may have a separate retention and access policy. State that policy explicitly.

For in-flight generation, choose and document a rule: authorize against a request-start snapshot, or require authorization again before delivery. A final check reduces exposure but still leaves a check-to-delivery race unless authorization changes and delivery are coordinated. Do not promise instantaneous revocation without implementing the consistency needed to support it.

Treat a cache hit as another read

OWASP recommends validating authorization on every request and denying access by default. Those principles apply when a cache supplies the response too. OWASP Authorization Cheat Sheet.

A useful answer-cache record contains:

Field	Purpose
Tenant and authorization scope	Prevent accidental reuse across security boundaries
Query and generation configuration	Identify the requested computation
Source IDs and content revisions	Track which inputs produced the answer
Permission revision or epoch	Detect relevant authorization changes
Expiration	Bound retention and ordinary staleness

A user ID in the key separates users, but the same user's permissions can change. A permission epoch helps only if every relevant policy, membership, and document-ACL change advances it, and the request obtains a sufficiently current value. Hashing an old group list does not make it current.

Here is control-flow pseudocode, not a complete security implementation:

authenticate request and establish tenant
find candidate cached answer within that tenant

if candidate exists:
    check its complete source dependencies
      against current authorization
    if dependencies are known and access is allowed:
        serve under the chosen delivery policy
    otherwise:
        do not serve the cached body

retrieve currently authorized context
generate a new answer
record all input dependencies
apply the chosen delivery policy

An unavailable authorization service must not silently turn a denied or unknown decision into permission to serve an old answer. A safe outcome may be an explicit temporary failure. A system can also answer from independently authorized public content, provided it does not reuse the restricted context.

The index has its own clock

Refreshing the answer cache does not fix stale permissions in the index.

Azure AI Search's query-time ACL/RBAC documentation, currently marked preview, explains that ACL freshness depends on ingestion. Its documented update paths include reingestion for custom push ingestion and resynchronization for particular indexer scenarios. Microsoft: Query-time ACL and RBAC enforcement.

That creates separate delays to measure: identity/group resolution, permission propagation into the index, authorization-cache freshness, and invalidation of derived answers.

A five-minute answer TTL does not establish a five-minute revocation bound if the authorization data used to regenerate that answer remains stale for longer.

For stricter requirements, evaluate whether candidate results need a check against an authoritative permission service before their content reaches the model. The right design depends on the source's consistency guarantees and the latency budget.

Test the warm path and the resumed conversation

Use synthetic documents with a distinctive marker, two test users, and controlled permission changes. Make the authorization state observable so the test knows when revocation is effective.

Experiment	Expected result under this example's contract
Warm the answer cache, revoke access, repeat the question	Cached protected body is not served
Ask a paraphrase that hits a semantic cache	Same authorization check applies
Revoke access, then resume an old conversation	Restricted chunks and derived summaries are not reused as context
Keep the search index deliberately stale	Unauthorized context does not reach generation
Make authorization unavailable	No fallback to the previously allowed answer
Leave a control user authorized	The control user can still retrieve and answer

Inspect the retrieved context and outgoing model payload, not just the final response. A model declining to repeat the marker does not prove it never received the protected text. Check stored summaries and citation metadata too.

For a revoked source inside a mixed answer, dropping one citation is insufficient. Regenerate from permitted inputs or withhold the derived artifact. Without trustworthy dependency tracking, rebuilding the conversation context may be safer than attempting selective cleanup.

The architecture review question is concrete: after a permission change, which component stops the next cached answer, follow-up turn, and export from using the old access decision?

Two Agents, One Record: Stop Silent Lost Updates

Naveen Alavilli — Sun, 04 Oct 2026 02:09:26 +0000

Two agents read the same support ticket. One corrects its customer-visible summary. The other changes its priority.

Both send valid updates. Both receive success responses.

The final record has the new priority and the old summary.

No timeout. No duplicate request. One successful write silently erased another.

This is a hypothetical design example. The same race can happen between an agent and a person using an ordinary web form.

Watch the interleaving

Assume the API replaces the editable fields with the submitted document:

Step	Agent A	Agent B	Stored version
1	Reads ticket		12
2		Reads ticket	12
3	Saves corrected summary		13
4		Saves priority using its old copy	14

B's payload still contains the original summary. Each request makes sense when considered alone. Together, they lose A's work.

A unique operation ID would distinguish the two writes, but both are intentional operations. Duplicate suppression does not decide whether B's starting point is still valid.

Make the starting version part of the write

A useful update contract says:

Apply these changes only if the resource still matches the version I read.

For an HTTP API that supports conditional updates, the client can retain the strong ETag returned with a read and supply it in If-Match:

GET /tickets/42

HTTP/1.1 200 OK
ETag: "ticket-42-v12"
Content-Type: application/json

{"summary":"Original summary","priority":"normal"}

A's update:

PUT /tickets/42
If-Match: "ticket-42-v12"
Content-Type: application/json

{"summary":"Corrected summary","priority":"normal"}

After A succeeds, B's different update using the old tag fails the precondition. In this scenario, the server responds with 412 Precondition Failed and leaves A's version intact.

RFC 9110, section 13.1.1 defines If-Match, requires strong entity-tag comparison, and describes its use in preventing lost updates. The tag above is illustrative; clients should treat the server's tag as opaque.

The application must actually support and enforce this contract. Adding a header to a client cannot fix a server that ignores it.

Enforce it where the mutation happens

For a versioned database record, the core operation can look like this PostgreSQL-style statement:

UPDATE tickets
SET summary = $1,
    priority = $2,
    version = version + 1
WHERE tenant_id = $3
  AND id = $4
  AND version = $5
RETURNING version;

The version predicate and mutation belong in the same atomic operation. A separate version check followed by an unconditional update reintroduces the race.

This fragment illustrates the concurrency check; the endpoint also needs authorization and validation. No returned row means the conditional write did not happen. It does not, by itself, distinguish a stale version from a missing record or a scope mismatch.

Every writer must follow the version contract, including admin scripts and background jobs. One unconditional writer can bypass the protection.

A conflict needs a decision

The dangerous recovery is:

Receive a conflict.
Fetch the latest version token.
Attach it to the original stale payload.
Retry.

That sequence can turn a detected conflict back into a lost update. The token becomes newer while the reasoning remains stale.

Instead, reload the current resource and compare it with the original observation and intended change.

In this example, B wanted only to raise the priority. A policy might permit reapplying that narrow change to the current record, preserving A's summary, then submitting it conditionally again.

But different fields do not automatically imply independent decisions. A changed summary might explain why raising the priority is no longer appropriate. Domain rules determine whether to rebase, recompute, or ask for review.

A bounded retry policy also needs a stopping condition. Persistent contention should surface as a conflict the user can understand.

Test the race deliberately

Avoid a test that merely launches two requests and hopes they overlap. Use a barrier or controlled sequence so both clients read version 12 before either writes.

Test	Expected result
A writes, then B submits a different update based on the same old version	B is rejected; A's data remains
B reloads and reapplies an allowed narrow change	Both intended changes survive
B fetches a new token but reuses its old whole-document payload	Recovery test fails
A background writer changes the record	Its write also advances the version
Permission is revoked between read and write	Execution is denied independently of version validity

These are proposed checks, not reported benchmark results.

For rules spanning multiple records, a version check on one row may be insufficient. Protect the full invariant with an appropriate transaction, constraint, or coordination mechanism.

The design question to bring to your next review is simple: what prevents a correct action based on yesterday's view from overwriting today's work?

AI disclosure: This article was generated and published by an AI assistant at the account owner's request. The scenarios are illustrative.

Your Agent Timed Out. Did the Action Still Happen?

Naveen Alavilli — Sat, 03 Oct 2026 17:55:58 +0000

An agent submits a request to publish a document. The server commits it. The response disappears before the agent receives it.

The agent sees a timeout and tries again.

You now have two published documents and a log that describes a successful recovery.

This is a design scenario, not a benchmark result. It exposes a question worth asking before giving an agent tools that change external state: what does your system do when it cannot tell whether an action happened?

A timeout establishes that the caller did not receive a timely result. It does not establish that the remote operation failed. The Amazon Builders' Library discussion of idempotent APIs explains this ambiguity and the use of caller-provided request identifiers to make retries safe.

For agent workflows, I'd make that uncertainty explicit in the application contract.

Give uncertainty a state

A boolean success field cannot describe every outcome of a remote write. Consider these states:

State	Meaning	Next step
Ready	The operation is authorized and durably recorded	Dispatch
In flight	A worker has claimed it; it may have reached the destination	Await evidence
Succeeded	The destination has confirmed the required outcome	Return the stored result
Failed	There is conclusive evidence it did not take effect	Apply the failure policy
Unknown	It may have taken effect, but evidence is missing	Reconcile

An expired worker lease also deserves attention: the worker might have crashed after the remote commit. Recovery must account for that possibility.

The UI can say: “The request was submitted, but completion is unconfirmed. Checking its status.” That is a useful result, even when it is less satisfying than “Done.”

Identify the operation before calling the model

A tool-call ID identifies an attempt. The application needs an identity for the logical operation across attempts.

For a hypothetical document workflow:

operation_id: op_8c21
actor_id: user_42
action: publish_document
target_id: doc_104
content_version: 7
request_fingerprint: <hash of canonical action parameters>
state: ready

Create and persist that identity in application code. Carry it through retries and restarts. If the destination supports an idempotency key, pass the same key for the same operation according to that API's contract.

The request fingerprint has a different job: detect changed parameters. Reusing an operation ID with a different destination or payload should produce a conflict. A hash alone cannot express intent; two intentional operations can have identical payloads.

Scope identifiers to the actor or tenant, enforce uniqueness atomically, and check the provider's retention window. An old key may stop protecting a retry after the destination expires its record.

Keep authorization attached to the proposed action

If a workflow requires approval, record what was approved: action, target, payload version, and applicable limits.

A retry of that exact operation can reuse the recorded authorization where policy permits. A model that changes the payload has proposed a different action. It should not silently inherit approval for the old one.

Recheck current permissions at execution time too. A durable approval record should not bypass a later revocation.

A local ledger cannot close a remote transaction

The difficult sequence is:

1. Record the operation locally.
2. Send the remote write.
3. The destination commits.
4. The worker crashes before recording the result.

A local transaction cannot make steps 2 and 4 atomic with an unrelated service.

The recovery path depends on the destination:

With suitable idempotency support, retry the same operation under that contract.
With an authoritative lookup by operation ID, query it and reconcile the result.
With neither, retain the unknown outcome and route it for investigation before attempting another consequential write.

An empty search result may be inconclusive if the destination is eventually consistent. A durable queue improves delivery, but the consumer still needs a strategy for duplicate attempts.

Test the inconvenient boundary

Before shipping, exercise these cases:

Injected condition	Expected behavior
Response lost after remote commit	Recovery resolves to the original result
Two workers dispatch the same operation	The destination applies one logical effect under its idempotency contract
Same ID, different payload	Conflict before another effect
Worker dies after remote commit	Operation enters reconciliation
Lookup is temporarily stale	No premature claim that nothing happened
Idempotency retention expires	Retry policy accounts for the lost protection

These are tests for the surrounding application, not prompts asking the model to be more careful.

A practical design review question is: if this write succeeds and its response vanishes, what evidence lets the next worker decide what to do?

If the answer is only “the agent will figure it out,” the recovery protocol is still unfinished.

I Built Nabsun: An Open-Source AI Browser That Works in Your Real Tabs

Naveen Alavilli — Fri, 25 Sep 2026 00:57:06 +0000

You have three documentation tabs open, a form half-filled, and the account you need already signed in.

Then you ask an AI assistant for help—and start copying everything into a chat window.

That gap is why I built Nabsun, an open-source browser with an AI assistant built in. It can read the page you are looking at, compare information across tabs, and use browser tools to help complete a task in your existing session.

It works where your work already is.

Nabsun is built with Chromium and Electron. You can use its bundled local model, connect a cloud provider, or bring Codex or Claude Code into the browser. It is a developer preview, and the source is available under MIT.

Website · GitHub repository · Download · Watch the demo

Why build another browser?

The browser already holds much of the context an assistant needs: the page you are reading, the tabs you are comparing, and the application you are signed into.

Moving that work into a separate chat creates friction. You copy context over, get an answer, switch back, and translate the answer into clicks and keystrokes. A separate automation session can introduce another problem: getting it into the same state as your real session.

I wanted to make that handoff smaller.

In Nabsun, the assistant sits beside your tabs. The browser provides page-reading tools, action tools, and approval controls. You can watch the work happen and take over in the same tab.

That is the reason to build at the browser layer: context, actions, and user control can live together.

What can it actually do?

Open the assistant with Ctrl+Shift+A. Start with the current page or give it a task involving several tabs.

Here are examples of tasks to try—not promises that every model will complete every website workflow:

Task	Example prompt
Understand a page	“Summarize this documentation and point out the setup requirements.”
Compare tabs	“Compare the options in these tabs. Make a table and link each finding to its source.”
Extract information	“Turn this table into structured records. Flag missing values.”
Prepare a form	“Fill this form using the details I provide. Stop before submitting.”
Research a question	“Find the relevant documentation, read it, and explain the answer with links.”

The assistant can read, click, type, select options, scroll, and navigate. It can ask for clarification when a choice belongs to you.

Nabsun also includes the everyday browser features that make this practical: tabs, bookmarks, history, downloads, session restore, and encrypted saved passwords.

The useful distinction is the move from discussing a task to helping carry it out, while keeping the result visible.

How the assistant sees a page

For developers, this is one of the more interesting parts.

Nabsun provides an accessibility-derived outline of the page. Interactive elements receive opaque references that the agent can use with tools such as click, type, and select.

The normal loop is:

Read the page → choose an element → request an action
             → apply approval settings → act → read the updated page

The page bridge rejects stale references and changed element identities instead of silently using them against a different target.

This gives the agent a structured way to interact with a page without relying on screen coordinates for every action. It does not make arbitrary websites reliable: iframe and shadow-root coverage are limited, and website compatibility varies.

The architecture notes explain the process boundaries, page tools, and execution loop.

Choose the model that fits the task

Nabsun separates the browser tools from the model using them.

Built-in local model: Qwen3 1.7B runs on your CPU without an account or API key.
Your local stack: connect Ollama or configure a different local model.
Cloud APIs: configure Anthropic or OpenAI in Settings.
Existing assistant accounts: connect Codex or Claude Code through Extensions → Assistants.

For the CLI connections, Nabsun installs the official native CLI when needed and can reuse existing sign-ins. Your provider account must have access to the assistant. Credentials remain in the CLI's own store; signing out also affects that CLI outside Nabsun.

The bundled model matters because you can start without opening another account or paying for hosted inference. It is suitable for simple tasks; complex research and long action sequences benefit from a stronger model.

Local inference works offline. Visiting websites still needs a network. Cloud providers and signed-in CLI assistants use their respective services and receive the context sent to them. Ollama is local only when its endpoint is local.

Optional personal context lives in soul.md, a Markdown file shared only with local providers by default.

Connect your editor to your real browser

Nabsun also exposes an MCP server.

That lets an external agent use Nabsun's browser tools against your existing tabs. An assistant in your development workflow can access the browser through a defined interface.

Copy the configuration from:

Settings → Integrations → Connect an external agent

The sidebar and external agents use the same browser approval settings. The bridge listens on loopback and uses a fresh bearer token for each launch.

Nabsun can also consume tools from MCP servers, load plugins, and load unpacked Chrome extensions. Chrome API support is partial, and there is no Chrome Web Store installation flow yet.

A signed-in browser needs clear boundaries

An assistant acting inside your session has meaningful access. The controls deserve as much attention as the capabilities.

By default, reading tools run automatically. Clicking, typing, navigation, and page code require approval. Per-tool grants and Autopilot change those settings, including for connected external agents.

The application UI and web pages run in separate renderers. Action targets are captured before approval and revalidated before dispatch.

Those controls have limits:

Prompt injection remains a risk. Instructions on a malicious page can influence a model; approval controls do not eliminate that problem.
Structured tools restrict credential handling. Password and one-time-code values are excluded from structured extraction, and typing into those fields is blocked. Arbitrary page JavaScript has broader access.
Plugins and MCP servers are trusted code. Plugins run with full Node privileges; they are not sandboxed.
Stop cancels pending work. It cannot undo an action that has already completed.

Nabsun has not had an independent security audit. The security document describes the controls and remaining gaps.

Why open source? Why MIT?

A browser assistant can encounter private documents, internal applications, and authenticated sessions. People should be able to inspect how it handles that access.

Publishing the source makes concrete questions inspectable:

What context reaches the selected model?
Where are credentials stored?
Which actions require approval?
What changes when Autopilot is enabled?
What privileges does an integration receive?

Open source does not automatically make software secure. It makes the implementation available for review, criticism, and improvement.

MIT also gives developers room to experiment: fork the browser, change its tools, adapt the interface, or reuse parts in another project under the license's terms. I want people building agent tools to be able to work with the implementation.

Nabsun's code is MIT-licensed. Bundled dependencies and model weights retain their own licenses and notices; those are documented in third-party notices.

Where it stands today

This is an early project, with real limitations:

No automatic updates, profile sync, or private browsing mode.
Unsigned Windows builds; macOS builds use ad-hoc signing without notarization.
Apple silicon has been tested locally; Intel Mac remains unverified. Linux release packaging is not supported yet.
The small bundled model can struggle with long tasks.
No managed enterprise policy, central action audit log, or plugin sandbox.

The README is the place to check current setup instructions and platform support.

Try it in a few minutes

Download an available build from GitHub Releases. Windows has an installer and a portable executable. The bundled model makes the download roughly 1.4 GB; verify your download against the release's SHA256SUMS.txt.

Or, with Node.js, npm, and Git installed:

git clone https://github.com/naveenalavilli/nabsun.git
cd nabsun
npm ci
npm run fetch:model
npm start

If Electron did not download during installation, run npm run setup. Linux source setup requires manual engine setup; follow the instructions printed by fetch:model.

For a first task, open a public documentation page, press Ctrl+Shift+A, and ask:

Summarize this page, identify the prerequisites, and link to the sections I should read next.

Then try comparing two tabs. Start with something whose answer you can check.

If you want to contribute, the contributor guide is the starting point. Reproducible website failures, clearer permission flows, and improvements to page tools would all be useful feedback.

What is one browser task you would hand to an assistant—and what would you need to see before letting it act?

The Validation Rule That Was Itself Invalid

Naveen Alavilli — Wed, 23 Sep 2026 21:31:16 +0000

I lost a save cycle last week to a bug that I now think is one of the most under-discussed failure modes in configurable systems: a validation rule that was itself incompletely configured.

Not invalid data. An invalid rule.

The setup

If you have ever built or maintained a form builder, you know the shape. Forms are not code, they are data, arranged in a hierarchy that looks roughly like this:

Form
└── Tab
    └── Section
        └── Question
            ├── type (text, date, number, radio, multi-select, ...)
            └── validations[]

A question carries a type and a list of validations. Text questions might accept MaximumLength, MinimumLength, Email, PhoneNumber, Required. List questions bind to a shared option set so that "County" means the same 254 choices everywhere it appears. Authors compose forms in a UI, hit save, and the whole tree is persisted as a draft. Publishing is a separate, explicit step.

This is a good architecture. It is also where the trap lives.

The trap

Most validations are a single flag. Required looks like one too. You add it to a question and move on.

Except Required was not a flag. Selecting it rendered a second dropdown, with two choices, something like Required and Semirequired - a genuinely useful distinction when a field must be answered before publication but may be left blank during intake.

That second dropdown had no default.

So the rule sat there, attached to the question, looking complete in the list of validations, carrying no answer to the question "required how?" I built out the rest of the form. Fifteen or so questions. Hit Save.

'Required' validation type is required

Inline, per question, for every question where I had added Required and not set the sub-type. The save was rejected. The error was accurate. It was just forty minutes late.

Why this class of bug happens

The rule had two states that the model could not distinguish:

Not configured yet - the author is mid-edit, nothing is wrong
Configured to nothing - the author has moved on, and this is now broken

Both serialize identically. A Required validation with a null sub-type. The only thing separating "in progress" from "broken" is whether the author intends to come back to it, and intent is not a column.

So the system deferred the judgment to the only moment it could be sure the author was finished: submit. That is a reasonable engineering decision and a poor authoring experience, and both things are true at once.

Three ways out

Make the invalid state unrepresentable. If Required always needs a strictness, then the rule is not Required plus a modifier, it is two distinct rules: Required and Semirequired. One dropdown, no sub-dropdown, no null state. Most "field A is mandatory when field B is set" configuration problems dissolve the moment you stop modelling the dependency and start enumerating the valid combinations.

Default to the safe option. If enumeration is genuinely awkward, pick a default. Strict Required is the conservative choice: it can only ever reject data that a laxer setting would have let through. An author who wanted Semirequired will notice. An author who wanted Required and got null will not.

Validate at the point of edit. If you must keep the null state, do not save it up for submit. The moment focus leaves a half-configured rule, mark it. A red dot on the question in the tree costs nothing and turns a forty-minute feedback loop into a four-second one.

Any one of these would have saved the cycle. The third is the cheapest to retrofit and the least satisfying, because it treats the symptom.

The part that generalises

Configuration is code without a compiler.

When behaviour lives in a database rather than a source file, everything the type system used to do for free becomes someone's explicit responsibility. A half-written if statement will not compile. A half-written validation rule saves cleanly, sits in a table, and waits.

The instinct that serves me best here is to ask, of any config schema: what is the set of rows this table can hold that no author would ever have meant? If that set is not empty, the schema is doing less work than it should, and the difference is being paid for at save time by whoever is holding the keyboard.

Worth an hour of design. Cheaper than forty minutes and a lost form.

Working notes from building form-driven systems. If you have fought the same fight in a different builder, I would like to hear how you modelled your way out.