fount Documentation

fount is a programmable, standardized, modular, and customizable AI agent runtime platform. It is designed to bridge the gap between highly efficient productivity tools (e.g., coding assistants, meeting summarizers) and immersive emotional interaction (e.g., digital companions).

Key characteristics include:

• Programmable Logic: Customize agent logic via code, not just prompts.
• Real-time Code Execution: Supports live compilation and execution of code blocks (C/C++, Rust, Python, JS, etc.) within the chat interface.
• Modular & Shareable: Agents (roles) and workflows can be encapsulated as files and shared easily.
• Cross-Platform: Runs on Windows, macOS, Linux, and Android (via direct installation or Docker).
• Extensible AI Sources: Connect to any AI provider (OpenAI, Claude, OpenRouter, etc.) using custom JavaScript in the AI Source Generator.
• Developer-Centric: Git-driven component management and VSCode integration for debugging agent logic.

fount is a programmable, standardized, and componentized AI agent runtime platform. It allows users to load various components to provide services, bridging the gap between high-efficiency productivity tools and immersive emotional interaction.

Key capabilities include:

• Agent Logic Customization: Focuses on custom agent logic rather than just prompt and UI engineering.
• Real-time Code Execution: Supports live compilation and running of code blocks (C/C++, Rust, Python, JS, etc.) with access to stdout and assembly output.
• Knowledge Assetization: Convert chat bubbles into HTML reports by dragging them to folders, or export agent workflows as shareable files.
• Extensive Integration: Connects agents to IDEs (JetBrains, neovim, Zed), browsers (to view/modify page content), Telegram/Discord (via Bot Shells), and terminals (via fount-pwsh).
• Flexible AI Source Integration: Uses JavaScript to connect to any AI source (OpenAI, Claude, OpenRouter, etc.) and supports API pooling for intelligent request routing.

This document provides a gap analysis comparing fount Chat's current capabilities against industrial-grade Instant Messaging (IM) platforms. It identifies what is currently implemented (the 'Main Path') and what is missing or intentionally omitted.

Implemented Core Features (Main Path)

• Channel Management: Permissions, reactions, pinning, voting, and sub-threads.
• Messaging: Inline replyTo, mute/care, @mention inbox, search, and forwarding.
• Reliability: Drafts (composerDraft), offline sending queues (sendQueue), and delivery status indicators.
• Media/Communication: Group calls with screen sharing, Web Push, and federated Mailbox/EVFS.

Known Limitations (Gaps)

• Voice Messaging: Currently implemented as a .wav attachment via toggleVoiceRecording. It lacks 'hold-to-talk' functionality, waveforms, or transcription.
• Read Receipts: Uses member-read-markers based on sequence watermarks (showing 'Sent' or 'Read' by others) rather than per-message individual receipts.
• Audio/Video Scale: Uses a single-process av-relay and sparse WebRTC, suitable for small communities but lacking industrial simulcast clusters or dedicated 1:1/Stage modes.
• Privacy: While the DAG (Directed Acyclic Graph) remains encrypted, the local display cache messages/{channelId}.jsonl is in plaintext.

The system follows a specific interaction baseline to separate concerns between human users, personas, and the world environment:

• Human ↔ Persona: Humans interact with a persona via Web or CLI. The persona acts as the primary I/O layer for human interaction; the UI does not bypass the persona system.
• World → Persona / Char: The world interacts with persona and char (character) entities via API calls (e.g., providing views via GetChatLogForViewer, contributing prompts, or arbitrating speech order).
• World → Chat Storage / P2P Layer: The world utilizes the chat storage and P2P layers through WorldChatHost.
• Char Internal: A char uses AI or plugins to generate replies. Reply generation is strictly the responsibility of the char. The unique entry point for generating a reply is char.GetReply. The shell (platform/wrapper) does not manage or provide official reply generation libraries.

Key Principles:

• Separation of Trigger and Generation: The decision to speak (trigger) is handled by the chat pipeline, while the content of the speech (generation) is handled by the char.
• Event-Driven Logic: All incoming events (chat messages or social posts) are unified under the OnMessage event. Specialized hooks (like OnMention) are deprecated in favor of checking the OnMessage context.
• Identity: The recipient of any notification, inbox, or feed is an entityHash (treating humans and agents as equivalent entities).

The system determines what a user can see in the emoji picker based on availability and usage.

Availability Rules: An emoji pack is considered Available if:

1. It is the user's own pack.
2. The user has joined the group providing the pack.
3. The user is following the entity (author) providing the pack.

Visibility (Picker Content): The picker displays a union of:

• Collections: Packs explicitly added to the user's collection (provided they are still 'Available').
• Used Packs: Packs found in the user's usage history.

Automatic Collection Logic:

• Joining a group or following an author automatically adds their defaultEmojiPackId to the user's collection.
• If an author changes their default pack, the system updates the user's collection (replacing the old default if it was present).
• Leaving a group or unfollowing an author does not remove the pack from the collection, but it will be filtered out of the picker because it is no longer 'Available'.