DEV Community: Melvin Carvalho

The Web's Missing Piece: How DID-Nostr Quietly Solves Social Portability

Melvin Carvalho — Thu, 28 Aug 2025 09:13:13 +0000

After decades of platform lock-in, the first truly portable social graph standard has arrived. It's simpler than you might expect—and more important than it first appears.

The Facebook Lesson We Forgot

Facebook's original genius wasn't the blue interface or the poke button. It was recognizing that social graphs are infrastructure—and the most valuable applications are built on top of that infrastructure.

Facebook started with university email directories and social networks that already existed. They digitized and centralized those relationships, then created an ecosystem where third-party developers could build on that social foundation. The result was extraordinary: social games that generated billions in revenue, payment systems that worked because they understood relationships, targeted advertising that leveraged social context, and recommendation engines that knew who you trusted.

The entire social web economy emerged from applications built on Facebook's social graph API.

But then Facebook closed the ecosystem. The API became restricted, then neutered, then largely eliminated. The social graph that had enabled so much innovation became a proprietary asset, locked away behind corporate walls.

For the first time since Facebook's early days, we have something similar: an open social graph that scales with adoption. Except this time, no one can close it.

The Problem We've Normalized

Your Twitter followers can't follow you to LinkedIn. Your Instagram connections don't transfer to TikTok. Your professional network on one platform stays trapped there forever.

This isn't a technical limitation—it's a business model. Social platforms create value by making it costly to leave. Your social graph becomes a kind of digital mortgage, binding you to platforms long after they've stopped serving your interests.

We've accepted this as inevitable. But what if the fundamental assumption is wrong?

What Is DID-Nostr?

DID-Nostr is a W3C specification that bridges two technologies: Decentralized Identifiers (DIDs) and the Nostr protocol. At its core, it does something deceptively simple: it makes your social connections part of your identity, not part of any platform.

Here's what a DID-Nostr identity looks like:

Identity: did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2

Profile: https://alice.com/.well-known/did/nostr/124c0fa9...

Social Graph: Built into the identity document itself

Your social connections become as portable as your email address.

Beyond Native Nostr: Why Standards Matter

Nostr users might wonder: "We already have portable identities and social graphs. What does DID-Nostr add?"

The answer lies in scale and interoperability beyond relay networks. While Nostr creates portable social relationships within its ecosystem, DID-Nostr transforms those relationships into web infrastructure that scales horizontally across every technology stack.

Beyond Relay Dependencies: DID documents can be served from traditional web servers, CDNs, IPFS, or any HTTP endpoint. Your social graph doesn't depend on relay uptime or relay discovery. It works with the same caching, load balancing, and global distribution infrastructure that serves the modern web.

Infinite Scale Through Web Infrastructure: Instead of querying multiple relays and aggregating responses, applications make single HTTP requests to cached endpoints. This transforms social graph discovery from an expensive, real-time operation into a fast, cacheable web request. The same infrastructure that serves billions of web pages can now serve billions of social relationships.

Universal Interoperability: Any application can use your social graph without running Nostr clients or managing WebSocket connections. Traditional web apps can offer social features through standard HTTP APIs. Your social graph works with anything that speaks HTTP—which is everything.

The Ecosystem That Becomes Possible

Remember what developers built on Facebook's social graph before it was locked down:

Social Games: FarmVille, Mafia Wars, and thousands of others that generated billions by leveraging friend networks for gameplay, competition, and viral growth.

Social Commerce: Applications that used trust relationships to enable peer-to-peer transactions, group buying, and social proof for purchases.

Content Discovery: Recommendation engines that surfaced content based on what your friends shared, liked, and engaged with.

Social Login: Universal authentication that worked across thousands of websites by leveraging Facebook's identity platform.

Targeted Services: Applications that could offer personalized experiences by understanding your social context and relationship patterns.

Group Coordination: Tools for organizing events, managing communities, and facilitating group decisions based on real social relationships.

Now imagine all of that—but decentralized, open, and resistent to shut down.

Decentralized Social Games: Games that use your portable social graph for multiplayer experiences, leaderboards, and viral mechanics—without depending on any single platform or risking account suspension.

Peer-to-Peer Payments: Payment systems that leverage cryptographically-verified social relationships for trust, reputation, and fraud prevention—without corporate intermediaries.

Open Social Commerce: Marketplaces and commerce applications that can bootstrap with existing social proof and trust relationships from day one.

Universal Social Login: Authentication that works across all applications and platforms, controlled by users rather than corporations.

Decentralized Content Networks: Recommendation systems that operate across multiple platforms, using your social graph to surface relevant content wherever you are.

Autonomous Social Coordination: DAOs and governance systems that can verify real social relationships and prevent Sybil attacks using portable social proof.

The Technical Innovation

DID-Nostr introduces something genuinely new: social relationships as first-class identity data. When you follow someone, that relationship becomes part of your cryptographically-signed identity document, discoverable through standard web protocols.

The specification defines three resolution methods:

HTTP Resolution: Standard web requests to .well-known endpoints
Offline Resolution: Full identity reconstruction from just a public key
Enhanced Resolution: Rich social data from distributed networks

This isn't just another API—it's infrastructure. Any application, anywhere, can resolve social relationships using the same standard protocols that serve web pages.

The key insight: by making social graphs web-native rather than protocol-native, they can leverage decades of web scaling innovation while maintaining complete decentralization.

The Local-First Revolution

DID-Nostr aligns perfectly with the emerging local-first software movement. Your identity document can be generated entirely offline. Your social relationships can be verified cryptographically without server dependencies. Your applications can work fully disconnected, syncing only when connectivity is available and desired.

This enables entirely new categories of social applications:

Offline Social Games: Multiplayer experiences that work without internet connectivity, using cryptographically-verified friend lists for local network play.

Private Social Commerce: Peer-to-peer marketplaces that can verify trust relationships without revealing your social graph to servers.

Resilient Social Infrastructure: Applications that continue working during network outages, internet censorship, or platform shutdowns.

Local Social Computation: Social algorithms and recommendations that run entirely on-device, using cryptographically-verified relationship data.

Why Portable Social Graphs Matter

Consider the network effects. Today's social platforms grow by capturing and isolating social graphs. Tomorrow's applications could grow by making social graphs more valuable as they become more widely accessible.

For users: Your social connections follow you across applications. Build your network once, use it everywhere—not just in Nostr clients, but in games, commerce apps, content platforms, and technologies that don't exist yet.

