Login Form and Signup Form: real accounts, entirely on the user's own machine

Desktop projects have their own Login Form and Signup Form blocks, separate from the ones on Web Application projects. A Desktop app has no server of its own, so these check a real, working account against data stored only on that one installed copy of the app, never against a hosted database and never synced anywhere.

How the blocks work together

Give a Signup Form and a Login Form the same Storage Key and they share one local account store. Signup checks the identifier isn't already taken and that the password and confirmation match, then saves the account; Login checks a typed identifier and password against it. A Change Password Form using that same Storage Key re-checks the identifier and current password, then replaces the stored password only on a real match, it doesn't rely on any "already logged in" state, since none of these blocks track a session. Passwords are never stored as plain text, the compiled app derives a salted, one-way hash before writing anything to disk, the same "can't be reversed" guarantee described in "The Custom Code block, and how it's kept safe" applies here for a different kind of data.

What this deliberately doesn't do

• No password reset: there's no email server on a local-only app to send a reset link through. Losing the password means the account can't be recovered from inside the app (Change Password only works when you already know the current one).
• No cross-device accounts: an account created on one installed copy doesn't exist on another, each copy has its own separate local store.
• No admin view of registered accounts: there's no "reveal" or export for what's been signed up, by design, the same way a Local Record Form's "secure" fields can't be read back either.