clusterflux-public/market_plan.md

Disasmer Market Plan and Abuse Notes

Positioning

Disasmer is an open-source distributed Wasm runtime. Its initial primary use case is as a build system.

The product promise:

real source file
normal debugging
local-first execution
distributed builds when needed
operator UI instead of CI YAML
self-hosted nodes when users want control
managed coordination when users want convenience

The hosted service is primarily the control plane:

identity
coordinator state
virtual process registry
node discovery
debug sessions
operator panels
artifact metadata
optional managed nodes later

The coordinator should not be a free general-purpose compute platform.

---

Open-source strategy

Disasmer should be open source by default:

runtime
SDK
CLI
VS Code extension
node runtime
local coordinator
protocol specs
example build programs

The hosted product should monetize convenience, scale, reliability, and managed infrastructure rather than hiding the core runtime.

Recommended split:

Open source:
  run Disasmer locally
  run your own coordinator
  attach your own nodes
  debug programs
  use the build-system features

Hosted service:
  managed coordinator
  identity/login
  public endpoint
  node rendezvous
  team management
  hosted operator panels
  artifact metadata/storage
  managed build nodes later
  uptime/support/compliance later

---

Community hosted tier

Community tier users get:

1 active virtual process
zero-capability hosted Wasm control loop
tiny memory/state limit
tiny CPU/fuel limit
tiny log limit
tiny artifact/state retention
operator panel access
ability to attach their own node(s) so these limits don't matter

The hosted free Wasm process has zero capabilities:

no network
no host filesystem
no secrets
no containers
no native commands
no outbound HTTP
no inbound ports
no arbitrary syscalls
no access to other users

It exists only to let users try the system and orchestrate their own attached nodes.

Real work in the community tier should run on user-provided nodes.

---

Paid products

Likely paid tiers:

Pro coordinator:
  more virtual processes
  more state/log retention
  private projects
  longer-running processes
  more operator panels
  artifact storage

Team coordinator:
  shared nodes
  roles/permissions
  audit logs
  team secrets
  organization billing

Managed nodes:
  Linux builders
  Windows builders
  macOS builders if feasible
  GPU/specialized nodes later
  warm caches
  reserved capacity

Enterprise:
  private coordinator deployment
  SSO/SAML/OIDC
  compliance controls
  support/SLA
  custom retention
  on-prem/hybrid support

Marketplace later:
  resold node capacity
  verified builder pools
  specialized environments

Primary revenue should come from:

managed coordinators
managed nodes
team features
artifact/log retention
support
enterprise deployments

Avoid depending on community tier compute economics.

---

Main abuse principle

Assume every public input is hostile:

users
programs
nodes
operator panels
logs
artifacts
OAuth identities
build files
container images
Git repos

The coordinator must coordinate untrusted systems without trusting them.

---

Abuse paths to derisk

1. Community tier compute abuse

Risks:

crypto mining
brute force jobs
scraping loops
infinite loops
account farming to multiply community tier resources

Controls:

fuel metering
wall-clock limits
memory limits
wake-up limits
per-account quotas
per-IP signup/rate limits
no hosted containers on community tier

---

2. Coordinator denial of service

Risks:

too many API calls
too many virtual process events
too many logs
too many UI updates
too many node heartbeats
too many task spawn attempts
huge metadata objects
expensive queries

Controls:

quota every API
rate-limit event streams
cap log size
cap UI update frequency
cap metadata size
cap process lifetime
use backpressure everywhere
admin kill switch

OWASP API Security lists unrestricted resource consumption as a major API risk, including CPU, memory, storage, bandwidth, and paid provider resources.

---

3. Network abuse

Risks:

port scanning
DDoS coordination
spam/proxy behavior
credential stuffing
webhook abuse
using Disasmer as rendezvous/C2 infrastructure

Controls:

free hosted tasks have no network
node traffic requires authenticated sessions
rate-limit rendezvous APIs
no public inbound ports by default
restrict relays
monitor suspicious fan-out
block known-abusive behavior

---

4. Artifact and log abuse

Risks:

malware hosting
phishing pages
illegal content
oversized binaries
secret leakage in logs
using logs as data exfiltration
using artifacts as free storage/CDN

Controls:

tiny free retention
size limits
download limits
content reporting/removal
malware scanning where practical
secret redaction tools
private-by-default artifacts
no public hosting by default

---

5. Secret theft

Risks:

malicious build scripts stealing tokens
operator panel phishing
exfiltration through logs/artifacts
self-hosted node compromise
repo credentials leaking into tasks

Controls:

no secrets in free hosted tasks
scoped short-lived task tokens
explicit secret grants
secrets never shown in UI/logs
audit access to secrets
separate coordinator identity from node identity

---

6. OAuth and account abuse

