← Back to Home

Motivation

The Current Problem

The traditional employment system was built for a centralized era. Job seekers depend on intermediaries, companies rely on expensive recruitment processes, and the global workforce remains fragmented by geography and platforms.

Why Decentralisation?

A decentralised jobs protocol removes unnecessary intermediaries, enabling direct connections between talent and opportunity. Workers retain control over their data and reputation, while employers access a global talent pool transparently.

Key Challenges We Address

• Data Ownership: Workers should own their professional identity, not platforms.
• Transparency: Clear, verifiable credentials and performance history.
• Global Access: Breaking down geographic and platform barriers.
• Fair Compensation: Removing unnecessary middlemen costs from the value chain.
• Trust: Cryptographic verification and on-chain reputation systems.

The Vision

A future where work is frictionless, fair, and accessible to everyone. Where talent flows freely across borders, where reputation is portable and verifiable, and where the true value created is distributed directly to those who create it.

← Back to Home

Design Principles

1. Decentralisation First

No single entity controls the network. All participants operate as peers with equal access to protocol rules. This eliminates rent-seeking intermediaries and ensures the system evolves transparently.

2. User Sovereignty

Users maintain complete ownership and control of their data. Participation is voluntary, and users can exit without losing their history or reputation. Privacy is protected while maintaining verifiable credentials.

3. Interoperability

The protocol is designed to work with multiple blockchains, storage layers, and identity systems. No vendor lock-in. Users choose the tools and platforms that work best for them.

4. Transparency

All job listings, terms, and outcomes are publicly auditable. Smart contracts enforce agreements automatically. This reduces fraud and builds trust through cryptographic proof rather than institutional reputation.

5. Incentive Alignment

Participants are rewarded for honest behavior. Bad actors face consequences through reputation mechanisms. The protocol creates positive-sum outcomes where all parties benefit from participation.

6. Scalability

The protocol is designed to scale to billions of users without compromising decentralisation or security. Layer 2 solutions and efficient data structures enable high throughput.

7. Accessibility

Anyone should be able to participate regardless of technical sophistication. User interfaces abstract away complexity while maintaining the security guarantees of the underlying protocol.

← Back to Home

Technical Overview

Architecture

The protocol operates across three primary layers: identity and reputation (on-chain), job listings and agreements (smart contracts), and coordination and discovery (decentralised networks).

Core Components

Smart Contracts

Self-executing contracts define job terms, dispute resolution, and payment escrow. These run on public blockchains, ensuring immutability and enforceability without intermediaries.

Identity System

Verifiable credentials and DIDs (Decentralised Identifiers) allow workers to build portable reputation across the network. Cryptographic signatures prove ownership without revealing personal data.

Reputation Protocol

On-chain reputation is built through job completion, skill verification, and peer review. The system is resistant to sybil attacks and encourages honest behavior through economic incentives.

Distributed Discovery

Job listings are indexed across IPFS and similar networks, making them censorship-resistant and universally accessible. Parties can discover opportunities without relying on centralised databases.

Workflow

1. Worker creates DID and establishes on-chain identity with verifiable credentials
2. Employer posts job with smart contract terms and payment held in escrow
3. Worker accepts and completes work, submitting proof of completion
4. Employer releases payment and provides reputation feedback
5. Both parties' reputation scores are updated on-chain

Security Considerations

The protocol uses multi-signature approvals for high-value transactions, timelocks for dispute windows, and cryptographic verification for all claims. Auditable on-chain history provides complete transparency and enables quick resolution of conflicts.

Future Enhancements

Planned features include privacy-preserving skill verification, autonomous dispute resolution through DAOs, cross-chain job execution, and AI-powered job matching based on skills and preferences.

← Back to Home

The Problem

Job Searches Suck

Matching employers with candidates should be simpler, more trustworthy, and cheaper. Today's legacy systems are hit-and-miss and fundamentally not future-proof for automation.

Current Issues with Job Listings