For developers: No need to build user acquisition from scratch or integrate with specific platforms. Applications can bootstrap with existing social relationships using familiar HTTP APIs that work with any backend technology.

For the ecosystem: Social data becomes public infrastructure rather than proprietary assets—enabling the same kind of innovation explosion that Facebook's early API created, but without the risk of platform capture.

Real Applications

The implications become clear when you consider what developers can build:

Social Gaming Platforms: Games that can access your friend network from day one, creating instant multiplayer experiences and viral growth loops without platform dependencies.

Decentralized Social Commerce: Marketplaces that use your social proof and trust relationships to enable peer-to-peer transactions with built-in reputation systems.

Cross-Platform Content Networks: Applications that can recommend content, facilitate discussions, and build communities using your existing social context.

Social Coordination Tools: Governance platforms, event organizing tools, and decision-making applications that leverage real social relationships for better outcomes.

Universal Social Authentication: Login systems that work across all applications while giving users complete control over their identity and relationships.

Social Financial Services: Lending platforms, group payment systems, and financial coordination tools that use social trust rather than traditional credit scores.

The Broader Context

This fits into a larger pattern of infrastructure becoming more portable. Email separated messaging from providers. RSS separated content from platforms. OAuth separated authentication from applications.

DID-Nostr separates social graphs from platforms—and makes them accessible to any web technology, enabling the same kind of ecosystem innovation that Facebook's early API created.

But it goes further. By making social graphs web-native and cryptographically verifiable, it enables applications that Facebook never could: truly peer-to-peer social experiences that work offline and can't be shut down.

Current Limitations

The specification is early-stage infrastructure. Real adoption requires solving practical challenges:

Developer adoption: Can the ecosystem attract the builders needed to create compelling applications?
User experience: Making cryptographic identity as simple as existing social login
Privacy controls: Balancing openness with selective sharing across different platforms
Storage infrastructure: Reliable hosting for identity documents at web scale

These aren't fundamental barriers, but they require continued development and real-world testing across different technical environments.

What Changes

The most significant impact may be the most subtle: application developers can now assume that social relationship data exists independently of any particular platform, and they can build on that foundation without fear of the API being shut down.

This assumption changes what becomes worth building. When social graphs are permanent public infrastructure rather than temporary proprietary assets, different kinds of applications become viable. When that infrastructure works offline-first and scales like the web, entirely new categories of social software become possible.

We're not just talking about better social networks. We're talking about social data as public infrastructure—like DNS or email protocols—that enables an entire ecosystem of applications and services.

Looking Forward

Social portability sounds like a small technical improvement. In practice, it might enable the same kind of innovation explosion that Facebook's social graph API created in the late 2000s—except this time, no one can turn off the API.

When email became portable across providers, it enabled decades of innovation in messaging and communication. When domains became portable across hosting providers, it enabled the modern web. When Facebook opened their social graph API, it enabled social games, social commerce, and the modern social web economy.

Portable, web-native, cryptographically-verified social graphs could enable something even bigger: a truly open social economy that no single entity controls.

The tools exist now. The question is what we'll build with them.

DID-Nostr v0.0.7 is available at nostrcg.github.io/did-nostr. The specification is developed by the W3C Nostr Community Group, an open standards organization.

Blocktrails: Smart-Contract Functionality - On Bitcoin, No Extra Token Needed

Melvin Carvalho — Tue, 24 Jun 2025 14:51:00 +0000

Picture a relay-race baton hurtling around a track.
Before each hand-off the runner stamps the baton with today’s secret code, then sprints ahead.
Every swap is signed, time-stamped, and etched into Bitcoin forever—so anyone can replay the entire race and verify there was never a duplicate baton.

That baton is a Blocktrail. It gives you contract-grade state changes, provable settlement, and full auditability—powered solely by Bitcoin, no new chain or side token in sight.

🏷️ What’s a Blocktrail?

A Blocktrail is a tiny, self-contained ledger riding inside Bitcoin’s main ledger.

state₀ —sha256→ tweak₀   (GENESIS UTXO)
          spend → state₁ —sha256→ tweak₁   (UTXO₁)
          spend → state₂ —sha256→ tweak₂   (UTXO₂)
          ...

One live output at a time—Bitcoin’s double-spend rule enforces the sequence.
SHA-256 of your app’s state (a Git commit, JSON blob, DAG root—anything hashable) becomes the Taproot tweak for the next output.
Whole history on-chain: fetch the tweaks, re-hash the snapshots, and you can replay every step without trusting anyone.

Result: all the “why” and “when” of a smart contract, with nothing but ordinary transactions.

🧩 Think “Git Commits on Bitcoin”

Genesis: create state₀, hash it, anchor it as the GENESIS transaction.
Next commit: update your data → state₁, hash again, tweak again, spend GENESIS.
Repeat: the latest UTXO is your repo HEAD; the chain of tweaks is the commit log.
No forks: Bitcoin consensus permits only one spend of the live UTXO—linear history guaranteed.

🔧 Blocktrail in (Pseudo) JavaScript

Functions like createGenesisUTXO, spendUTXO, and auditChain are illustrative.
A real blocktrails-js library is the very next milestone.

// keypair controls the trail (can double as Nostr pubkey)
const trailKey = generateKeypair();     // { priv, pub }

// helper: hash any client-side state object
const hashState = state => sha256(JSON.stringify(state));

// 1. GENESIS
let state   = { owner: "alice", balance: 0 };
let genesis = createGenesisUTXO({
  pubkey: trailKey.pub,
  value:  546n,                 // sats
  tweak:  hashState(state)      // hash of state₀
});
console.log("GENESIS:", genesis.outpoint);

// 2. first update → UTXO₁
state.balance += 100;
let utxo1 = spendUTXO({
  prev:    genesis,
  privkey: trailKey.priv,
  value:   520n,                // minus fee
  tweak:   hashState(state)     // hash of state₁
});
console.log("UTXO₁:", utxo1.outpoint);

// 3. another update → UTXO₂
state.owner = "bob";
let utxo2 = spendUTXO({
  prev:    utxo1,
  privkey: trailKey.priv,
  value:   500n,
  tweak:   hashState(state)     // hash of state₂
});
console.log("UTXO₂:", utxo2.outpoint);

// 4. audit anytime
const history = auditChain({ tip: utxo2.outpoint });
history.forEach(step => console.log(step.outpoint));

🏗️ Why You Might Care

