> ## Documentation Index
> Fetch the complete documentation index at: https://docs.array.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Terms

> The product names, and the vocabulary these docs use. Short definitions, in the order you are likely to meet them.

<Note>
  **Maturity:** Reference. If a term here contradicts a page elsewhere in this
  guide, the term is the bug. Tell us.
</Note>

## The products

Three names start with Alive and they are not the same thing: **Alive** is the
app, an **Alive ID** is a person's identity, and the **Alive Internet** is what
the whole thing is for.

**Array Network** is the multi-tenant infrastructure
that powers the protocol. It is the settlement layer and the on-chain trust
graph around it. It is agnostic of applications and social accounts, and sees
commitments, public keys and ArrayIDs. Ethereum is to dApps what Array Network
is to identity-aware applications.

**Array Identity** is the identity provider built on Array Network. It handles
key derivation, backup and recovery, social bindings, the client directory your
application registers in, and the consent ceremony that mints a login token.
`array-identity` is also the name of the deployed service, which is why it
appears in hostnames and package names.

**Alive** is the first-party consumer app, previously called Vibecheck. It
holds a privileged position in the protocol, as the only writer of admission
and connections to the graph, but it is also a customer of Array Network like
any other application. Being both is deliberate, and the two roles use separate
credentials.

**Vibecheck** survives as an identifier rather than a product name. It is the
company, Vibecheck Labs, and it appears in three places you will type: the
`@vibechecklabs` package scope, the GitHub organisation, and the app's
registered URL schemes (`vibecheck`, `vibecheck-testnet`, `vibecheck-dev`).
None of those change with the app's name.

**Alive ID** is the user-facing name for a person's identity. It is what the
consent sheet shows and what a disclosed sign-in hands to you. More broadly it
is the gateway to the Alive Internet, so the term carries more than the string
does.

**ArrayID** is the same thing in code and in protocol documentation. It is a
254-bit value derived from the user's initial Baby JubJub public key,
`Poseidon1(bjj_pub_x)`, which makes it self-certifying: anyone holding the
public key can recompute the ArrayID and check it matches. It is permanent, and
keys rotate under it.

**The Alive Internet** is the idea the rest of it serves. A layer of the
internet where every interaction is grounded in a verified human network,
where bots cannot exist by construction, and where the trust signal improves
under adversarial pressure rather than degrading. It is a concept rather than a
component, and nothing in code is named after it.

## Terms in this guide

**Relying party (RP)** is you. An application that sends a sign-in request and
verifies what the user's device signs. The term comes from the identity
standards these docs build on.

**Self-issued** describes who signs the login token. The user's device signs
it, not an identity provider, which is why your server can verify it without
calling Array.

**Subject modes.** A sign-in is either **disclosed**, which hands you the
user's ArrayID, or **pairwise**, which hands you a per-application pseudonym
that is stable for you and uncorrelatable anywhere else. You choose per
request.

**Identity facet** is the scoped pseudonym behind a pairwise subject. It is
derived from the user's key and your application's scope, so it is the same
every time that person signs in to you, and unrelated to what they present
elsewhere.

**Verdict tier** is how strong a verified login is: `key_possession`, then
`self_certified`, then `membership_proven`. Only the last carries a sybil
guarantee.

**Membership proof** is a zero-knowledge proof that the user is in the identity
tree. It is what raises a login to `membership_proven` and sets the `unique`
flag.

**Roots** are the Merkle roots of that tree. The indexer signs them with an
operator key and publishes them on a feed. Your verifier accepts a proof only
against a root it has verified against an operator key you pinned yourself.

**Client directory** is the public record of registered applications, holding
your display name, your allowed response endpoints and your presenter keys.
The device reads it before showing a consent sheet, which is what stops one
application impersonating another.

**Presenter key** is the key you register and sign sign-in requests with. Array
holds only the public half.

**Nonce** is the single-use value your backend issues and burns on verification,
so a captured token cannot be replayed. You run that store, not Array.

**M2M key** is a machine-to-machine API key identifying your application to
Array services. It never resolves a person on its own. We provision and issued
this, per-application.

**Capability grant** is a second artifact the device can mint alongside a login
token, authorising you to ask Array specific questions about that user. See
[Capability grants](/build/capability-grants).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.