# Hay > Documentation for Hay plugins, SDK 0.1, packages and the discoverable registry protocol. Hay requires a global account sign-in. The implemented primary flow uses Continue in browser at app.hay.so, explicit Continue to Hay and Open Hay; the native email-code fallback remains. One email-verification flow signs in existing users or creates a new account only after a correct code. Optional Choose your handle offers public Display name/Handle, Save profile and Do this later, preserving the original request/return; choosing a handle never publishes code. Availability is authenticated/advisory, and final save reuses the account’s existing personal publisher identity. Existing profileless sessions remain usable. New onboarding has isolated test coverage, with no new production verification claimed. Web HTTP-only host cookies and native encrypted credentials are separate sessions. App callback completion requires a native-held PKCE verifier plus the single-use callback code; neither page visits nor polling alone approves sign-in. Manage on web uses an explicit two-minute handoff bound to the first browser. Profile controls and sign-out affect their respective web or native session. Isolated backend/synthetic-browser checks cover the unified protocol. Live installed-app retention and scoped DNS fallback plus Chrome’s explicit legacy-to-new browser carry are now separately verified. Local plugins, custom registries and authenticated personal publication are implemented; the legacy account service and plugins.hay.so use D1, with earlier live checks for inbox-code sign-in, publication, history, revocation and host download/install. New default account UI/API uses app.hay.so; legacy accounts.hay.so API requests stay served without bearer redirects. Exact old-to-new encrypted native session migration and a short-lived one-use browser-bound web handoff preserve valid logins with explicit identity confirmation and no new inbox code solely for the move. Migrated browser cookies share web-session revocation across both hosts and preserve validated pending app sign-in destinations; native sessions remain independent. Cookies remain host-only; account HTML referrers are same-origin and API JSON referrers are no-referrer. The new account origin is deployed and its HTTP/TLS routing checks passed through its published address with normal hostname validation, without system/app DNS changes. Scoped native fallback and migration regressions passed, including three isolated real-service Electron journeys. The existing legacy Chrome login was retained after deployment without another email code. After Keychain approval, installed Hay retained the same account/workspace and opened authenticated legacy Manage on web, verifying live scoped native fallback. Chrome completed explicit same-identity carry to app.hay.so without new email/code or logout. Canonical native fallback retirement is regression-covered only; normal Node/macOS getaddrinfo recovery remains pending. The full published-address live HTTP check preserved normal TLS hostname validation without system/app DNS changes. Only credentials retained for the exact old-to-new production pair may retry their original HTTPS host on ENOTFOUND/EAI_AGAIN before a canonical response; fresh sign-in, custom servers, certificate/HTTP errors and other failures never qualify. Keep the encrypted origin legacy until canonical validation succeeds; then resave and retire fallback. A validated legacy Manage on web URL is allowed within that migrated-login scope. The first public release is halil.documents 0.1.1. Connect a registry base address such as plugins.hay.so; discover .well-known/hay-registry.json for paged catalogs and direct release lookup. Live discovery, pages, exact release lookup and a fresh-workspace installation through the updated client are verified. Static registries use a discovery descriptor pointing to index.json. Only discovery HTTP 404/410 permits that legacy fallback. All endpoints and artifacts resolve against the same registry base; public/custom requests carry no credentials and redirects are refused. Client browsing is bounded at 5,000 releases / 100 pages / 20 MB / 30 seconds; direct release installation skips catalog traversal, not review or integrity checks. Live packaged sign-in, the global publisher display and authenticated release history are verified. Production publication and fresh installation were checked separately; the full native publish click-through previously ran against a local service. Public marketplace HTML, search, details and exact-release API are deployed and pass production HTTP checks. The docs-only mirror is live at plugins.hay.so/docs/. Packaged Hay loaded its signed-in account’s empty personal registry. Its built-in browser followed a live marketplace link to the native overview and inline installation request; the demonstration was declined and dismissed, preserving the workspace. Isolated native end-to-end checks completed public/private publication and approved installation. The operator record preserves the current live verification scope. Marketplace search is literal and case-insensitive (120 characters), with 24 latest plugins per page and 50 numeric-newest releases per detail page. Private reads require the account-owned personalRegistryURL and valid same-owner session, returning 401 for missing/revoked and 404 for another owner; all private responses are private/no-store and vary by Authorization. Host credentials stay only at the account API or exact own private base, never public/custom registries, URLs or plugins. Opening an install link only opens an overview; Review installation and inline approval remain separate. Workspace data stays local unless explicitly shared. The default recommendation is Workers Free with D1 and Resend email; native Cloudflare EMAIL requires a paid plan and remains optional. PostgreSQL/Hyperdrive is an alternative. Docs are also available as a [single text file](https://plugins.hay.so/llms-full.txt). ## Documentation - [Hay documentation](https://plugins.hay.so/docs/index.md): Build a plugin, keep your work local, and share it when it is ready. - [Hay accounts](https://plugins.hay.so/docs/accounts.md): Use one Hay identity in the app and marketplace, with separate signed-in sessions. - [Find and install plugins](https://plugins.hay.so/docs/marketplace.md): Browse the marketplace, choose a release, and review installation in Hay. - [Build your first plugin](https://plugins.hay.so/docs/quickstart.md): A small local notes tool, from two source files to an installed plugin. - [Local plugins and saved work](https://plugins.hay.so/docs/local-plugins.md): Know which copy you are editing, what Hay keeps, and what leaves your Mac. - [SDK overview](https://plugins.hay.so/docs/sdk.md): Use Hay’s services through a small, permissioned browser API. - [Capabilities and review](https://plugins.hay.so/docs/capabilities.md): Declare the access your plugin needs. The user decides what to grant. - [Generation and outputs](https://plugins.hay.so/docs/outputs.md): Generate a result, save it with the task, and hand it to the next step. - [Native coding](https://plugins.hay.so/docs/coding.md): Use Hay’s coding runtime from a plugin, with scope and verification visible in chat. - [Browser and source tools](https://plugins.hay.so/docs/browser.md): Work with websites through Hay’s built-in browser, including saved sign-ins. - [Share a plugin](https://plugins.hay.so/docs/sharing.md): Move a useful tool from one workspace to another without moving private work. - [Publish to Hay](https://plugins.hay.so/docs/publishing.md): Choose a public marketplace release or a private release for your own account. - [Keep releases in your personal registry](https://plugins.hay.so/docs/personal-registries.md): Publish code for your account without listing it in the public marketplace. - [Host a registry](https://plugins.hay.so/docs/registry.md): A catalog and immutable plugin files, served from one HTTPS origin. - [Package and manifest](https://plugins.hay.so/docs/manifest.md): The self-contained files and versioned contracts Hay accepts. - [Registry contract](https://plugins.hay.so/docs/registry-reference.md): Base addresses, discovery, paged catalogs and immutable release downloads. - [Publisher API](https://plugins.hay.so/docs/publisher-api.md): Web and native sign-in, personal ownership, publication and registry reads. - [Deploy the account service](https://plugins.hay.so/docs/account-service.md): Workers, durable account storage, email delivery and explicit migrations. - [Build with an agent](https://plugins.hay.so/docs/agents.md): A practical contract for agents creating plugins and registries. ## Contracts - [SDK TypeScript declaration](https://plugins.hay.so/docs/reference/index.ts) - [Manifest JSON schema](https://plugins.hay.so/docs/reference/manifest.schema.json) - [Bundle JSON schema](https://plugins.hay.so/docs/reference/bundle.schema.json) - [Legacy registry index schema](https://plugins.hay.so/docs/reference/registry.schema.json) - [Registry discovery schema](https://plugins.hay.so/docs/reference/registry-discovery.schema.json) - [Registry page schema](https://plugins.hay.so/docs/reference/registry-page.schema.json) - [Registry release schema](https://plugins.hay.so/docs/reference/registry-release.schema.json) Schemas describe structure. Runtime checks for identity, grants, ownership, source provenance, byte integrity and cross-field constraints also apply.