Need	Blocktrail Delivers
Smart-contract enforcement	Only one valid next state—no VM required.
Double-spend safety	Bitcoin consensus blocks competing branches.
Tamper-proof history	Each state hash is burned into the chain.
Full replay	Rebuild state locally, match hashes, verify every step.
Zero extra infra	Just Bitcoin transactions. No gas, no databases.

🧪 What Can You Build?

🔄 Supply-chain docs — every warehouse hashes its manifest, tweaks, spends, passes on.
✅ One-person-one-vote — ballot UTXO’s tweak is sha256(choice), binding voter intent to a single spend.
🎮 Game quests — quest token’s tweak is sha256(save-game), so progress is provably unique.
📈 Prediction markets — each market state (order book, odds, settlement) hashes into the next tweak; payouts are locked to the final on-chain hash.
🧾 Regulator-grade receipts — hash your PDF invoice, tweak, create an immutable audit link.
💬 Social attestations via Nostr — hash a Nostr event (or thread root), tweak it into the next Blocktrail output, and anchor every reply or edit to Bitcoin—giving posts, likes, or channel memberships an immutable, on-chain audit path while the conversation itself stays lightweight and off-chain.

🔭 Next Up: `blocktrails-js`

We’re drafting an open-source JavaScript SDK that will:

Wrap Bitcoin Core or external signers (Ledger, Trezor, WebLN).
Provide simple helpers: createGenesisUTXO, spendUTXO, auditChain.
Ship with wallet components that surface “current tip” and commit hashes at a glance.
Offer explorer overlays that draw Blocktrails as subway lines on mempool graphs.

The library is the next mile on this trail—stay tuned.

TL;DR

Blocktrails link Bitcoin outputs with Taproot tweaks that are SHA-256 hashes of your app’s state.
Start with a GENESIS output, hash-tweak each new state, spend once, and keep moving.
You get smart-contract guarantees—deterministic execution, audit, provable settlement—with nothing but lean, ordinary Bitcoin transactions.

🕶️ Introducing Shade: Taproot-Based Messaging in the Post-Surveillance Web

Melvin Carvalho — Wed, 28 May 2025 14:10:56 +0000

“Freedom of speech requires freedom of whisper.”

We live in an era of networked everything — and surveillance of everything. Even the most "encrypted" messengers leak metadata, rely on centralized servers, or fall back on federated infrastructures with brittle assumptions.

It's time for something simpler, leaner, and more aligned with Bitcoin’s core ethos: Shade, a secure messaging client built on Taproot, NosDAV, and strong cryptography.

🌱 Why Shade?

Shade is a new kind of secure messaging tool:

No central servers
No global inboxes
No dependence on “NIPs” or federated relays
Just you, your Taproot key, and encrypted blobs shared via NosDAV.

Whether you're a developer, a privacy advocate, or someone who just wants to chat without compromise — Shade is for you.

🧩 How It Works

Shade uses Taproot public keys as identity anchors. Each user owns a Bitcoin-native keypair — the same ones used for signing transactions can be used for messaging.

🔐 Identity and Encryption

Your Taproot key = your identity
Messages encrypted with Double Ratchet (like Signal)
Files and messages stored encrypted with AEAD (XChaCha20-Poly1305)

☁️ Storage: NosDAV

NosDAV is a lightweight, Nostr-authenticated file storage protocol. Shade uses it to:

Store encrypted message blobs
Retrieve messages privately
Avoid centralized relays or server-side logic

Messages are stored like:

PUT /<receiver-pubkey>/shade/<obfuscated-hash>.msg

All messages are encrypted and path-obfuscated via HMAC.

🔎 Metadata Resistance

One of the biggest privacy failures in modern messengers isn’t encryption — it’s metadata:

Who are you talking to?
When?
How often?
From what IP?

Shade counters that:

Leak	Mitigation
Message content	Encrypted end-to-end
Sender/receiver	Public keys only, no usernames
Timestamps	Padded, delayed, optionally batched
Subject lines	Not used — messages are opaque blobs
Transport logs	NosDAV can be self-hosted or Tor-routed

You can even use a different Taproot key per contact, or per session.

⚙️ The Developer Stack

Layer	Tech
Identity	Bitcoin Taproot keypairs (X-only)
Encryption	Double Ratchet + XChaCha20
Storage	NosDAV (HTTP + Nostr Auth)
UI	Preact + HTM (Web), Electron (Desktop), Capacitor (Mobile)
CLI	Node.js prototype in progress

🧪 Sample CLI

# Send a message
shade send --to npub1... --file message.txt

# Fetch new messages
shade fetch

# Start background sync
shade daemon

🌍 Platform Goals

✅ Web (PWA)
✅ Linux, macOS, Windows
⏳ Android + iOS
✅ Fully local-first, syncs when you choose
✅ No accounts. No phone numbers. Just keys.

💡 Why Not Nostr DMs?

Nostr DMs are clever but face major drawbacks:

Metadata-heavy (global relays can see everything)
Lack of forward secrecy
No message expiration or secure deletion
Centralized relay behavior incentivizes spam filtering

Shade fixes this by:

Moving message delivery to your own encrypted storage
Using modern crypto
Putting you in full control

Threadlocks: One-Time Commitments with Bitcoin and Nostr

Melvin Carvalho — Sun, 18 May 2025 09:14:36 +0000

What if you could make a promise, cryptographically bind it to Bitcoin, and close it forever with one action — all while broadcasting its intent through Nostr?

Welcome to Threadlocks — a new pattern for time-boxed commitments that live at the intersection of Bitcoin and decentralized social protocols.

⛓️ The Problem with Open-Ended State

Distributed systems struggle with consensus over time and state. You want to make a claim — or a promise — and prove it happened. But you don’t want to bloat a blockchain. And you don’t want to trust a centralized party. You just want a one-time, cryptographically verifiable commitment, and a public record that it occurred.

💡 Introducing Threadlocks

Threadlocks are a minimal, composable mechanism for one-time commitments. Inspired by the idea of single-use seals, Threadlocks build on native Bitcoin primitives (like Taproot key tweaking) and pair beautifully with Nostr, the decentralized event-based protocol.

🧵 What’s a Threadlock?

A Threadlock is:

Time-boxed: It exists only until it’s used.
Single-use: Once closed, it can never be reopened.
Cryptographically anchored: It's tied to a Bitcoin UTXO or Taproot tweak.
Narratively threaded: Nostr events document, declare, and extend Threadlocks in social or application logic.

