webr3

Hyper Agent Protocol (HAP) - An Overview

What is HAP?

The Hyper Agent Protocol (HAP) is a new, simplified standard for how software "agents" (or any automated services and capabilities) communicate with each other over the web. Imagine a universal way for different software components to discover what other components can do and then ask them to do it, all using standard web technologies.

The goal of HAP is to make it much easier to build flexible, interoperable systems where different services, tools, or AI agents can work together seamlessly, regardless of how they are built internally.

Core Idea: Every Capability has a Web Address (URI)

melvincarvalho

1. High-level architecture

┌──────────────┐        WebSocket / HTTP-JSON        ┌──────────────────┐
│  CJ Client   │  <-- register / sign / finalize --> │  CJ Coordinator  │
└──────────────┘                                      └──────────────────┘
        ▲                                                       │
        │ uses                                                  │ broadcasts
        │                                                       ▼
┌──────────────────┐ ┌──────────────────┐

webr3

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.

Part 1: Model Context Protocol (MCP) Functionality

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).

Client-to-Server Request Methods:

• 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.

melvincarvalho

🕊️ Agentic Principles Manifesto

A call for autonomy, dignity, and trust in the age of intelligent agents.

---

1. Agents Must Serve the User First

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.

melvincarvalho

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.

Key Elements:

1. Human-Readable Clarity: Each contract includes a clearly written, legally interpretable text detailing the contractual terms, signed and timestamped as a Nostr note.

2. Cryptographic Certainty:

RubenSomsen

SwiftSync

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.

Introduction

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

melvincarvalho

nip	title	status	author	created	discussions-to
TBD	Linked Subkeys for Multi-Device Nostr Usage	Draft	Melvin Carvalho	26-02-2025	nostr-protocol/nips#1810

Linked Subkeys for Multi-Device Nostr Usage

melvincarvalho

Glyphs

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.

Glyphstones

Glyph protocol messages, called glyphstones, are stored in Bitcoin transaction outputs.

melvincarvalho

NIP-570: Public On-Chain Zaps and Anti-Zaps

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.

Summary

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).

Motivation

aidik

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.

Prerequisite

• A server with Nginx responding to basic requests. (minimal configuration should be enough)

Config

Inside the http block insert map and map_hash_bucket_size directives:

map_hash_bucket_size 256;

map $arg_name $nostr_key {