User

A User is a data-owning identity within an Account. OpenViking uses it to separate personal memories, private sources, and sessions. Alice and Bob can each retain long-term context while using shared team sources.

A User is the identity accessing the service. An application can map it to a person or a separate application identity. Multiple agents using one User key share that user's space; use different users when their personal data needs to remain separate.

Understand user space

Alice's directory looks like this:

viking://user/alice/
├── memories/    # Alice's long-term memories
├── resources/   # Alice's private sources
├── skills/      # Alice's private skills
├── peers/       # Alice's interaction counterparts
└── sessions/    # Alice's conversations

viking://~/ aliases the current user's home directory. It expands to viking://user/alice/ for Alice and viking://user/bob/ for Bob. Shared sources live under viking://resources/ in the same account.

Prerequisites

Complete Authentication, creating Alice and Bob as ordinary users in acme and saving acme-alice and acme-bob connections. This example creates an empty private directory and a session without triggering memory extraction.

Create private content

Alice activates her connection, checks her identity, and creates a directory:

ov config switch acme-alice
ov health -o json
ov mkdir viking://~/resources/personal-check
ov ls viking://~/resources

The listing should include personal-check. Create a session owned by Alice with automatic commits disabled:

ov session new --session-id alice-user-check --no-auto-commit
ov session add-message alice-user-check --role user --content "This is Alice's personal project discussion."
ov session get alice-user-check

Check that the session contains the message. This saves conversation content; committing starts memory extraction. See Memory usage for that workflow.

Check as Bob

Bob lists his home directory with his own connection:

ov config switch acme-bob
ov ls viking://~/resources

This lists Bob's private sources. Try accessing the directory Alice just created:

ov ls viking://user/alice/resources/personal-check

Access should be denied. Account membership enables collaboration while personal spaces remain separated by User. To share selected knowledge, Alice publishes it as shared sources, as described in Knowledge sharing.

Users and roles

The User identifies the data owner; the role determines management capabilities:

User role	Main capabilities
USER	Personal data operations and authorized shared-source access
ADMIN	Their own user space, account member management, and management of shared sources in the account

An administrator's ordinary data requests still use their own User identity. In API key mode, changing identity headers cannot switch an administrator into Alice or Bob. Platform ROOT manages accounts and other platform operations; its key is not used to read ordinary tenant data.

Applications can reuse a user identity across conversations to accumulate long-term memory. Session IDs distinguish conversations; Peers distinguish stable interaction counterparts under that user.

Check the result

Alice can access her directory and session. Bob's home alias resolves to his own space, and he cannot read Alice's private directory. If both see the same personal space, check whether they are sharing a key.

Next steps

Read Peer to organize sources and memories for different counterparts under one user. See Admin API for registration, roles, and key rotation.