Marketplace

Documentation Index

Fetch the complete documentation index at: https://docs.myme.so/llms.txt

Use this file to discover all available pages before exploring further.

The Marfa marketplace is a surface in the web console where users browse and install things published by other Marfa users. Equivalent in shape to the Obsidian community plugin browser or the VS Code Extensions tab — in-app, not GitHub-PR-driven. Three deployment shapes coexist:

• Pure-local users never touch the marketplace. Their schemas stay private.
• Self-hosted users can mirror the registry, install via URL, or skip the marketplace entirely.
• Hosted users are the default audience.

​

What gets published

Two kinds, with a clean axis between them: declarative schemas versus active integrations. Apps (clients like Notes, the web console itself) sit outside the marketplace. The marketplace can surface them as listings — pointers to where the app actually lives — without owning their distribution.

​

The defining axis — declarative versus active

Determines runtime, trust, and install flow.

• Schemas — declarative. No runtime, no credentials. Install copies the type definition into the user’s space. Easy to inspect; low trust risk; publish freely. See Authoring types.
• Integrations — active. Running code. Install is heavier:
  • A runtime to host the code. Hosted users get hosted infrastructure; self-hosters get their own; pure-local users use the local runtime tier. The manifest’s runtime_compatibility declares which tiers the connector supports.
  • A scoped permission set declared in the manifest. Which item types it reads or writes, which extension namespaces it touches, which edge types it traverses, which OAuth scopes against the upstream service. Shown to the user at install. Explicit approval required.
  • Stronger trust signals — verified publisher, source repo visible, sandboxing where applicable.

The same split Claude takes between skills (declarative, low risk) and MCP servers (active code, verified at the publisher, user-approved at install with capabilities shown). For the Integration manifest contract and runtime tiers, see Integrations.

​

Discovery

Browse by kind. Each kind has its own manifest schema, so the browse experience can be tailored. Trust signals shown alongside listings:

• Verified publisher (GitHub-linked, domain-verified, or platform-verified).
• Install count.
• Rating.
• Source repo presence.
• Last updated.

Curation by the platform happens only for the smallest “officially blessed” set, if at all — not as a gate on every listing.

​

Versioning

Semver, server-enforced for both kinds.

• Patch and minor changes are additive only. Existing items and installed copies stay valid; consumers auto-pull.
• Major changes are effectively a new artefact. Existing installs stay on the old major; explicit upgrade is required.

Server-side diff at registration enforces correct bumps — same mechanism for type field changes and integration manifest deltas. See Authoring types. For Integrations specifically, each (name, version) pair persists as a sibling system.integration item; spaces pin to a specific version at install time.

​

Publishing flow

In-app, through the console. Authors paste or upload the artefact, fill in metadata, hit publish. What gets published:

• Schema: name, version, schema body, optional metadata (description, README, icon, source repo).
• Integration: the above plus the manifest — runtime requirements, permission scopes, OAuth requirements, webhook verification, bidirectional handling, configuration schema for the user.

Publisher identity is the Marfa handle — see Handles and publishers. One handle, two installable kinds.

​

Depublishing

Standard pattern, drawn from npm and the VS Code Marketplace.

• Default — soft deprecation. Marked deprecated, hidden from search, existing installs keep working, new installs allowed but warned. This is what 95% of “depublish” requests should mean.
• Hard delete — exceptional. Reserved for legal or abuse cases, mediated by platform support. Existing installs don’t break — the schema or manifest is already copied into the user’s space. Only the registry’s hosted copy goes away.

Schema portability protects everyone. Because installing copies the artefact into the user’s space, even a depublish doesn’t break their data. Future updates are lost; not items.

​

Schema sanity-check on publish

The registry validates that the published artefact is well-formed before accepting it.

• Schemas — schema is well-formed, doesn’t conflict with reserved fields, isn’t absurdly large.
• Integrations — manifest is well-formed (Zod schema validation), declared permissions are valid, runtime requirements are recognized, scope grammar is valid, type identifiers are well-formed.

Cheap to implement; prevents broken installs.

​

Out of scope

• Themes and styling. Marfa is the data layer; theming lives in the apps that consume Marfa.
• View extensions. UI surfaces in the console that render existing items differently are an apps-own-their-UI concern.
• Paid items. Some apps listed in the marketplace may be commercial externally (App Store apps with their own pricing) but the platform itself does not run a billing layer for marketplace items.
• Federation. Third-party hosted services running their own marketplaces and federating with the platform’s are out of scope.