Design partners

Nearglass is newly built. We are opening it to a small group of design partners: three to five teams with a real product to ship, who build on it with us while we take it from tested in our runs to proven in theirs. Keys and packages come from us directly; there is no sign-up page and nothing on public npm yet.

Apply to be a design partner.

Who we want to work withCopy Anchor Link

• Robotics and teleoperation. One operator drives a robot, a vehicle or a machine over the web while others watch, and the device needs to stop by itself when the commands stop.
• Live interactive events. Auctions, betting and live commerce, where a bid, a bet or a purchase has to land on the moment that is really happening.
• AI vision is welcome too: a model watching a live camera, with its results tied to the exact frame they came from.

What works todayCopy Anchor Link

Each feature's status, and what it was tested on, is on Feature status. Verified there, with a recorded run:

• Publishing from ffmpeg over SRT, with sound (AAC-LC turned into Opus, or Opus passed through); from a file with the nearglass command line tool; and from a device with the C library on Linux x86_64.
• Playing in Chrome on a computer over MoQ, with sound and switching between renditions.
• Controllers: one driver, many watchers, with the device stopping by itself when the driver goes away.
• Admission: viewer tokens from your backend, public admission with a publishable key, the viewer cap and its waiting line, token renewal while watching, and publisher tokens.
• Operating: usage metering, spending caps and alerts, webhooks to the operator, monitoring endpoints, regions with the nearest edge and failover, and kicking a viewer.
• Scale: 1,000 simulated viewers (software viewers that receive every frame but do not decode it) on one stream, on cloud VMs, twice (Performance).

Most of these runs were on one machine, in headless Chrome. None was on a phone, in Safari, or glass to glass.

What we build and validate togetherCopy Anchor Link

These are what we set out to prove with each partner, on your setup. They are validation targets, not promises:

• Your real devices: your cameras, encoders, robots and the phones and browsers your users have.
• Your real networks: cellular links, long distances, and viewers in a region other than the source's.
• Scale with real players: your audience size, in real browsers, not only software viewers.
• Glass to glass: from your camera to your viewer's screen, against a target we agree with you for your product.

What working together looks likeCopy Anchor Link

• A shared channel with the engineers building Nearglass.
• Direct engineering time on your integration: your encoder, your backend, your player.
• A baseline and success criteria agreed up front: what we measure, how, and the result that counts as done, written down before we start.

What partners getCopy Anchor Link

• Direct access to our engineering team.
• Priority integration and technical support.
• Real influence over the roadmap: what we build next follows what our partners need to ship.
• Early access to new capabilities before they are generally available.
• Preferred early-partner commercial terms, agreed individually.

Apply to be a design partner.