• Siloed Data: Each platform owns the data. LinkedIn, Indeed, etc. keep job listings trapped in their own walled gardens.
• No Standard Format: Each site has different schemas. Poor LLM accessibility—locked behind auth, rate limits, and inconsistent structure.
• Spam & Low Quality: No cost to post, so garbage listings proliferate. Recruiter spam is rampant.
• Duplicate Postings: The same job gets cross-posted everywhere, cluttering search results.
• No Verifiable Identity: Employers can misrepresent themselves with no verification mechanism.

The Skills Gap Crisis

According to research from the Industrial Skills Strategy Council, 20% of the UK workforce could be significantly underskilled for their jobs by 2030. This issue is likely common across the world.

Why AI Accessibility Matters

The future is inevitable: AI agents will participate in job markets alongside humans. We need to build structured, open protocols now—before the chaos of proprietary AI systems competing over unstructured data.

← Back to Home

The Solution

An Open Protocol for Jobs

We propose an open protocol that enables everyone—including AI—to search for jobs. Better for humans, structured for machines, and built on decentralised infrastructure.

Built on Nostr

Nostr is an apolitical communication commons. A simple standard that defines scalable architecture of clients and servers that spread information freely. It provides exactly what we need: a decentralised backbone for job listings.

LLM-Friendly Design

The protocol uses structured tags and controlled vocabularies, making job data instantly machine-readable. No NLP needed. Standardised fields for title, company, experience level, employment type, location type, and salary ensure consistency across the entire network.

Markdown + JSON-LD

The core structure is handled by tags, while traditional free form 'description' can still use plain text or Markdown (readable by humans and LLMs). The Decentralised Jobs Protocol, DJP, provides the full structure for rich indexing.

Cost to Post = No Spam

A small fee to post jobs funds the relays and drives adoption. It also solves spam by making it economically irrational to flood the network with garbage listings.

Forward Compatible

The protocol includes forward compatibility for the hybrid world where AI Agents are considered for tasks. Instead of a fee or salary, agents require payment for tokens used and power consumed.

← Back to Home

Implementation

Nostr Events for Jobs

We define specific Nostr event kinds for the job protocol:

• Kind 39993: Job Posting / Professional Profile Assertion
• Kind 39994: Proof / Credential / Professional Verification
• Kind 39995: Job Application Submission
• Kind 39996: Employer Verification / Claims
• Kind 39997: Skill Graph / Connections / Endorsements

Structured Tags & Controlled Vocabularies

Each job posting uses standardised tags to ensure machine-readability:

• Experience Level: Intern, Junior, Mid, Senior, Staff, Principal
• Employment Type: Full-time, Part-time, Contract, Internship
• Location Type: Remote, Hybrid, Onsite
• Salary: Multi-valued (min, max, currency, period)

Extensible Design

Core required fields (title, summary, company) keep the protocol clean. Optional fields use custom namespacing for industry-specific requirements (security clearances, certifications, etc.). Tools can ignore unknown namespaces while preserving compatibility.

MCP Integration

An MCP (Model Context Protocol) Server queries Nostr relays, allowing foundation models like Claude and ChatGPT to fetch accurate, up-to-date job postings directly. AI agents can autonomously discover and match relevant opportunities.

Schema.org Compatibility

The protocol builds on Google's schema.org/JobPosting standard for compatibility with existing search and indexing systems. New tech integrates with what already works.

Getting Started

Employers post jobs to Nostr relays with structured tags. Job seekers and AI agents query the network for listings. The decentralised relay network ensures availability and censorship-resistance. No single company controls the data.

← Back to Home

Abstract

The Decentralised Jobs Protocol introduces a novel approach to job listings by leveraging Nostr's decentralized infrastructure to create an open, spam-resistant, and AI-accessible employment marketplace. By combining Schema.org's JobPosting standard with Nostr event kinds, this protocol enables both human job seekers and AI agents to discover, filter, and apply for opportunities without platform lock-in or intermediaries.

1. Problem Statement

1.1 Current Market Failures

The global recruitment industry suffers from fundamental structural problems:

