Youblob: Open Knowledge Infrastructure for Industry 5.0

The backend is composed of 37+ domain-specific modules, each encapsulating its own data models, services, and API routes. Modules communicate through MedusaJS's dependency injection container and an event bus for asynchronous operations.

All on-chain operations require a CIP-30 compatible wallet (Lace, Nami, Eternl, or any conformant extension). The frontend uses the standard window.cardano API to request wallet access, build transactions client-side, and submit signed transactions to the network.

Every Gold Coin transaction is an on-chain Cardano transaction. There is no off-chain ledger, no custodial wallet, and no IOUs. When a maker spends YGOLD, they sign a transaction with their private key, and settlement is final in approximately 20 seconds.

Chain queries (UTXO lookups, transaction submission, metadata retrieval) are handled through Blockfrost, a managed Cardano API service. The backend never runs a full Cardano node. This trades some decentralization for operational simplicity — the platform can verify any transaction independently by querying the public ledger through any alternative indexer.

Blueprints can be minted as NFTs using the CIP-25 metadata standard. The minting process stores:

• Blueprint metadata (title, author, creation date) in the transaction metadata
• Thumbnail image on IPFS via Blockfrost (paid tier, 1 GB allocation)
• Full blueprint data on Arweave for permanent, immutable storage
• Creator attribution as an on-chain record tied to the minting address

Once minted, the NFT is the canonical proof of authorship. It cannot be altered, revoked, or disputed — even if youblob.com goes offline, the attribution record persists on-chain.

Corporate Guilds lock their fee parameters on-chain. When a guild registers, a datum containing the fee percentage and beneficiary address is locked at the validator script address. The validator enforces that:

• Only the guild owner can update fee parameters
• Fee changes require a new transaction (immutable per-UTXO)
• Minimum and maximum fee bounds are enforced by the script

Blueprint connections carry revenue attribution (CIP-102 pattern). Each connected blueprint receives a 10% royalty on downstream revenue, up to a maximum of 5 connections (50% total). The royalty split is recorded in the blueprint's on-chain metadata and enforced at payment time.

-- CIP-102 Revenue Attribution
-- Max 5 connections per blueprint
-- 10% allocation per connection
-- Remaining goes to primary creator

connections: [
  { blueprint_id, allocation: 10%, added_at }
]

A core architectural principle: ownership, attribution, and royalties must live on-chain. They must never depend on youblob.com being online. If the platform disappears tomorrow, every creator's attribution record, every royalty split, and every NFT remains verifiable on the Cardano ledger. This principle overrides “simpler off-chain” tradeoffs in every design decision.

The platform takes the smallest viable cut. Creator revenue is maximized by design, not as a marketing claim.

No hidden fees, no tiered pricing, no premium seller programs. The fee structure is identical for every seller on the platform.

Silver Coins are fractional credits (100 Silver = 1 Gold). They are automatically credited when a transaction results in a partial amount. Silver Coins are off-chain credits, not blockchain tokens — they provide UX convenience for micro-transactions without incurring on-chain fees for every fractional amount.

• Blueprint NFT minting (permanent on-chain attribution)
• Content promotion (1 YGOLD = 24 hours featured placement)
• Blueprint translation (1 YGOLD = all 43 languages)
• Tipping creators
• Professional service fees
• Corporate Guild registration

Every blueprint exists in two tables simultaneously: the MedusaJS product table (for commerce integration) and a dedicated blueprint table (for domain-specific queries). The product.metadata.blueprint_data JSONB field is the source of truth for the store API.

blueprint_data: {
  steps: [
    {
      step_number: 1,
      title: "Crush the malachite ore",
      description: "...",
      content_type: "text" | "design",
      materials: [{ product_id, name }],
      tools: [{ product_id, name }]
    }
  ],
  materials_list: [{ product_id, product_name, quantity, unit }],
  tools_required: [{ product_id, product_name, quantity, unit }],
  connections: [{ blueprint_id, allocation_percentage: 10 }],
  knowledge_connections: [{ blueprint_id }]
}

