Personality
Node identity and uniqueness
Personality
How OctoMY™ gives each node a unique, consistent identity that's both machine-verifiable and human-friendly.
Did You Know?
The name "Personality" was chosen because it encompasses more than just identity. Like a human personality, a node's Personality includes how it looks (identicon and colors), what it's called (generated name), and even how it sounds (voice characteristics). All of this is deterministically derived from a single cryptographic key.
What is Personality?
Every OctoMY™ node has a Personality - a set of deterministically generated identity traits derived from the node's cryptographic key. This makes each node unique and recognizable.
Generated traits
| Trait | Description |
|---|---|
| Name | Unique generated name (e.g., "Blue Spark", "Red Nova") |
| Identicon | Visual pattern unique to this key |
| Colors | Primary and accent colors |
| Voice | Text-to-speech voice characteristics |
How personality is generated
Personality derives from the node's RSA key pair through deterministic random generation:
Key property: Determinism
The same key always generates the same personality traits. This means:
- Personality survives application restarts
- Personality is consistent across different devices (if key is transferred)
- Other nodes see the same personality for a given key
The identicon
The identicon is a visual representation of the node's cryptographic identity.
Purpose
- Quick visual verification - Users can glance at identicons to verify identity
- Memorable - Patterns are easier to remember than hex strings
- Tamper-evident - Any key change produces a completely different identicon
Example
Generated names
Each node receives a unique generated name combining descriptive words.
Name generation
Names are generated from word lists seeded by the key:
- Adjective + Noun combinations
- Alliterative options
- Memorable and pronounceable
Examples
- "Blue Spark"
- "Crimson Runner"
- "Silent Guardian"
- "Amber Echo"
Name properties
- Unique - Extremely low collision probability
- Consistent - Same key always generates same name
- Human-friendly - Easy to say and remember
- Localizable - Word lists can be translated
Colors
Each node has generated colors used throughout the UI.
Color usage
| Color | Usage |
|---|---|
| Primary | Main accent color, identicon |
| Secondary | Complementary highlights |
| Background | Optional themed backgrounds |
Color properties
- Derived from key hash
- Guaranteed sufficient contrast
- Consistent across platforms
Voice
For nodes with audio output, personality includes voice characteristics.
Voice parameters
- Pitch - Base pitch offset
- Speed - Speaking rate
- Timbre - Voice quality characteristics
Usage
- Text-to-speech announcements
- Autonomous interaction responses
- Status notifications
Personality vs identity
| Aspect | Identity | Personality |
|---|---|---|
| What | Cryptographic key pair | Generated traits |
| Purpose | Authentication, encryption | Human recognition |
| Storage | Keystore | Computed on demand |
| Verification | Mathematical | Visual/auditory |
Personality makes cryptographic identity accessible to humans.
Transferring personality
Since personality derives from the key:
Backup and restore
- Export key pair from node
- Import to new device
- Personality automatically matches
Implications
- Same robot on new hardware keeps identity
- Users recognize the familiar personality
- Trust relationships transfer with key
Warning: Key sharing
If keys are copied to multiple devices:
- All devices have same personality
- This can cause confusion
- Generally not recommended
Personality in LLM interactions
When LLMs interact with or through a node, personality provides:
- Consistent voice - LLM outputs use node's voice characteristics
- Named identity - LLM can refer to self by generated name
- Visual continuity - UI elements maintain personality colors
Delivery (birth) process
When a node starts for the first time, it goes through the "delivery" process to create its identity.
AppContext
When a node starts, it receives an AppContext containing:
| Component | Description |
|---|---|
| Command line options | Options set at invocation |
| Environment variables | System environment |
| Settings instance | Node settings |
| Base name | Identifying string |
| Base directory | Local filesystem location for this node instance |
| Headless mode | Whether running without GUI |
The base name allows multiple nodes to run on the same computer by creating separate base directories side by side.
Identity components
All nodes have these components relating to identity:
| Component | Responsibility |
|---|---|
| KeyStore | Asynchronous loading/storing of local key pair, public keys of associates, key generation, and key lookup by ID |
| LocalIdentityStore | Asynchronous loading/storing of local identity (ID, Node Type, Role, Birth Date, Name, Gender) - except the key pair |
| NodeIdentity | Wraps LocalIdentityStore data with proper selectors |
First-time startup
When started for the first time:
- Base directory and settings files are missing
- Node UI guides user through initialization:
- Generation of ID
- Configuration of hardware (Agent only)
- Pairing with other nodes
Sanity check
After KeyStore activation, the node runs a sanity check:
| State | Condition | Result |
|---|---|---|
| Virgin | No ID exists | delivered = false, UnboxingWizard shown |
| Error | ID exists but no key | User intervention needed |
| Error | ID with key but no private part | User intervention needed |
| Delivered | ID and matching key with private part | delivered = true, normal operation |