Risks:

fake account farms
stolen OAuth sessions
bad redirect URI handling
token leakage
OAuth app phishing
provider token overreach

Controls:

OIDC/OAuth with PKCE
strict redirect URI matching
verified email where possible
short-lived sessions
minimal scopes
anti-abuse signup checks
manual suspension tools

OAuth security best current practice is covered by RFC 9700.

---

7. Malicious user-provided nodes

Risks:

lying about results
faking logs
returning malicious artifacts
claiming cache hits incorrectly
exfiltrating inputs/secrets
attacking other nodes
using coordinator for discovery of targets

Controls:

never mix tenants by default
explicit node sharing only
signed node identity
per-node capability policy
artifact provenance
optional reproducible/repeated builds
trust labels for nodes

Default rule:

A user's work runs only on that user's nodes, managed paid nodes, or explicitly shared team nodes.

---

8. Cross-tenant isolation bugs

Risks:

user sees another user's process
user sees another user's logs
user accesses another user's node
artifact metadata leak
operator panel leak
bad authorization check on debug endpoint

Controls:

tenant ID on every object
authorization checks on every API
negative tests for cross-tenant access
separate storage namespaces
least-privilege service tokens
security review for debug APIs

---

9. Debugger abuse

Risks:

reading secrets through debugger
modifying task state maliciously
attaching to another user's process
debug endpoint used as data exfiltration path
huge memory reads causing DoS

Controls:

attach requires owner/team permission
debug memory reads are quota-limited
debug sessions are audited
no cross-tenant debug access
hosted free tasks have no secrets

---

10. Operator panel phishing

Risks:

fake login forms
fake GitHub authorization prompts
malicious links
misleading buttons
HTML/script injection

Controls:

built-in widgets only
no custom HTML/JS in MVP
escape all text
label panels as user-provided
no password fields initially
restricted external links
no OAuth flows inside user panels

---

11. Container/runtime abuse

Risks:

container escape
privileged container misuse
Docker socket exposure
host filesystem mount abuse
kernel attack surface
supply-chain malware

Controls:

no free hosted containers
managed containers only on hardened paid nodes
rootless where practical
seccomp/AppArmor/SELinux
no privileged containers by default
no Docker socket mounts
read-only mounts where possible
network egress policy

NIST SP 800-190 covers container security concerns; Docker documents rootless mode and seccomp profiles as important hardening tools.

---

12. Supply-chain abuse

Risks:

malicious Disasmer examples
malicious Containerfiles
malicious flakes
dependency confusion
poisoned build caches
untrusted public templates

Controls:

signed official examples
template review
cache namespace separation
provenance metadata
dependency lockfiles
clear trust warnings before running third-party projects

---

13. Cost amplification

Risks:

API calls that trigger expensive work
artifact sync causing storage costs
log spam causing storage costs
OAuth/webhook/email costs
relay bandwidth costs

Controls:

hard spend caps
per-user cost budgets
quota before work starts
paid-only expensive features
separate flush from sync
bulk data never routed through coordinator by default

---

Free-tier product rule

Free hosted mode should prove the product, not subsidize heavy builds.

It should support:

creating a virtual process
opening an operator panel
testing the SDK
attaching a user's own node
running tiny control logic
spawning tasks onto the user's node
using the debugger flow

It should not support:

hosted CI workloads
hosted arbitrary containers
large artifact storage
public file hosting
network scanning
long-running compute

---

MVP commercial rollout

Phase 1:

open-source local runtime
free hosted coordinator
one zero-capability hosted process
attach-your-own-node flow
VS Code extension
operator panel
basic abuse controls

Phase 2:

paid coordinator limits
team projects
more processes
longer retention
private artifacts
better logs

Phase 3:

managed Linux nodes
warm build caches
paid artifact storage
organization billing

Phase 4:

Windows/macOS builders
enterprise/private coordinators
SSO/audit/SLA
node resale or marketplace

---

Success metric

The free product should let someone do this quickly:

sign in
create one Disasmer program (through the website, terminal or vscode for example)
open its operator panel
attach their own machine as a node and verify this in the coordinator UI
spawn a build task onto that node
debug it from VS Code
see artifacts/logs in the coordinator UI

That proves the platform without giving away expensive compute.

---

References

OWASP API Security Top 10 2023: Unrestricted Resource Consumption
https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/

OAuth 2.0 Security Best Current Practice, RFC 9700
https://datatracker.ietf.org/doc/rfc9700/

NIST SP 800-190: Application Container Security Guide
https://csrc.nist.gov/pubs/sp/800/190/final

Docker Rootless Mode
https://docs.docker.com/engine/security/rootless/

Docker Seccomp Security Profiles
https://docs.docker.com/engine/security/seccomp/