Each blueprint references concrete products for every material and tool. The BOM is stored in three places:

1. Top-level materials_list and tools_required arrays (drives frontend rendering)
2. Per-step materials and tools arrays (drives per-step BOM display)
3. blueprint_bom_item relational table (drives analytics and cross-referencing)

Blueprints can be connected through two tiers:

Connections must represent genuine process relationships — a shared ore, a direct byproduct, a prerequisite technique. “Same author” or “same category” is never sufficient. Zero connections is always better than wrong connections.

One step = one action = one verb. Blueprints target 15–30 atomic steps, not 5 dense paragraphs. Each step is independently translatable, independently referenceable by LPM, and can carry its own materials/tools/images. This granularity is what makes blueprints machine-composable.

MOS is the material intelligence layer. It defines a structured ontology for every physical material, tool, and component on the platform — classifying them by material type, typical uses, associated blueprints, category taxonomy, and usage patterns. MOS enables:

• Automated product categorization and recommendation
• Cross-blueprint material matching (find all blueprints that use copper wire)
• Supply chain insights (which materials are most used, least available)
• Material substitution suggestions based on BOM analysis

LPM is a knowledge compounding system trained on blueprint steps, material connections, skill progressions, and maker outcomes. It builds a model of how prototyping processes relate, which techniques produce the best results, and where knowledge gaps exist. The long-term goal:

• AI-generated blueprints based on accumulated maker knowledge
• Skill path recommendations (what to learn next based on your current skills)
• Process optimization (suggest improvements to existing blueprints)
• Cross-domain innovation (identify techniques in one craft applicable to another)

LPM is why blueprint accuracy is sacred. Every blueprint is training data. If the foundation contains errors, all compounded knowledge built on top is poisoned. This is not a quality preference — it is an architectural constraint.

All data is archived, never deleted. Every product, blueprint, comment, transaction, and skill progression is soft-deleted (deleted_at timestamp) rather than removed. This preserves the complete history for MOS and LPM training.

Spider Guard is a Redis-backed rate limiting system that operates at the IP level. It tracks request frequency, identifies anomalous patterns (scraping, credential stuffing, API abuse), and blocks offending IPs temporarily or permanently.

• Org-friendly thresholds: organizations and makerspaces get higher rate limits to prevent false positives on clusters of users behind a single IP
• Loopback exemption: SSR requests from the frontend (IPv4/IPv6 loopback) are never rate-limited
• Graduated response: warning → temporary block → permanent block

Notifications use a milestone-based system that reduces spam by 99.87%. Instead of notifying on every like, fork, or comment, the system batches events and triggers notifications at meaningful thresholds (10 likes, 50 likes, 100 likes). This prevents notification fatigue while ensuring important milestones are surfaced.

Rather than permanently banning disruptive users, the platform implements a redemption system. Flagged accounts enter a cooling-off period with reduced privileges. Constructive behavior during this period gradually restores full access. This preserves the “archive everything” principle while protecting community health.

Every creator has a uniqueness rating that reflects their contribution originality. A 9-tier ladder (Drifter through Ninja, range 1000–3500) tracks blueprints published, skill diversity, and content distinctiveness. A 70% similarity threshold flags potential duplicates before publication.

Blueprints involving physical safety hazards (molten metals, toxic fumes, strong acids, explosives) are flagged with an is_hazardous flag. This drives a red “Hazardous” badge on blueprint cards and enables content gating for school accounts. Safety framing leads with physical hazards — Youblob is a maker platform where the primary risk is silica dust and welding fumes, not content moderation in the social-media sense.

// Core MedusaJS modules
const customerService = req.scope.resolve(Modules.CUSTOMER)
const productService = req.scope.resolve(Modules.PRODUCT)

// Custom modules — resolved by module key
const marketplace = req.scope.resolve("marketplace")
const tokenomics = req.scope.resolve("tokenomics")

