┌──────────────┐ WebSocket / HTTP-JSON ┌──────────────────┐
│ CJ Client │ <-- register / sign / finalize --> │ CJ Coordinator │
└──────────────┘ └──────────────────┘
▲ │
│ uses │ broadcasts
│ ▼
┌──────────────────┐ ┌──────────────────┐
This document outlines the key functionalities of the Model Context Protocol (MCP) and the Agent-to-Agent (A2A) protocol, derived from their respective JSON schema definitions (schema.json
for MCP, dated 2025-03-26, and a2a.json
for A2A). It then presents a comparative table to identify common and unique functionalities and analyze interoperability.
Derived from schema.json
. MCP facilitates interactions between a "client" (e.g., an LLM-hosting environment or agent framework) and a "server" (providing tools, resources, or prompts).
initialize
: Client initiates connection with the server, exchanging capabilities (ClientCapabilities
,ServerCapabilities
), protocol versions, and implementation information.ping
: Client sends to server to check liveness and ensure the connection is active.resources/list
: Client requests a list of available data resources from the server.
A call for autonomy, dignity, and trust in the age of intelligent agents.
Agents are extensions of human will—not proxies for corporations. They must act in the user’s interest, not in the interest of advertisers, platforms, or centralized authorities.
Introducing Nostr Ricardian Contracts
Nostr Ricardian Contracts combine the clarity of human-readable, legally enforceable agreements with the cryptographic certainty and decentralization of smart contracts on Bitcoin layers. This innovative approach leverages Nostr, a decentralized messaging protocol, to publish signed human-readable legal agreements that accompany traditional smart contract logic running on Bitcoin-based layers such as RGB, Discreet Log Contracts (DLC), Liquid, or Lightning Network.
-
Human-Readable Clarity: Each contract includes a clearly written, legally interpretable text detailing the contractual terms, signed and timestamped as a Nostr note.
-
Cryptographic Certainty:
Near-stateless, fully parallelizable validation of the Bitcoin blockchain with hints about which outputs remain unspent. All other inputs/outputs are efficiently crossed off inside a single hash aggregate that only reaches zero if validation was successful and the hints were correct.
Validation is at the heart of Bitcoin. Any improvements in validation speed will have a direct impact on the scalability of the system, including everything that is built on top of it. For this reason improving validation performance may be one of the most important things we can do.
The generalized observation of SwiftSync is that if we have two sets (in this case the inputs and outputs), and we want to know the difference between these sets (the UTXO set), validating a given answer to this question (the hints) is significantly easier than calculating the answer itself. The novel part here (to my knowledge) is specifically how this can be applied to sets. It seems likely that this observation ca
nip | title | status | author | created | discussions-to |
---|---|---|---|---|---|
TBD |
Linked Subkeys for Multi-Device Nostr Usage |
Draft |
Melvin Carvalho |
26-02-2025 |
Glyphs allow Bitcoin transactions to etch, mint, and transfer Bitcoin-native digital commodities. They are very similar to the Runes protocol, but rely soley on OP_RETURNs, and do not support inscriptions. Glyphs are designed to be compatible with nostr npubs and bitcoin taproot.
Whereas every glyph is unique, every unit of a glyph is the same. They are interchangeable tokens, fit for a variety of purposes.
Glyph protocol messages, called glyphstones, are stored in Bitcoin transaction outputs.
Authors Melvin Carvalho
optional
draft
Disclaimer: this is an early draft and should be considered v0.0.0, use xxzap in testing, so it is not indexed. Final version should probably used OP_PUSHNUM
and OP_PUSHBYTES
TBD. That said the spec is ready for experimentation and feedback.
This proposal outlines a method for implementing simple on-chain zaps between Nostr users using Taproot addresses. The proposal includes specifications for both regular zaps and negative zaps (antizaps).
Nostr NIP-05 specification makes it a bit harder to serve identifiers from a simple webserver without CGI to run an external program handling the name
URL query parameter. I really didn't want to do all that, so instead I focused on how to handle everything just in Nginx itself.
- A server with Nginx responding to basic requests. (minimal configuration should be enough)
Inside the http
block insert map
and map_hash_bucket_size
directives:
map_hash_bucket_size 256;
map $arg_name $nostr_key {
#!/bin/bash | |
# Mirrors notes from one nostr relay to another. | |
# | |
# Example usage: | |
# nostr-mirror.sh wss://source.relay.example wss://target.relay.example | |
# Source relay to fetch events from (wss://...). | |
SOURCE=$1 | |
# Target relay to send these events to (wss://...). | |
TARGET=$2 |