It’s like a fuse you can light once — but visible forever in the chain.

🔧 How Threadlocks Work (In Plain Terms)

1. Lock the Thread

You create a commitment point:

Usually a Bitcoin UTXO.
Or better yet, a tweaked Taproot pubkey derived from a base key and a secret (your claim hash, a nonce, or logic payload).

This UTXO becomes your Threadlock.

2. Declare the Thread

You post a Nostr event with a special t tag or threadlock tag:

{
  "kind": 3xxxx,
  "content": "I claim access to channel #xyz",
  "tags": [
    ["c", "txo:chain:txid:vout"]
  ]
}

This announces your intent and binds it to a specific Bitcoin output.

3. Resolve the Lock

Later, you spend that UTXO in a Bitcoin transaction, embedding the commitment proof in witness data, an OP_RETURN, or via script logic.

Once spent, that output is forever closed — your Threadlock is done.

📜 Why Not Just Use Smart Contracts?

Because:

You don’t need a VM or gas fees.
You don’t need global consensus on execution.
You don’t want to publish logic on-chain.
You just want a provable state transition: once, verifiably.

Threadlocks are the "less is more" of crypto commitments.

🌐 What Nostr Brings to the Table

Nostr gives Threadlocks:

Event sequencing (via created_at)
Threaded logic (e tags / reply chains)
Lightweight announcements
Social context for commitments

Threadlocks can be:

Referenced by future events
Forked into multiple branches
Validated by others watching for specific closure conditions

🧪 Use Cases

Threadlocks enable:

✅ One-time claims ("I minted this", "I voted")
🔐 Access control (only those with unspent Threadlocks can act)
🗳️ DAO governance (commit → vote → finalize)
🎮 Game state progression (quests, puzzles, unlocks)
🧾 Credential issuance (proof of training, rights, NFTs)

All without smart contracts. Just Bitcoin + Nostr.

🛠️ Future: Libraries, NIPs, Agents

We're working on:

A lightweight JavaScript library for managing Threadlocks
A NIP proposal for a standardized threadlock tag
Autonomous agents that monitor and act on Threadlock resolution

What Does `did-nostr` Do?

Melvin Carvalho — Wed, 02 Apr 2025 08:07:50 +0000

🧭 What Does `did-nostr` Do?

did-nostr is a DID method that brings decentralized identity to Nostr. It lets you attach useful metadata and service endpoints to your Nostr public key, turning it into a portable identity hub.

Instead of just being a key that signs events, your Nostr pubkey becomes a rich identifier that can point to relays, profiles, storage, Bitcoin wallets, and much more.

💡 Example: Basic `did-nostr` Document

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/nostr/context"
  ],
  "id": "did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2",

  "verificationMethod": [
    {
      "id": "#key1",
      "type": "SchnorrVerification2023",
      "controller": "did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2",
      "publicKeyBase16": "124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2"
    }
  ],

  "authentication": ["#key1"],
  "assertionMethod": ["#key1"],

  "service": [
    {
      "id": "#relay",
      "type": "Relay",
      "serviceEndpoint": [
        "wss://relay.nostr.example",
        "wss://nostr-pub.wellorder.net"
      ]
    },
    {
      "id": "#profile",
      "type": "Profile",
      "serviceEndpoint": "https://your.site/profile.json"
    },
    {
      "id": "#storage",
      "type": "DecentralizedStorage",
      "serviceEndpoint": "https://storage.example.com/alice/"
    },
    {
      "id": "#inbox",
      "type": "Messaging",
      "serviceEndpoint": "https://inbox.example.org/alice"
    },
    {
      "id": "#vc",
      "type": "VerifiableCredentialService",
      "serviceEndpoint": "https://vc.example.com/submit"
    },
    {
      "id": "#wallet",
      "type": "BitcoinTaprootAddress",
      "serviceEndpoint": "bc1p...yourTaprootAddress"
    }
  ]
}

🧩 What Kind of Services Can You Attach?

Here are just a few possibilities:

🔌 Relays

Let others know where you're active or reachable.

{
  "id": "#relay",
  "type": "Relay",
  "serviceEndpoint": [
    "wss://relay.nostr.example",
    "wss://nostr.damus.io"
  ]
}

🧾 Consistent Profiles

Point to a hosted profile document (e.g., NIP-05, JSON-LD, or Solid).

{
  "id": "#profile",
  "type": "Profile",
  "serviceEndpoint": "https://yoursite.example/profile.json"
}

📦 Storage

Advertise where your public data or documents live.

{
  "id": "#storage",
  "type": "DecentralizedStorage",
  "serviceEndpoint": "https://storage.example/alice/"
}

✉️ Messaging Inbox

Allow others to DM you using email-style or DIDComm-compatible protocols.

{
  "id": "#inbox",
  "type": "Messaging",
  "serviceEndpoint": "https://inbox.example.org/users/alice"
}

🪪 Verifiable Credentials

Issue or receive credentials, badges, or attestations.

{
  "id": "#vc",
  "type": "VerifiableCredentialService",
  "serviceEndpoint": "https://vc.example.com/submit"
}

🪙 Bitcoin Wallet

Include your Taproot (P2TR) address derived from your pubkey.

{
  "id": "#wallet",
  "type": "BitcoinTaprootAddress",
  "serviceEndpoint": "bc1p...yourTaprootAddress"
}

🤝 Why Use `did-nostr`?

Because your Nostr pubkey can do more than sign events. With a did:nostr document, you can:

Make your key discoverable
Declare your preferred relays
Publish profile or storage locations
Link to wallet or message inboxes
Become part of a broader decentralized identity ecosystem

All of this is portable, self-hosted, and standardized.

📬 Want to Build With It?

The did-nostr method spec is open and evolving. You can check out the latest draft here:

👉 https://nostrcg.github.io/did-nostr/

PRs welcome. Identities are yours. Let’s build the semantic web of Nostr, one DID at a time.

Sketch: Selling Digital Art with DID-Nostr, Bitcoin, and Nostr

Melvin Carvalho — Sat, 29 Mar 2025 12:32:13 +0000

Sketch: Selling Digital Art with DID-Nostr, Bitcoin, and Nostr

The fusion of digital identity, Bitcoin, and decentralized protocols is reshaping how creators sell and own their digital art. DID-Nostr, a decentralized identity method leveraging the Nostr protocol, opens new possibilities for artists to confidently authenticate, own, and sell their artwork as NFTs using Bitcoin.

