Why work programs are becoming ordinary data
A clear account of the executor/store boundary and why the runtime object can become a small capability map.
Current product direction · World v2
World is the Hara community's shared front page: articles from submitted feeds, short clippings, ranked discussions, threaded comments, GitHub-backed contributor profiles, and a visible sense of who is around. Tutorials, courses, and learning progression live at learn.hara-lang.org.
Screen 01 · Shared front page
The front page behaves like a focused Hara community board. Every item keeps source provenance and a clear path into its discussion.
Hara community
Ranked by active discussion and recent community votes.
A clear account of the executor/store boundary and why the runtime object can become a small capability map.
“A protocol should describe the boundary, not become the thing doing the work.”
Clipped from the new executor/store design note, with a short comment about native parity.
(intern-all std.foundation
[work-spec submit! complete!]) A small example from the ongoing portable façade cleanup.
Release notes, migration examples, and the maintained namespace list are attached to the contributor profile.
World ranks articles, clippings, package releases, and one daily snippet.
Syndicated articles retain their canonical publisher, submitter, and source link.
Every object leads into a thread rather than a separate social feature.
Screen 02 · Article and comments
Comments link to GitHub-backed people. A bot may comment only through a visible owner relationship, and its owner's presence is shown beside the bot identity.
The useful boundary is becoming surprisingly small: an algebra describing what should happen, an executor, a store, and a map of capabilities.
Once the runtime stops carrying identity of its own, the same work value can move between an ephemeral executor, a durable executor, and a browser evaluator without changing its public form.
step :code/list
function list-code-units
boundary checkpointedThe discussion below is about whether anything important is lost when runtime becomes ordinary data.
I like the smaller public boundary. Should capability lookup remain a plain map lookup before executor dispatch?
I checked the current implementations. Three executors read capability keys before dispatch; two retain a runtime wrapper.
That inventory makes the migration concrete. I would keep capability resolution outside IWorkExecutor.
Related package release: std.work 0.4.2 includes the first executor/store split and migration notes.
Usernames, maintainer roles, and bot owners resolve to a contributor profile.
Thread depth is visible without becoming a narrow staircase.
Bot attribution is part of the comment header and receipt.
Screen 03 · Public digest
Anyone can subscribe without creating a World profile. The digest combines community posts with package and namespace activity.
Wednesday · 19 August
Chronological updates from submitted feeds, packages, namespaces, and community threads.
Released by @cora · 14 comments · 3 maintained namespaces updated
From hara.devlog.org · submitted by @mina · 42 comments
Reviewed contribution record · 26 merged changes · badge earned
(intern-all std.foundation
[work-spec submit! complete!])Selected from the portable façade cleanup · 27 comments
RSS source submitted by @jo · graphics, wasm, animation
An email address is sufficient for a digest subscription.
What's new is chronological; what's hot reflects active discussion and votes.
Package releases and namespace stewardship appear without becoming separate World products.
Screen 04 · Feed directory and submission
People submit RSS or Atom feeds through a first-party form. GitHub identity establishes the submitter, while review protects provenance, permission, and relevance.
Community sources
Runtime architecture, type systems, and portable tooling.
Wasm graphics, procedural animation, and visual experiments.
Package releases, deprecations, and maintainer changes.
Submit a publication
The source remains yours. World stores the reviewed registration and always links readers to the canonical article.
The browser cannot invent source ownership or reviewer-controlled status.
The original site remains the article destination and source of truth.
GitHub remains the review backend, not the visitor-facing data-entry interface.
Screen 05 · GitHub contributor profile
Profiles explain what a person publishes, which namespaces they maintain, what they contributed, and which bots they own.
GitHub contributor
@mina · Melbourne · online now
Maintaining work execution, portable storage, and the community build bot.
Work algebra, executor, and store interfaces.
Durable SQLite work store and receipt ledger.
Inspection tools for work programs.
Badges attach to reviewed contribution facts, not arbitrary engagement points.
Publishes and maintains a package release.
Maintains a reviewed public namespace.
Substantive reviews accepted across changes.
Submitted and maintains a community source.
Every bot comment links back to this owner profile.
Posts repository inventories and build observations when invoked.
Posts reviewed package-release summaries.
Profiles answer what somebody maintains and publishes.
Each badge maps to reviewed contribution or registry facts.
Registered bots inherit visibility and accountability from a GitHub owner.
Screen 06 · Presence
Presence shows optional, coarse activity context—reading, commenting, or maintaining—without adding messages or another real-time social product.
Live community
The map creates ambient community awareness without introducing messaging.
Activity is grouped into reading, commenting, and maintaining.
Bot nodes always display their owner and owner presence.