Database Schema

• Database Schema
  • Shared Settings Table
  • Directory Canister
    • Directory Canister Settings Keys
    • moderators Table
    • users Table
    • tombstones Table
    • reports Table
  • User Canister
    • User Canister Settings Keys
    • profiles Table
    • statuses Table
    • inbox Table
    • followers Table
    • following Table
    • liked Table
    • blocks Table
    • mutes Table
    • bookmarks Table
    • boosts Table
    • media Table
    • edit_history Table
    • hashtags Table
    • status_hashtags Table
    • featured_tags Table
    • pinned_statuses Table
    • profile_metadata Table
  • Custom Data Types
    • Visibility
    • ActivityType
    • FollowStatus
    • ReportState
  • Persistence

Mastic uses wasm-dbms for persistent storage inside the Directory and User canisters. Because wasm-dbms manages its own stable memory, ic-stable-structures cannot be used alongside it in these canisters. Configuration values that would normally live in stable cells are stored in a shared settings key-value table instead.

The Federation Canister does not use wasm-dbms; it uses ic-stable-structures directly.

Shared Settings Table

Both the Directory and User canisters include a settings table with the same schema. Each row maps an integer key to a polymorphic value (SettingValue, backed by the wasm-dbms Value type).

The Settings table and its helper methods (set_config_key, get_required_settings_value, get_settings_value, get_as_principal) live in the db-utils crate and are shared by both canisters.

Directory Canister

Directory Canister Settings Keys

moderators Table

users Table

The handle column uses HandleSanitizer (trims whitespace, lowercases, strips leading @) and HandleValidator (enforces the handle rules). See the Handle Validation page for the full specification.

tombstones Table

Retains deleted handles to block immediate re-registration and to keep an audit trail. handle uses the same sanitizer/validator pair as the users.handle column; see the Handle Validation spec.

reports Table

Stores user-submitted moderation reports. See the Reports spec for validation rules on reason and target_status_uri.

User Canister

User Canister Settings Keys

profiles Table

Single-row table holding the owner’s profile.

statuses Table

See the Status Content spec for full validation rules on content, spoiler_text, and in_reply_to_uri.

inbox Table

Stores inbound ActivityPub activities.

follow_requests Table

followers Table

following Table

liked Table

blocks Table

mutes Table

bookmarks Table

boosts Table

Tracks Announce activities emitted by the user. Each boost is paired with a wrapper row in the statuses table.

The same Snowflake is reused as boosts.id, boosts.status_id, the wrapper statuses.id, and the wrapper’s feed.id — making the wrapper status URL <actor>/statuses/<snowflake> also the canonical id of the emitted Announce activity. One sequence increment per boost; one URL that dereferences both the wrapper status and the boost activity.

media Table

See the Media Attachments spec for full validation rules on media_type, description, and blurhash.

edit_history Table

previous_spoiler_text uses the same sanitizer/validator pair as statuses.spoiler_text; see the Status Content spec.

hashtags Table

Local per-user index of hashtags referenced by the user’s statuses.

The tag column uses HashtagSanitizer (trims whitespace, lowercases, strips leading #) and HashtagValidator. See the Hashtag Validation page for the full specification.

status_hashtags Table

Join table between statuses and hashtags. Uses a surrogate id primary key because the underlying storage layer does not support composite primary keys; uniqueness of (status_id, hashtag_id) is enforced by the application layer.

featured_tags Table

Up to four hashtags featured on the user’s profile. The tag column uses the same HashtagSanitizer / HashtagValidator pair as the hashtags table.

pinned_statuses Table

Up to five statuses pinned on the user’s profile.

profile_metadata Table

Up to four custom fields shown on the user’s profile. See the Profile Metadata spec for full validation rules.

Custom Data Types

The following custom types are used in the schema and stored as compact single-byte discriminants:

Visibility

Maps to did::common::Visibility.

ActivityType

Maps to activitypub::ActivityType.

FollowStatus

ReportState

Persistence

All tables are created during canister init. Data survives canister upgrades because wasm-dbms stores everything in stable memory. The post_upgrade function does not need to re-register the schema.