What is DID-Nostr?

DID-Nostr (Decentralized Identifier using Nostr) is an open, permissionless method for establishing identities rooted in the Nostr protocol. By tying cryptographic identities directly to Nostr's decentralized network, DID-Nostr allows secure, verifiable interactions that don't depend on centralized platforms.

Empowering Artists through NFTs

Traditionally, selling digital art required intermediaries, platforms that could censor content, control visibility, or impose high fees. DID-Nostr introduces an open standard, empowering artists with autonomy:

Provenance and Authenticity: Artworks minted as NFTs on DID-Nostr carry cryptographic proof of creation, provenance, and ownership directly linked to the artist’s DID.
Ownership and Transfer: Transfers become transparent and verifiable, allowing collectors to confidently own authentic, artist-verified digital art.
Decentralized Marketplace: Artists can sell their digital art on open, censorship-resistant marketplaces built atop Nostr, using Bitcoin for secure and borderless transactions.

Technical Overview: Minting an NFT with DID-Nostr

Follow these simplified steps to create and sell an NFT:

1. Minting the NFT

Create a JSON record for your NFT:

{
  "id": "did:nostr:nft:artwork123",
  "assetUri": "blossom://yourAssetCID",
  "owner": "did:nostr:npub1artistid",
  "creator": "did:nostr:npub1artistid",
  "metadata": {
    "title": "My Unique Digital Art",
    "description": "An original artwork minted as NFT using DID-Nostr.",
    "attributes": [{"trait_type": "genre", "value": "abstract"}]
  },
  "provenance": [{
    "type": "mint",
    "timestamp": "2025-03-29T12:00:00Z",
    "by": "did:nostr:npub1artistid"
  }]
}

2. Announcing on Nostr

Broadcast an NFT Mint Event:

{
  "kind": "nft_mint",
  "content": "I've minted new art! Check it out at blossom://yourAssetCID",
  "tags": [["nft", "did:nostr:nft:artwork123"]],
  "pubkey": "npub1artistid",
  "created_at": 1740528000
}

3. Selling with Bitcoin

When a collector wants to buy your art:

Agree on the price in Bitcoin.
The collector sends Bitcoin to your address.
Transfer ownership by signing an NFT Transfer event:

{
  "kind": "nft_transfer",
  "content": "Ownership of NFT artwork123 transferred to npub1buyerid",
  "tags": [
    ["nft", "did:nostr:nft:artwork123"],
    ["from", "npub1artistid"],
    ["to", "npub1buyerid"]
  ],
  "pubkey": "npub1artistid",
  "created_at": 1740614400
}

Benefits for Artists and Collectors

Lower Fees: No intermediaries or third-party platform fees. More revenue directly to artists.
Global Accessibility: Anyone with internet and Bitcoin can participate—no gatekeepers.
Immutable History: Clear, transparent ownership history recorded permanently on Bitcoin and Nostr, providing long-term authenticity assurances.

Envisioning a Decentralized Artistic Future

DID-Nostr represents more than technological innovation—it's an invitation to rethink digital art's value chain. Artists, freed from centralized constraints, can cultivate authentic connections with global collectors, forming communities built on shared passion, trust, and verifiable authenticity.

As we explore this path, let's remember: this is just the beginning. The decentralized future, powered by DID-Nostr, Bitcoin, and Nostr, is a canvas waiting for creators to paint their visions.

Trustless Bitcoin Swaps with DID, Nostr, and HTLCs

Melvin Carvalho — Fri, 28 Mar 2025 09:24:45 +0000

🤔 The Problem

Say Alice wants to send 100,000 sats to Bob.

But:

Alice only has on-chain Bitcoin.
Bob only uses the Lightning Network.

They want to swap — but without using a centralized exchange or trusted custodian.

Can they do it trustlessly?

Yes — with:

DIDs (Decentralized Identifiers)
Nostr (a decentralized messaging protocol)
Bitcoin + Lightning
HTLCs (Hashed Time-Locked Contracts)

🔗 A Simple Use Case

Let’s walk through a real-world example that almost anyone can understand:

💡 Scenario: On-chain to Lightning Swap

Alice wants to pay 100k sats on-chain.
Bob wants to receive 100k sats on Lightning.
They don’t trust each other and want to swap trustlessly.

🧩 Enter DID + Nostr + HTLCs

✅ 1. Identity via DIDs on Nostr

Both Alice and Bob have DIDs tied to their Nostr pubkeys.
DIDs make it possible to verify identities and sign messages.
Alice posts a signed message to Nostr offering the swap.

{
  "type": "swap-offer",
  "from": "did:nostr:pubkeyalice",
  "to": "any",
  "amount": 100000,
  "direction": "onchain-to-lightning",
  "hashlock": "abcdef123456...",
  "expires_in": 3600
}

Bob sees it and replies with a signed acceptance.

📡 2. Coordinating via Nostr

The offer and acceptance are broadcast as ephemeral Nostr events.
Both parties agree on:
- The amount
- The hashlock
- Timeouts
- Where to send funds

No servers, no intermediaries — just pubkey-signed messages over a decentralized relay network.

🔐 3. The HTLC Swap

They now execute the swap using the same secret hash:

Alice (on-chain):

Sends 100k sats to a Bitcoin HTLC (can only be claimed with the secret before timeout).

Bob (Lightning):

Sends 100k sats to a Lightning HTLC (also locked with the same hash).

As soon as one party claims the funds, the preimage is revealed, and the other can claim theirs too.

✅ 4. Atomic Swap Complete

Bob claims the on-chain BTC → reveals the secret.
Alice uses the same secret to claim her Lightning BTC.
No one can cheat — it’s enforced by the HTLCs and timeouts.

✨ Why This Matters

This setup gives us:

✅ Trustless swaps

✅ No custodians or centralized services

✅ Cross-layer interoperability

✅ Identity-based coordination via Nostr DIDs

And it all works with:

Bitcoin
Lightning
DID documents
Open message relays

🔮 What’s Next?

Add wallet support for DID-authenticated swap offers over Nostr.
Explore multi-party or ring swaps.

🔗 TL;DR

DID + Nostr + HTLCs = trustless swaps across Bitcoin and Lightning, with identity and coordination baked in.

No middleman. Just keys, hashes, and the open web.

How to Fix Cursor AppImage Not Running on Ubuntu 24.04

Melvin Carvalho — Thu, 06 Mar 2025 22:21:35 +0000

