Maturity: Reference. If a term here contradicts a page elsewhere in this
guide, the term is the bug. Tell us.
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.