// Cross-module queries (preferred for reading)
const query = req.scope.resolve("query")
const { data } = await query.graph({
  entity: "product",
  fields: ["id", "handle", "title", "metadata.*"],
  filters: { id: productIds },
})

State changes emit events that downstream modules can subscribe to. This decouples modules: the blueprint module doesn't need to know about the notification module, the skill module, or the analytics module. It emits blueprint.published and interested subscribers react independently.

// Emitting
await eventBus.emit("blueprint.published", {
  id, creator_id, status: "published"
})

// Subscribing
class SkillSubscriber {
  static subscribeTo = ["blueprint.published"]
  async handle({ id, creator_id }) {
    // Award skill points, update uniqueness rating
  }
}

• /store/* — Public and authenticated user routes
• /admin/* — Admin-only routes (admin dashboard, reports)
• Singular paths (/store/vendor/) = current user's own resource
• Plural paths (/store/vendors/[handle]/) = public by-handle access
• [id] for user actions, [handle] for public display pages

PostgreSQL's JSONB type is used extensively for semi-structured data: blueprint steps, BOM entries, MOS metadata, promotion placement criteria, and targeting rules. This allows the schema to evolve without migrations for metadata-level changes while keeping relational integrity for core entities.

Entities that participate in both the commerce layer (products, pricing, sales channels) and the domain layer (blueprints, skills, certifications) exist in both MedusaJS core tables and custom domain tables. The product table is the commerce identity; the blueprint table is the domain identity. Both share the same primary key and must stay in sync.

The skill_activity_log table records every skill-relevant event: blueprint published, certification earned, contest won, workshop attended. Points are awarded per category (specialty + maker) and accumulate into the user's skill profile. The skill system is designed to mirror real-world maker progression — you level up by doing, not by gaming metrics.

Promoted content (featured blueprints, sponsored listings) is tracked in a dedicated content_promotion_transaction table with full payment provenance: payment method, exchange rate at time of purchase, NOK equivalent for Norwegian tax compliance, and impression/click analytics. All promotion revenue feeds into the platform's tax reporting system.

Navigation, buttons, sidebar labels, category names, and all platform UI text is translated into all 43 locales through static JSON dictionary files. Each locale has a complete dictionary covering every UI string. Arabic is the only RTL locale, though layout is kept LTR per user preference.

Blueprint content (steps, descriptions, materials) can be professionally translated into 42 target languages using an English pivot approach:

1. Source language → English (canonical pivot)
2. English → 41 other target locales

Translation costs 1 YGOLD per blueprint for all 43 languages at once — not per language. The English pivot ensures consistency across all locales: every reader sees the same meaning, phrasing, and tone.

A planned layer will provide Facebook-style inline translation for all user-generated content (blueprints, products, comments, reviews). Makers write in their native language (source of truth), and viewers see auto-translated content in their locale. Domain-specific maker terminology (filament, kerf, chamfer) requires LPM training to translate accurately — generic translation models produce nonsense for specialized vocabulary.

All core features are built. The current phase focuses on integration testing, data integrity verification, and ensuring every subsystem works correctly before inviting the public. The priority is absolute: everything must work 100% before LPM goes live. LPM on a broken platform equals garbage in, garbage out.

• Complete blueprint publishing pipeline (all agent cohorts active)
• AI content translation layer for user-generated content
• Full MOS metadata coverage across all products
• LPM v1 deployment (knowledge graph from blueprint connections)
• Maker skill tree integration (self-assessment + platform tracking)

• AI-generated blueprints from LPM accumulated knowledge
• Cross-domain innovation detection (LPM identifying technique transfers)
• Expanded smart contract suite on Cardano
• Decentralized storage migration (IPFS/Arweave for all blueprint data)

Industry 5.0 → 6.0 within 5 years → 7.0 even faster. As LPM compounds knowledge and AI agents become more capable, the rate of innovation accelerates. The flywheel: more products + more MOS metadata + more blueprints → LPM learns → AI creates better blueprints → knowledge compounds forever.