How to Fix Cursor AppImage Not Running on Ubuntu 24.04 (AppArmor Solution)

If you just downloaded Cursor for Ubuntu 24.04 and it won’t start, AppArmor is likely blocking it. This guide will show you how to properly configure AppArmor to allow the AppImage to run.

Why This Happens?

Ubuntu 24.04 enforces stricter AppArmor security policies, preventing some AppImages from running correctly. The fix involves creating an AppArmor profile that lets the Cursor AppImage run unconfined (without restrictions).

Step 1: Move Cursor AppImage to a Permanent Location

By default, downloaded AppImages reside in ~/Downloads/. It’s better to move them to ~/Applications/ for consistency:

mkdir -p ~/Applications
mv ~/Downloads/Cursor-0.46.8-be4f0962469499f009005e66867c8402202ff0b7.deb.glibc2.25-x86_64.AppImage ~/Applications/cursor.AppImage
chmod +x ~/Applications/cursor.AppImage

Step 2: Create an AppArmor Profile for Cursor

Create a new AppArmor profile at /etc/apparmor.d/cursor-appimage:

sudo nano /etc/apparmor.d/cursor-appimage

Paste the following contents:

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile cursor /home/{USER}/Applications/cursor*.AppImage flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/cursor>
}

Important:

Replace {USER} with your actual username or leave it as is (Ubuntu replaces it dynamically).
The unconfined flag ensures Cursor runs without restrictions.

Step 3: Apply the AppArmor Policy

Run the following command to reload AppArmor with the new policy:

sudo apparmor_parser -r /etc/apparmor.d/cursor-appimage

Step 4: Run Cursor

Now, try launching Cursor again:

~/Applications/cursor.AppImage

It should start without AppArmor interference.

Bonus: Make Cursor Easier to Launch

To make Cursor available in your application launcher:

Create a desktop entry:

   nano ~/.local/share/applications/cursor.desktop

Add the following contents:

   [Desktop Entry]
   Name=Cursor
   Exec=/home/{USER}/Applications/cursor.AppImage
   Icon=/home/{USER}/Applications/cursor-icon.png
   Type=Application
   Categories=Development;Utility;

Refresh your application menu:

   update-desktop-database ~/.local/share/applications/

Now, you can find Cursor in your system’s application menu!

Could Nostr Subkeys Replace GPG? A Simple, Powerful Alternative for the Modern Web

Melvin Carvalho — Wed, 26 Feb 2025 13:47:55 +0000

For decades, GPG (GNU Privacy Guard) has been the go-to tool for secure messaging, signing, and encryption. But let’s be honest—GPG is a pain to use. Key management is clunky, revocation is a mess, and for the average user, it's just too complicated.

But what if we had something simpler, more flexible, and designed for the modern internet?

Nostr’s subkey model could provide a better, decentralized alternative to GPG while keeping the core benefits: strong cryptographic identity, multi-device support, and easy verification.

👉 Full subkeys specification: Nostr Subkeys Proposal

🔑 What Makes GPG a Pain?

GPG works, but it suffers from:

Complicated Key Management – Exporting, importing, and backing up keys is a hassle.
No Native Multi-Device Support – You either copy your private key (bad idea) or manually set up subkeys.
Difficult Revocation & Recovery – If your key is lost, good luck convincing your contacts to update.
Keyservers Are a Mess – Syncing keys and verifying trust requires third-party infrastructure.
Awful UX – Even power users struggle with the interface and workflow.

GPG was built for a different era. Nostr’s built-in cryptographic identity model gives us a chance to rethink how we handle signing, encryption, and trust in a way that’s simpler and more user-friendly.

🚀 How Nostr Subkeys Could Replace GPG

1. Cryptographic Identity Without the Hassle

With Nostr, your identity is just a public key (npub), and all messages/events are signed using your private key (nsec). No complex keyservers, trust chains, or manual verifications needed—signatures are in-band and self-verifying.

2. Built-In Multi-Device Support

GPG forces you to manually create subkeys if you want to use multiple devices securely. Nostr, on the other hand, can natively support subkeys, where:

Each device gets its own subkey.
The master key delegates authority to subkeys, proving they belong to the same identity.
Clients automatically verify subkeys without needing keyservers.

🔹 GPG: Export/import keys manually → hope your contacts update

🔹 Nostr: Subkeys are linked to your master key and discoverable automatically

3. Simple, Fast Revocation & Rotation

GPG key revocation is a nightmare—if a key is compromised, you have to:

Publish a revocation certificate (which most people never generate in advance).
Hope everyone actually updates their keyrings.

With Nostr subkeys, revocation is instant and automatic:

If a device is lost or compromised, just remove its subkey from your profile (kind:0).
Clients will immediately stop trusting the revoked subkey.
No need to rely on external keyservers or out-of-band revocation mechanisms.

→ Faster, simpler, and no outdated trust issues.

4. Decentralized, No Keyservers Required

GPG relies on centralized keyservers (which are often slow, unreliable, or even censored).

Nostr, by design, is relay-based—meaning:

Public keys and signatures are naturally distributed across multiple relays.
Users can self-host their own relays or use multiple public ones.
There's no single point of failure, making censorship much harder.

🔹 GPG: Trust centralized keyservers (hope they work)

🔹 Nostr: Just use relays—they handle distribution

5. Lightweight, Modern, and Web-Native

GPG was built in the 1990s for a world of email and command-line cryptography. It doesn’t fit well with modern web applications, mobile devices, or decentralized protocols.

Nostr natively works with the web:

✅ It’s API-driven

✅ Works with any app that can verify signatures

✅ Can be used for chat, document signing, and authentication

✅ Requires no complicated installs or CLI commands

→ A signing/encryption system that actually fits how people use the internet today.

🔮 What Could a Nostr-Based GPG Replacement Look Like?

Instead of gpg --sign myfile.txt, imagine:

Signing a message by posting a kind:4 event
Encrypting a file by using NIP-44 (Nostr’s built-in encryption)
Verifying someone’s signature by checking their Nostr identity and delegation

This isn’t just theoretical—all the building blocks exist today in Nostr. With a bit of tooling, we could make signing and encryption as easy as sending a Nostr note.

🔗 GPG vs. Nostr Subkeys: The Comparison

