Ultrahost/ docs
All examples

Example 06

Experiment

User Profiles & Activity

A living picture of each user: who they are, what they do, and who they resemble.

A profile is more than a row of fields. It is the facts you hold, the numbers that change, the things the user is connected to, and the people who behave like them. Each block adds one of those views.

Chapter one

When a user joins

Before anyone can sign in, there is a pool to hold them. Once it exists, every new user goes through the same short path.

  1. 1
    Federated Auth & User Management

    A user pool is created

    Only once, when the pool is first set up

    The Identity engine creates the pool around which direct registrations and federated users will be stored. This is a one-time setup, not something that repeats for every new user.

  2. 2
    Federated Auth & User Management

    The user is registered

    A person signs up directly, or arrives through a federated provider, and becomes a user in the pool.

  3. 3
    Authorization Layer

    Permissions are granted

    The Authorization engine records what this user is allowed to do from the very first day.

  4. 4
    Document Database

    Their profile is kept

    A JSON document holds the metadata and any extra information you want to remember about the user.

  5. 5
    Search Engine

    They become searchable

    The user is indexed, so people with the right access can find them by name, trait, or anything else in the profile.

Chapter two

When a user uses the application

Every visit repeats the same two questions: who is this, and are they allowed to do what they just asked.

  1. 1
    Federated Auth & User Management

    The user is authenticated

    The Identity engine verifies who they are and hands back an access token that works across the whole application.

  2. 2
    Authorization Layer

    Each action is checked

    The Authorization engine verifies the token’s permissions for every action, in the frontend and in the backend.

Chapter three

When you want to understand a user

Over time, each user leaves traces. Four blocks turn them into four different views of the same person.

Someone asks about a user

An analyst, a recommendation, or an assistant wants more than the profile fields.

  • Over time

    How their activity changes

    Every user-related metric is stored as a series, so trends, streaks, and drops can be read directly.

    Timeseries Database

  • In context

    What they are connected to

    A user graph relates the person to every entity in the system they touch, from projects to purchases.

    Graph Database

  • By resemblance

    Who behaves like them

    Users and their activity are embedded, so similar people can be classified and clustered together.

    Vector DB

  • In documents

    What is written about them

    Additional documents related to the user are loaded and retrieved when more context is needed.

    RAG

Make it yours

Variations worth trying

  • Start with profile data and activity metrics, and leave clustering for later.
  • Keep the psychographic graph separate from the relationship graph if they have different audiences.
  • Add sign-in with Federated Auth if the profiles need to be tied to real accounts.

Starting point

Ask your coding agent for your version

Use this prompt as a starting point, then change whatever does not fit your idea.

Build user profiles that hold metadata, track activity over time, are searchable, are connected to the rest of the system, and can be compared with similar users.

Use these Ultrahost building blocks, in this flow.

When a user joins:
1. Federated Auth & User Management (only once, when the pool is first set up): The Identity engine creates the pool around which direct registrations and federated users will be stored. This is a one-time setup, not something that repeats for every new user.
2. Federated Auth & User Management: A person signs up directly, or arrives through a federated provider, and becomes a user in the pool.
3. Authorization Layer: The Authorization engine records what this user is allowed to do from the very first day.
4. Document Database: A JSON document holds the metadata and any extra information you want to remember about the user.
5. Search Engine: The user is indexed, so people with the right access can find them by name, trait, or anything else in the profile.

When a user uses the application:
1. Federated Auth & User Management: The Identity engine verifies who they are and hands back an access token that works across the whole application.
2. Authorization Layer: The Authorization engine verifies the token’s permissions for every action, in the frontend and in the backend.

When you want to understand a user:
- Over time (Timeseries Database): Every user-related metric is stored as a series, so trends, streaks, and drops can be read directly.
- In context (Graph Database): A user graph relates the person to every entity in the system they touch, from projects to purchases.
- By resemblance (Vector DB): Users and their activity are embedded, so similar people can be classified and clustered together.
- In documents (RAG): Additional documents related to the user are loaded and retrieved when more context is needed.

Treat this as a starting point. Keep the parts that fit my idea and adapt the rest.

Next example

Role-Based Access Control