A Vibelet is a compact mini‑app or widget, built using standard web technologies (HTML, CSS, JavaScript), intended to run inside a Federated Wiki page. It is minimal in external dependencies so that it remains portable and easy to embed via the `frame` plugin. A Vibelet might simulate systems, offer interactive editors, or render visualizations of data from the wiki.
Vibelets can also act as **bridges**: they import external or internally derived data into the wiki (via ghost pages or structured JSON), and export living or dynamic representations of wiki content (snapshots, simulations, charts). They let your wiki turn knowledge into interactivity.
# Characteristics & Design Principles - **Self‑contained**: all logic lives in the Vibelet file or small supporting files - **Lightweight**: no heavy frameworks or build steps—ideally plain JS - **Forkable**: users can copy, tweak, and remix Vibelets easily - **Federated**: stored in the wiki’s `assets/` folder, served over HTTP, and embedded via `frame` - **Interactive**: read from and write to the wiki (or ghost versions) in structured fashion - **Context‑aware**: Vibelets can respond to the current wiki page context, metadata, or agent output
# Scope & Constraints (Initial Focus) To ensure stability, composability, and ease of experimentation, the project begins with a **reduced scope**: - **JSON In / JSON Out**: Vibelets are restricted to accepting JSON from other wiki pages and producing valid page‑JSON for **ghost pages** - **Zero Dependencies**: Vibelets must be written as **plain, single-file HTML/JS widgets** with no external libraries or imports - **Sandboxed Display**: They must render entirely within the `frame` plugin and not modify the DOM outside their iframe - **Standard Interfaces**: The goal is to create interoperable patterns so Vibelets can be generated, understood, and extended by both agents and humans
This constraint makes the Vibelet ecosystem portable, remixable, and more easily inspectable for educational use.
# Vibe Coding & Related Services
The term **vibe coding** refers to a style of AI-assisted development where the AI is given freedom to iteratively generate code, respond to prompts, and build components rapidly. The developer’s role is more supervisory, testing, refining, and guiding rather than prescribing every detail.
- A recent study titled *Good Vibrations?* explored how developers interact with AI agents under this style
- Some emerging platforms use **Erlang-based web stacks** (e.g. **Arizona** and **Nova**) to enable high-concurrency backends for vibe-coded microservices
- These tools mirror the simplicity and reusability of Vibelets, but on the server side
- erlangforums.com 
- news.ycombinator.com
- The goal of these tools is similar: build fast, test live, deploy small
# Use of Vibelets in the Hitchhiker’s Project In your system, Vibelets function as both **presentation surfaces** and **computational units**: 1. **Agent-Generated Artifacts** - Agents generate or modify Vibelet code and place it in the `assets/` folder - Vibelets are embedded in wiki pages via `frame` and rendered live 2. **Feedback Loops with JSON** - Vibelets read structured JSON from other wiki pages (via HTTP) - They write updates as ghost pages—staging changes without committing immediately - This allows for iterative, agent-assisted workflows 3. **Educational Remixability** - Each Vibelet can be forked, edited, and used to teach concepts (HTML, JSON, agents, simulations) - Guides and plans can reference Vibelets as both tools and output
# Suggested Use Cases - A JSON-based quiz widget that loads questions from a linked wiki page - A simulation of agent task queues using wiki page metadata - A visual editor for Plan YAML blocks that outputs structured ghost pages - A minimalist D3.js bar chart Vibelet (no external scripts) reading from a data page - A LiveCode API log viewer rendered inside the wiki via a plain HTML file
# Security and Design Considerations - Run all Vibelets in sandboxed iframes - Avoid remote fetches or cross-origin requests - Validate ghost page output before committing changes - Encourage manual review before publishing agent-generated Vibelets - Allow local-only mode for educational and home-lab use
# Next Steps - Define a canonical Vibelet structure (HTML head, JS template, expected input/output schema) - Build a small gallery of example Vibelets and host them locally - Write agent plans that generate Vibelets using structured prompts - Design a LiveCode launcher and inspector for rendering or modifying Vibelet behavior - Allow for Plan-driven agent workflows that generate, validate, and embed new Vibelets via automation
By standardizing and simplifying Vibelets around JSON workflows and zero-dependency HTML, we create a clean foundation for both educational content and decentralized agent experimentation.
# See