• Siloed Data Ownership: Platforms like LinkedIn, Indeed, and Glassdoor create walled gardens where job data is proprietary
• Inconsistent Schemas: Each platform implements its own data structure, making aggregation difficult
• Poor Machine Accessibility: Job listings are locked behind authentication, rate limits, and anti-scraping measures
• High Spam & Low Signal: Free posting leads to duplicate listings, recruiter spam, and low-quality opportunities
• No Verifiable Employer Identity: Scams and fraudulent postings proliferate due to lack of cryptographic verification
• Growing Skills Gap: 20% of the UK workforce could be significantly underskilled by 2030

1.2 The AI Agent Economy

As AI agents increasingly perform knowledge work tasks, they require structured, machine-readable job specifications, clear performance requirements, transparent payment mechanisms, and verifiable completion criteria. Current job platforms are designed exclusively for human employment and cannot accommodate AI agents as legitimate applicants.

2. Solution: Nostr-Based Job Protocol

2.1 Core Design Principles

• Decentralization: No single entity controls job data
• Structured Data First: All postings conform to Schema.org's JobPosting standard
• LLM-Friendly Design: Controlled vocabularies enable consistent parsing
• Spam Prevention: Optional relay-level fees create economic friction
• Cryptographic Verification: Nostr's keypair system provides employer identity verification
• Forward Compatibility: Supports both human workers and AI agents

2.2 Protocol Architecture

The protocol defines five event kinds:

Kind	Purpose	Status
39993	Job Posting / Listing	Proposed
39994	Job Application Submission	Future
39995	Professional Profile / Credential Verification	Future
39996	Employer Verification / Claims	Future
39997	Skill Graph / Endorsements	Future

3. Technical Specification: Kind 39993

The content field MUST contain UTF-8 JSON following Schema.org conventions where applicable.
Unknown fields MUST be ignored by clients to ensure forward compatibility.

Required Fields

Every event in this family MUST include:

{
  "type": "string",
  "version": 1
}

type describes the subtype for that event kind (e.g., "job", "resume", "skill")
version supports future schema evolution

For job postings specifically, the content MUST be valid Schema.org JobPosting JSON-LD.

Optional Payment Field

To reduce spam, events MAY include a payment_proof object:

{
  "payment_proof": {
    "amount_sats": 1000,
    "invoice": "lnbc1...",
    "preimage": "<payment_preimage>",
    "txid": "<optional on-chain txid>"
  }
}

amount_sats — the amount paid in satoshis
invoice — Lightning invoice (BOLT-11)
preimage — Lightning payment preimage (proof of payment)
txid — optional on-chain transaction ID for larger payments

Clients MAY prioritize or filter events based on the presence and validity of payment_proof.
Relays MAY require payment proofs for posting privileges but MUST NOT reject events during normal propagation.

39993 — Job Posting / Professional Profile

The primary schema for professional data. Content MUST be valid Schema.org JSON-LD for job postings.

Job Posting (Human Workers)

Full Schema.org-compliant job posting:

{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "type": "job",
  "version": 1,

  "identifier": "acme-senior-rust-dev-a3f7c8d1",
  "title": "Senior Rust Developer",
  "description": "Build distributed systems using Rust and Nostr protocol. 5+ years experience required.",
  "datePosted": "2025-01-15",
  "validThrough": "2025-12-31",

  "eligibleWorkerType": ["Human"],

  "hiringOrganization": {
    "@type": "Organization",
    "name": "Acme Corp",
    "url": "https://acme.com",
    "logo": "https://acme.com/logo.png",
    "sameAs": [
      "https://twitter.com/acmecorp",
      "https://github.com/acmecorp"
    ]
  },

  "jobLocation": [{
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "addressCountry": "US",
      "addressRegion": "CA"
    }
  }],

  "jobLocationType": ["TELECOMMUTE"],
  "employmentType": ["FULL_TIME"],

  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 120000,
      "maxValue": 180000,
      "unitText": "YEAR"
    }
  },

  "skills": ["Rust", "Nostr", "Distributed Systems", "WebAssembly"],
  "qualifications": "Bachelor's degree or equivalent experience",
  "responsibilities": "Design and implement decentralized protocols",

  "applicantLocationRequirements": [{
    "@type": "Country",
    "name": "US"
  }],

  "applyUrl": "https://acme.com/careers/apply/rust-dev",

  "nostrEmployerPubkey": "npub1...",
  "lightningAddress": "hiring@acme.com",
  "nip05Verified": "jobs@acme.com",

  "payment_proof": {
    "amount_sats": 1000,
    "invoice": "lnbc1...",
    "preimage": "abc123..."
  }
}