Feature	GPG (Legacy) ❌	Nostr Subkeys (Modern) ✅
Multi-Device Support	❌ Manual setup, hard to sync	✅ Automatic subkeys for each device
Revocation	❌ Painful, requires external servers	✅ Instant, just update your profile
Key Discovery	❌ Requires keyservers	✅ Relays distribute public keys naturally
Ease of Use	❌ Complex CLI, manual imports	✅ Just sign events like any Nostr note
Decentralization	❌ Trusts keyservers	✅ Fully decentralized, relay-based
Web & App Friendly	❌ Not native to modern apps	✅ Nostr works in browsers, mobile apps, and more

🌍 A Future Without GPG?

GPG isn’t going away tomorrow—it’s deeply embedded in many systems. But for people looking for a modern, decentralized alternative, Nostr’s subkey model could be simpler, stronger, and better suited for the web.

With a little development, we could make Nostr subkeys the default way to sign, encrypt, and verify identities—without any of GPG’s pain points.

GPG had its time. Maybe it’s time for something better. 🚀

What’s Next?

Interested? Let’s build it. Drop into Nostr dev discussions and let’s start shaping a true GPG alternative—one that’s decentralized, easy to use, and works everywhere.

👉 Nostr isn’t just for social media—it could be the future of cryptographic identity. 🔑

Nostr-Passport: A Step Towards Infinite Storage

Melvin Carvalho — Sat, 07 Oct 2023 15:48:40 +0000

In the evolving digital landscape, Nostr-Passport presents itself not as a spectacle but as a humble tool, quietly enabling a seamless and private user experience across various web frameworks, such as Express, Koa, Fastify, and Hapi.

NIP-07: Privacy-Centric Identification

NIP-07 offers a protocol that facilitates identification (answering the "Who am I?") with a notable degree of privacy, allowing users to interact with applications in a read-only mode without surrendering any personal data to the digital ether.

NIP-98: Transitioning to Contribution

When users decide to shift from browsing to contributing, NIP-98 steps in, providing authentication (affirming "Verify who I am") by sending a signed header to the server, ensuring the user's contributions are authenticated and accepted.

Nostr-Passport: Bridging Identification and Authentication

Nostr-Passport serves to validate the header sent via NIP-98, unobtrusively linking identification and authentication to ensure a clean, modular, and scalable user experience.

Layered Access Control: Node-ACL and Casbin

Integration with nostr-passport allows for the subtle layering of access control using Node-ACL or Casbin, creating a secure environment where access is not only regulated but also precisely defined and controlled.

Towards Socially Aware Cloud Storage

This approach quietly transforms into socially aware cloud storage, implementing diverse roles and access in a manner that is both effective and unassuming. It creates a scenario where platforms, such as Wikipedia or private journals, can exist harmoniously, each with unique access controls and shared access to secrets.

Relays and Cloud: Navigating Towards Infinite Storage

Nostr relays, proficient in enabling real-time updates and storage, when amalgamated with cloud technology, elevate their capabilities to archival levels, providing significantly enhanced storage. This pairing doesn't just alleviate pressure on the relays but also propels Nostr towards a scale that could cater to millions or even billions of users, smoothly navigating towards infinite storage.

In Closing: A Powerful Tool for a Scalable Future

Nostr-Passport quietly nudges us towards a future where digital interactions are secure, private, and scalable, without the fanfare but with a steadfast reliability that promises a future where user privacy and contribution are harmoniously balanced.

As we explore this unassuming yet potent tool, we find a future where browsing and contributing online are not only secure and private but also infinitely scalable and quietly efficient.

Smart Events (Contracts) Over Nostr: A Consensus-Based Approach

Melvin Carvalho — Sun, 07 May 2023 12:43:19 +0000

Introduction:

In this blog post, we'll explore the concept of smart events (contracts) over Nostr, a decentralized network protocol for content sharing. We'll detail the consensus mechanism that ensures secure and reliable transaction processing and provide insights into the contracting layer of the network.

Nostr Consensus Mechanism:

The Nostr protocol employs a four-phase consensus mechanism, ensuring that only valid transactions are committed to the event chain. These phases are as follows:

Proposal Phase: A validator is chosen as the proposer for the current round based on a deterministic algorithm. This algorithm considers the validator's voting power and previous round information. The proposer creates an event proposal containing transactions and broadcasts it to other validators.
Prevote Phase: Validators verify the correctness of the proposed event, checking transactions and ensuring compliance with network rules. If valid, validators broadcast a signed "prevote" message for that event. If invalid or not received within a specified time limit, validators broadcast a "nil" prevote.
Precommit Phase: After receiving prevotes from more than two-thirds of validators (by voting power), a validator enters the precommit phase. Validators check if the majority of prevotes are for the same event proposal. If so, they broadcast a signed "precommit" message for that event. If there is no majority or the event is not received within the time limit, validators broadcast a "nil" precommit.
Commit Phase: Once a validator receives precommits for the same event proposal from more than two-thirds of validators (by voting power), it enters the commit phase. The validator commits the event to its local event chain, finalizing the consensus process for that event. The validator then moves to the next round or height and begins the process again with the proposal phase.

Contracting Layer:

Digital signatures provide a partial solution, with validators guaranteeing the proper sequencing of contractual states. As long as the dishonest validators do not exceed one-third of the total, the state shall maintain its correct order.

The state machine is capable of monitoring any contract or ledger state. It is crucial to select a federation of esteemed Nostr users, ensuring they are not Sybil attackers. A DynaFed approach could be employed, allowing a supermajority to vote out malicious nodes or those with low uptime, and replacing them with nodes of higher reputation.

Initially, the system is expected to operate in a testnet mode, wherein tokens should not be regarded as possessing tangible value. This allows for thorough evaluation and refinement of the network before transitioning to a mainnet environment, ensuring the stability and security of the system.

Conclusion:

Smart events (contracts) over Nostr provide a promising approach to decentralized content sharing and transaction processing. By utilizing a consensus-based mechanism and carefully designed contracting layer, the Nostr protocol can create a secure, reliable, and efficient platform for a variety of applications.

Run a Nostr Relay on Your Phone with Termux and Fonstr

Melvin Carvalho — Sun, 07 May 2023 06:54:21 +0000

Explore a World of Possibilities: Run a Nostr Relay on Your Phone with Termux and Fonstr

Stay connected, be part of a decentralized network, and discover new opportunities

In this blog post, we'll show you how to set up a Nostr relay server on your Android phone, using Termux and Fonstr, so you can join this exciting world of decentralized communication even if you're not a tech expert.

Getting Started: Installing Termux

