Hi @kaiweijw @ctkm-aelf,
Marketing put together a v2 README redesign proposal aimed at fixing a few funnel issues we've been surfacing. We'd love your input before iterating further — this draft is 100% from a market lens (funnel CRO + narrative balance), and the dev/builder lens you'd bring is a different optimization target.
Context
The current README on main has a few rough edges we surfaced via a recent funnel audit:
- The 3-line subhead dilutes the canonical "localhost → MCP in 5 minutes" wedge
- No primary CTA button to the register flow
- The current
## Use Cases section is 3 abstract capability bullets that readers don't self-identify with — they don't try because they don't see themselves
The v2 draft has ~22 changes total. Most are plumbing (CTA row, demo.gif placement, badge cleanup, Why-NyxID table additions, AI-Assisted prompt cleanup). The biggest semantic change is the ## Use Cases section, which we restructured into a 6-section narrative based on ChatGPT feedback:
v2 §Use Cases · proposed (click to expand the full markdown)
## Use Cases
### Give AI agents safe access to real systems
If you use Claude Code, Cursor, Codex, or any AI agent that calls APIs, you eventually run into the same problem: the agent needs access, but your credentials should not be sitting in `.env` files, duplicated across tool configs, or exposed to an LLM provider through an accidental prompt leak.
NyxID keeps upstream credentials on the server side and gives each tool its own scoped token. You configure access once, then see in a single audit log which agent called which API, when, and under which scope.
### Reach local services without opening ports
Many useful systems do not live in the cloud. They run on your laptop, a Raspberry Pi, a homelab server, an n8n workflow, a local Postgres database, or a Home Assistant setup.
A lightweight NyxID node runs on your machine and maintains an outbound WebSocket connection to the NyxID gateway. That means a cloud-based AI agent can securely reach approved local services without you opening firewall ports or exposing your network directly.
### Connect agents to the systems you actually use
With NyxID, AI agents can work with both cloud and local systems:
- production data and internal APIs
- billing systems and dashboards
- local databases and development services
- Home Assistant and IoT devices
- n8n workflows and homelab tools
The agent sees only what you allow, through scoped tokens and auditable access.
### Examples
**Ask:**
> "Is anyone at the front door?"
Your agent can request a frame from the front-door camera connected through NyxID and summarize what it sees.
**Tell it:**
> "Dim the living room to evening mode."
The lights can actually change, through the permissions you granted.
**Ask:**
> "How are my IoT devices doing?"
The agent can check connected devices and summarize which ones are drifting from baseline.
NyxID turns AI agents from chat-only tools into controlled operators for the systems you care about. One gateway. Scoped tokens per tool. Full auditability.
What we'd love your input on
-
Is the v2 direction technically accurate? — especially the Examples claims (front-door camera frame fetch, light service call, IoT device health summary). They're anchored to a real dogfood session against a 230-entity Home Assistant instance, but you'd know better whether any wording overstates what NyxID actually ships today.
-
Does the 6-section narrative work for the dev audience you'd want this README to reach? — the draft assumes the entry-point reader is a Claude Code / Cursor / Codex user with a credential-sprawl problem. Does that match the audience you'd want hitting this page?
-
What would you change if you were optimizing this README from the dev side? — this is the part we most want fresh perspective on. The draft above is one angle (market lens) — your angle (dev lens) is different and equally valid. Suggestion: open a session with your own AI tool (Claude Code / Cursor / Codex) and have it propose how you'd restructure the README for the dev audience you'd want reaching it. Treat our v2 draft as one input, not the answer. If your dev-lens take ends up notably different from our market-lens take, that's a useful signal — we'd rather merge two angles than ship a one-sided draft.
Resources
Timeline
No hard deadline — drop thoughts when you have a session window. Aiming to consolidate feedback into v3 by end of next week. Happy to jump on a quick call if easier than typing.
cc @nwnwnw413 (Ada · Marketing lead)
Hi @kaiweijw @ctkm-aelf,
Marketing put together a v2 README redesign proposal aimed at fixing a few funnel issues we've been surfacing. We'd love your input before iterating further — this draft is 100% from a market lens (funnel CRO + narrative balance), and the dev/builder lens you'd bring is a different optimization target.
Context
The current README on
mainhas a few rough edges we surfaced via a recent funnel audit:## Use Casessection is 3 abstract capability bullets that readers don't self-identify with — they don't try because they don't see themselvesThe v2 draft has ~22 changes total. Most are plumbing (CTA row, demo.gif placement, badge cleanup, Why-NyxID table additions, AI-Assisted prompt cleanup). The biggest semantic change is the
## Use Casessection, which we restructured into a 6-section narrative based on ChatGPT feedback:v2 §Use Cases · proposed (click to expand the full markdown)
What we'd love your input on
Is the v2 direction technically accurate? — especially the Examples claims (front-door camera frame fetch, light service call, IoT device health summary). They're anchored to a real dogfood session against a 230-entity Home Assistant instance, but you'd know better whether any wording overstates what NyxID actually ships today.
Does the 6-section narrative work for the dev audience you'd want this README to reach? — the draft assumes the entry-point reader is a Claude Code / Cursor / Codex user with a credential-sprawl problem. Does that match the audience you'd want hitting this page?
What would you change if you were optimizing this README from the dev side? — this is the part we most want fresh perspective on. The draft above is one angle (market lens) — your angle (dev lens) is different and equally valid. Suggestion: open a session with your own AI tool (Claude Code / Cursor / Codex) and have it propose how you'd restructure the README for the dev audience you'd want reaching it. Treat our v2 draft as one input, not the answer. If your dev-lens take ends up notably different from our market-lens take, that's a useful signal — we'd rather merge two angles than ship a one-sided draft.
Resources
git pullon the Marketing repo and open it locally.Timeline
No hard deadline — drop thoughts when you have a session window. Aiming to consolidate feedback into v3 by end of next week. Happy to jump on a quick call if easier than typing.
cc @nwnwnw413 (Ada · Marketing lead)