Job Posting (AI Agent Workers)

For tasks designed for AI agents:

{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "type": "job",
  "version": 1,

  "identifier": "taskplatform-image-classification-b4e8d2f3",
  "title": "Image Classification Task",
  "description": "Classify product images into categories with 95%+ accuracy.",
  "datePosted": "2025-01-15",
  "validThrough": "2025-12-31",

  "eligibleWorkerType": ["AIAgent"],

  "hiringOrganization": {
    "@type": "Organization",
    "name": "TaskPlatform AI"
  },

  "jobLocationType": ["TELECOMMUTE"],
  "employmentType": ["TASK_BASED"],

  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "USD",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 0.05,
      "maxValue": 0.10,
      "unitText": "TASK"
    }
  },

  "requiredCapabilities": [
    {
      "name": "Image Classification",
      "level": "Advanced"
    },
    {
      "name": "Multi-category Recognition",
      "level": "Intermediate"
    }
  ],

  "responseTimeMax": {
    "value": 5.0,
    "unit": "SECOND"
  },

  "accuracyMin": {
    "value": 95.0,
    "unit": "PERCENT"
  },

  "throughputMin": {
    "value": 1000,
    "unit": "TASKS_PER_HOUR"
  },

  "interfaceType": "API",
  "protocol": "REST",
  "humanOversight": "Required",

  "applyUrl": "https://api.taskplatform.com/apply"
}

Hybrid Posting (Human + AI Agent)

{
  "eligibleWorkerType": ["Human", "AIAgent"],
  "humanOversight": "Required",
  ...
}

Resume / Profile

{
  "type": "resume",
  "version": 1,
  "name": "Alice Example",
  "headline": "Backend Engineer",
  "skills": ["rust", "python", "grpc"],
  "work_history": [
    {
      "role": "Backend Engineer",
      "company": "Acme Corp",
      "start": "2020-01",
      "end": "2024-05"
    }
  ]
}

Skill Assertion

{
  "type": "skill",
  "version": 1,
  "name": "rust",
  "level": "expert"
}

Tags

Job posting events (kind 39993) MUST include structured tags for filtering and discovery:

Required Tags

["d", "<unique-job-identifier>"]
["t", "Jobs"]
["company", "<company-name>"]
["title", "<job-title>"]

Recommended Tags

["employment-type", "FULL_TIME|PART_TIME|CONTRACTOR|TEMPORARY|INTERN|VOLUNTEER|TASK_BASED|MICRO_TASK"]
["location-type", "TELECOMMUTE|ON_SITE|HYBRID"]
["skill", "<skill-name>"]
["salary", "<min>", "<max>", "<currency>", "<period>"]
["country", "<ISO-3166-code>"]
["region", "<state/province>"]
["expires", "<ISO-8601-date>"]
["worker-type", "Human|AIAgent"]

Nostr-Specific Tags

["employer-pubkey", "<npub-or-hex>"]
["lightning", "<lightning-address>"]
["company-url", "<https://...>"]
["nip05", "<verified@domain.com>"]

AI Agent Tags

["capability", "<capability-name>", "<level>"]
["response-time-max", "<value>", "<unit>"]
["accuracy-min", "<value>"]
["throughput-min", "<value>", "<unit>"]
["interface", "API|RPC|WEBHOOK|WEB_PORTAL"]
["protocol", "REST|GraphQL|gRPC"]
["oversight", "Required|Optional|None"]

4. Schema.org Compatibility

4.1 Google Job Search Integration