First things first, let's get Termux installed on your Android phone. Termux is a powerful terminal emulator that allows you to run a Linux environment on your Android device.

To install Termux, follow these simple steps:

Download and install the F-Droid app store on your phone. F-Droid is an alternative app store for Android that focuses on free and open-source software. You can download F-Droid from their website.
Open F-Droid, search for "Termux," and install the app.

Preparing Your Phone with Termux

Now that you have Termux installed on your phone, let's set up the environment:

Open Termux and enter the following command to update the package list and upgrade the installed packages:

pkg update && pkg upgrade

Next, install Node.js by entering:

pkg install nodejs

Finally, install Git with the following command:

pkg install git

Great! You've just set up your phone to run a Nostr relay.

Installing Fonstr: Your Nostr Relay Server

With your environment ready, it's time to install Fonstr:

In Termux, clone the Fonstr repository with the following command:

git clone https://github.com/nostrapps/fonstr.git

Navigate to the project directory:

cd fonstr

Install the necessary dependencies:

npm install

Running Your Nostr Relay: It's Showtime!

With everything set up, you can now run your Nostr relay server:

./index.js [port]

Replace [port] with the desired port number. If no port is provided, the server will run on port 4444 by default.

Hooray! Your Nostr relay server is up and running on your Android phone, and you're now part of the Nostr decentralized network.

Testing Your Relay with Websocat

To make sure everything is working correctly, you can test your relay using Websocat. Websocat is a command-line tool that allows you to interact with WebSocket servers.

Install Websocat on your computer by following the instructions on their GitHub page.

pkg install websocat

Open a terminal on your computer and enter the following command to connect to your Nostr relay:

websocat ws://[your-phone-ip]:[port]

Replace [your-phone-ip] with your phone's IP address and [port] with the port number you used when starting the relay.

You should now be able to communicate with your Nostr relay!

Test Events

To test sending an event you can use NAK to create an event e.g.

{
  "content": "hello world",
  "created_at": 1683206612,
  "id": "9d87daf61771777d73ea901efd3771f142fbc887283d75771dbeda030d725c7e",
  "kind": 1,
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "sig": "54be52723617100b776730cc8c1871698b222ddfae4bbbd47627705593e09731f147708b3808b14b71fdcac0bcd6e3fef11442b48f0d5cbca7e58d2e03ae4d53",
  "tags": []
}

Send ["EVENT", <your event] via websocat

To listen for new events try:

echo '["REQ", "fonstr", {}]' | websocat -n --ping-interval 20  ws://localhost:4444

Conclusion

You've just opened a world of possibilities by setting up a Nostr relay server on your Android phone. This achievement not only allows you to stay connected to a decentralized network but also empowers you to explore new opportunities in the world of communication and collaboration. By following these simple steps, even non-technical users can join and contribute to the Nostr network.

As you become more familiar with Nostr and its potential, you might want to explore other Nostr applications and tools to expand your knowledge and capabilities. With the power of decentralized communication at your fingertips, the sky's the limit!

Don't hesitate to share your Nostr relay experience with friends and fellow enthusiasts. By spreading the word about the Nostr protocol and its benefits, we can build a more robust, decentralized, and open network for everyone to enjoy.

Happy exploring!

DEV Community: Melvin Carvalho

The Web's Missing Piece: How DID-Nostr Quietly Solves Social Portability

The Facebook Lesson We Forgot

The Problem We've Normalized

What Is DID-Nostr?

Beyond Native Nostr: Why Standards Matter

The Ecosystem That Becomes Possible

The Technical Innovation

The Local-First Revolution

Why Portable Social Graphs Matter

Real Applications

The Broader Context

Current Limitations

What Changes

Looking Forward

Blocktrails: Smart-Contract Functionality - On Bitcoin, No Extra Token Needed

🏷️ What’s a Blocktrail?

🧩 Think “Git Commits on Bitcoin”

🔧 Blocktrail in (Pseudo) JavaScript

🏗️ Why You Might Care

🧪 What Can You Build?

🔭 Next Up: blocktrails-js

TL;DR

🕶️ Introducing Shade: Taproot-Based Messaging in the Post-Surveillance Web

🌱 Why Shade?

🧩 How It Works

🔐 Identity and Encryption

☁️ Storage: NosDAV

🔎 Metadata Resistance

⚙️ The Developer Stack

🧪 Sample CLI

🌍 Platform Goals

💡 Why Not Nostr DMs?

Threadlocks: One-Time Commitments with Bitcoin and Nostr

⛓️ The Problem with Open-Ended State

💡 Introducing Threadlocks

🧵 What’s a Threadlock?

🔧 How Threadlocks Work (In Plain Terms)

1. Lock the Thread

2. Declare the Thread

3. Resolve the Lock

📜 Why Not Just Use Smart Contracts?

🌐 What Nostr Brings to the Table

🧪 Use Cases

🛠️ Future: Libraries, NIPs, Agents

What Does `did-nostr` Do?

🧭 What Does did-nostr Do?

💡 Example: Basic did-nostr Document

🧩 What Kind of Services Can You Attach?

🔌 Relays

🧾 Consistent Profiles

📦 Storage

✉️ Messaging Inbox

🪪 Verifiable Credentials

🪙 Bitcoin Wallet

🤝 Why Use did-nostr?

📬 Want to Build With It?

Sketch: Selling Digital Art with DID-Nostr, Bitcoin, and Nostr

Sketch: Selling Digital Art with DID-Nostr, Bitcoin, and Nostr

What is DID-Nostr?

Empowering Artists through NFTs

Technical Overview: Minting an NFT with DID-Nostr

1. Minting the NFT

2. Announcing on Nostr

3. Selling with Bitcoin

Benefits for Artists and Collectors

Envisioning a Decentralized Artistic Future

Trustless Bitcoin Swaps with DID, Nostr, and HTLCs

🤔 The Problem

🔗 A Simple Use Case

💡 Scenario: On-chain to Lightning Swap

🧩 Enter DID + Nostr + HTLCs

✅ 1. Identity via DIDs on Nostr

📡 2. Coordinating via Nostr

🔐 3. The HTLC Swap

Alice (on-chain):

Bob (Lightning):

✅ 4. Atomic Swap Complete

✨ Why This Matters

🔮 What’s Next?

🔭 Next Up: `blocktrails-js`

🧭 What Does `did-nostr` Do?

💡 Example: Basic `did-nostr` Document

🤝 Why Use `did-nostr`?