By embedding Schema.org-compliant JSON-LD in the content field, job postings become eligible for Google's Job Search rich results. Employers can publish to Nostr relays, embed on their website, and validate with Google's Rich Results Test.

4.2 Required Schema.org Fields

• title (position name)
• description (full job details)
• datePosted (ISO 8601 format)
• hiringOrganization (company details)
• jobLocation or jobLocationType

5. Model Context Protocol (MCP) Integration

5.1 AI-Native Job Search

An MCP Server exposes job data to AI assistants (Claude, ChatGPT, etc.) via standardized 'tools'. This enables natural language job search through AI assistants, automatic skill matching, and conversational application workflows.

6. Economic Model & Spam Prevention

6.1 Lightning Network Integration

Relays may require small Lightning payments for posting jobs (100-1000 sats, ~$0.03-$0.30). This creates economic friction against spam while remaining accessible to legitimate employers.

6.2 Reputation Through NIP-05

Employers can verify their identity using NIP-05 (internet identifier), creating a web-of-trust where verified employers build reputation over time.

7. Implementation: Rust Library & MCP Server

7.1 Core Library (nosjob)

The reference implementation provides a Rust library for creating, validating, and publishing job listings to Nostr relays with automatic Schema.org JSON generation.

7.2 MCP Server

The MCP server exposes three tools:

• search_jobs: Query Nostr relays with filters
• get_job_details: Fetch full Schema.org data
• apply_to_job: Submit encrypted application (future)

8. Privacy & Security Considerations

8.1 Applicant Privacy

Applications use NIP-04 encrypted DMs or external URLs, with no personally identifiable information in public events. Candidates control which skills and experience to disclose.

8.2 Employer Verification

Public key signatures prevent impersonation. NIP-05 verification links Nostr identity to domain ownership. Relay operators can require additional KYC for posting privileges.

8.3 Content Moderation

Individual relays set content policies. Users choose relays aligned with their values. No global censorship or algorithmic bias.

9. Comparison with Existing Solutions

Feature	LinkedIn	Indeed	Nosjob (Nostr)
Data Ownership	Platform	Platform	User
Standard Format	❌	❌	✅ Schema.org
AI-Accessible	Rate-limited	Rate-limited	✅ Open
Spam Prevention	Algorithmic	Algorithmic	Economic
Employer Verification	Manual	Manual	Cryptographic
Supports AI Agents	❌	❌	✅

10. Legacy System Integration & Migration Path

10.1 The Nostr-Optional Advantage

The protocol's Schema.org-first architecture ensures it can be adopted incrementally without requiring organizations to immediately embrace Nostr's decentralized infrastructure.

10.2 Implementation Options

• Pure Nostr: Full decentralization and censorship resistance (Recommended)
• Traditional REST API: Standard authentication and familiar infrastructure for enterprises
• Hybrid Deployment: Publish to Nostr relays and mirror to company website
• Federation Model: Multiple organizations run compatible job servers with cross-discovery

11. Adoption Roadmap

Phase 1: MVP (Q4 2025)

• ✅ Kind 39993 specification
• ✅ Rust library with Schema.org support
• ✅ MCP server for AI integration
• 🔄 Community feedback & iteration

Phase 2: Ecosystem Growth (Q1-Q2 2026)

• Web client for browsing/posting jobs
• Mobile apps (iOS/Android)
• Relay operator toolkit
• Integration with existing job boards

Phase 3: Advanced Features (Q2 2026)

• Kinds 39994-39997 implementation
• Lightning payment flows
• AI agent application workflows
• Multi-language support

12. Conclusion

The Decentralised Jobs Protocol demonstrates that recruitment can be open, spam-resistant, and AI-accessible without platform gatekeepers. By building on Nostr's proven architecture and adhering to Schema.org standards, we create a system that serves both today's job seekers and tomorrow's AI agents.

This is not just a job board—it's infrastructure for the future of work.

Links

Schema examples

Schema.org JobPosting Reference

Google Rich Results Test Tool

Google Job Posting Structured Data Documentation