Showing posts with label protocol. Show all posts
Showing posts with label protocol. Show all posts

Open Payment Standard x402 Expands Capabilities in Major Upgrade

Mike's Notes

A need-to-know for handling payments in the future.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ
  • Home > Handbook > 

Last Updated

22/03/2026

Open Payment Standard x402 Expands Capabilities in Major Upgrade

By: Sergio De Simone
InfoQ: 22/01/2026

Sergio De Simone is a software engineer. Sergio has been working as a software engineer for over twenty five years across a range of different projects and companies, including such different work environments as Siemens, HP, and small startups. For the last 10+ years, his focus has been on development for mobile platforms and related technologies. He is currently working for BigML, Inc., where he leads iOS and macOS development.

After six months of real-world usage, the open payment standard x402 has received a major update, extending the protocol beyond single-request, exact-amount payments. The release adds support for wallet-based identity, automatic API discovery, dynamic payment recipients, expanded multi-chain and fiat support via CAIP standards, and a fully modular SDK for custom networks and payment schemes.

"V2 is a major upgrade that makes the protocol more universal, more flexible, and easier to extend across networks, transports, identity models, and payment types. The spec is cleaner, more modular, and aligned with modern standards including CAIP and IETF header conventions, enabling a single interface for onchain and offchain payments."

x402 V2 offers a unified payment interface supporting stablecoins and tokens across multiple chains, including Base, Solana, and others, while maintaining compatibility with legacy payment rails such as ACH, SEPA, and card networks. It also introduces per-request routing to specific addresses, roles, or callback-based payout logic, enabling complex multi-step payment workflows.

Another enhancement in x402 V2 is the clear separation between the protocol specification, its SDK implementation, and facilitators (responsible for verifying and settling the payment on-chain), which improves extensibility and enables a modular, plug-in–based architecture.

The new standard also introduces wallet-based access, reusable sessions, and modular paywalls. Wallet support provides clients with greater flexibility, streamlining payment flows and reducing round-trip and latency for previously purchased items. Modular paywalls enable developers to integrate and extend new backend payment logic, fostering a more extensible ecosystem.

Finally, x402 V2 improves the developer experience by simplifying configuration through its modular design, adding support for choosing multiple facilitators simultaneously, and minimizing the amount of glue code or boilerplate required.

x402 is an open, web-native payment standard/protocol designed to make payments a first-class citizen of the internet. It enables micro-payments, pay-per-use, and machine-to-machine payments, allowing web apps, APIs, and autonomous agents (like AI bots) to pay for services directly over HTTP without traditional accounts, subscriptions, or complex payment flows. Within months, the protocol has processed over 100 million payment flows across APIs, web applications, and autonomous agents.

The protocol leverages the rarely used HTTP status code 402 (Payment Required) to signal when payment is required and to include payment instructions in the response. By using x402, payments can be executed directly within the HTTP request–response flow, eliminating the need to redirect users to external payment pages or to rely on API keys and personal accounts.

Cloudflare, as one of the original partners in the x402 Foundation alongside Coinbase, integrated support for the protocol into its developer tools and infrastructure. This includes both the Agents SDK, which allows developers to build agents capable of automatically making payments using x402, and MCP servers that expose x402-enabled tools and enable services to return 402 Payment Required responses and accept x402 payments from clients.

By , No comments:
Tags , , , ,

Agent Card

Mike's Notes

Earlier this week, I attended the APAC Cloud Technical Series: On Board from Google. It was 10 hours over 2 days of talks and code workshops from Google staff, who were mainly based in Singapore.

It was excellent and worth the time. I signed up for more sessions planned later in the year. Google Weeklies is a regular in-depth talk available both live and as an archive. Excellent stuff.

I got an invite to join Google for Startups' Rising Founders program. I hope that this will lead to access to researchers at Google DeepMind. I have questions.

I initially registered to participate in the Gen AI Academy APAC Edition, which would have been fun, but then I discovered an age restriction. I'm too ancient. 😊

IaC

This will help me build Pipi Engines to build, deploy, and manage infrastructure-as-code (IaC) in the cloud.

A dedicated agent engine has been created for each cloud platform. They have yet to be differentiated.

  • Apple Engine (ale)
  • AWS Engine (aws)
  • AZURE Engine (azu)
  • Digital Ocean Engine (dgo)
  • Google Cloud Engine (ggc)
  • IBM Engine (ibm)
  • Meta Engine (met)
  • Oracle Engine (ora)
  • (More will be added later; all are welcome)

Agents

Pipi 9 is a type of world-model AI, not an LLM. Google is offering a platform for LLM-based generative AI agents. My thought is to connect Pipi 9 to these external agents via open protocols, leveraging the strengths of both.

  • MCP
    • PostgreSQL
    • TPU
    • etc
  • A2A
    • Agent Card
  • ADK

More Pipi engines

  • MCP Engine (mcp)

Agent card

Here are some initial notes about the Agent Card protocol, part of A2A. I will start building from there.

Pipi is an agent built from hundreds of other kinds of deeply nested agents, and is capable of learning, evolving and replicating. So does this mean that Pipi needs its own Agent Card? 😀

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

13/02/2026

Agent Card

By: Mike Peters
On a Sandy Beach: 1/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

From A2A Protocol Documentation

A2A revolves around several key concepts. For detailed explanations, please refer to the Key Concepts guide.

    • A2A Client: An application or agent that initiates requests to an A2A Server on behalf of a user or another system.
    • A2A Server (Remote Agent): An agent or agentic system that exposes an A2A-compliant endpoint, processing tasks and providing responses.
    • Agent Card: A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.
    • Message: A communication turn between a client and a remote agent, having a role ("user" or "agent") and containing one or more Parts.
    • Task: The fundamental unit of work managed by A2A, identified by a unique ID. Tasks are stateful and progress through a defined lifecycle.
    • Part: The smallest unit of content within a Message or Artifact. Parts can contain text, file references, or structured data.
    • Artifact: An output (e.g., a document, image, structured data) generated by the agent as a result of a task, composed of Parts.
    • Streaming: Real-time, incremental updates for tasks (status changes, artifact chunks) delivered via protocol-specific streaming mechanisms.
    • Push Notifications: Asynchronous task updates delivered via server-initiated HTTP POST requests to a client-provided webhook URL, for long-running or disconnected scenarios.
    • Context: An optional, server-generated identifier to logically group related tasks and messages.
    • Extension: A mechanism for agents to provide additional functionality or data beyond the core A2A specification.

- A2A Protocol Documentation

Agent Discovery in A2A

To collaborate using the Agent2Agent (A2A) protocol, AI agents need to first find each other and understand their capabilities. A2A standardizes agent self-descriptions through the Agent Card. However, discovery methods for these Agent Cards vary by environment and requirements. The Agent Card defines what an agent offers. Various strategies exist for a client agent to discover these cards. The choice of strategy depends on the deployment environment and security requirements.

The Role of the Agent Card

The Agent Card is a JSON document that serves as a digital "business card" for an A2A Server (the remote agent). It is crucial for agent discovery and interaction. The key information included in an Agent Card is as follows:

  • Identity: Includes name, description, and provider information.
  • Service Endpoint: Specifies the url for the A2A service.
  • A2A Capabilities: Lists supported features such as streaming or pushNotifications.
  • Authentication: Details the required schemes (e.g., "Bearer", "OAuth2").
  • Skills: Describes the agent's tasks using AgentSkill objects, including id, name, description, inputModes, outputModes, and examples.

Client agents use the Agent Card to determine an agent's suitability, structure requests, and ensure secure communication.

Sample Agent Card

{
  "protocolVersions": ["1.0"],
  "name": "GeoSpatial Route Planner Agent",
  "description": "Provides advanced route planning, traffic analysis, and custom map generation services. This agent can calculate optimal routes, estimate travel times considering real-time traffic, and create personalized maps with points of interest.",
  "supportedInterfaces": [
    {"url": "https://georoute-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC"},
    {"url": "https://georoute-agent.example.com/a2a/grpc", "protocolBinding": "GRPC"},
    {"url": "https://georoute-agent.example.com/a2a/json", "protocolBinding": "HTTP+JSON"}
  ],
  "provider": {
    "organization": "Example Geo Services Inc.",
    "url": "https://www.examplegeoservices.com"
  },
  "iconUrl": "https://georoute-agent.example.com/icon.png",
  "version": "1.2.0",
  "documentationUrl": "https://docs.examplegeoservices.com/georoute-agent/api",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": false,
    "extendedAgentCard": true
  },
  "securitySchemes": {
    "google": {
      "openIdConnectSecurityScheme": {
        "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
      }
    }
  },
  "security": [{ "google": ["openid", "profile", "email"] }],
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "image/png"],
  "skills": [
    {
      "id": "route-optimizer-traffic",
      "name": "Traffic-Aware Route Optimizer",
      "description": "Calculates the optimal driving route between two or more locations, taking into account real-time traffic conditions, road closures, and user preferences (e.g., avoid tolls, prefer highways).",
      "tags": ["maps", "routing", "navigation", "directions", "traffic"],
      "examples": [
        "Plan a route from '1600 Amphitheatre Parkway, Mountain View, CA' to 'San Francisco International Airport' avoiding tolls.",
        "{\"origin\": {\"lat\": 37.422, \"lng\": -122.084}, \"destination\": {\"lat\": 37.7749, \"lng\": -122.4194}, \"preferences\": [\"avoid_ferries\"]}"
      ],
      "inputModes": ["application/json", "text/plain"],
      "outputModes": [
        "application/json",
        "application/vnd.geo+json",
        "text/html"
      ]
    },
    {
      "id": "custom-map-generator",
      "name": "Personalized Map Generator",
      "description": "Creates custom map images or interactive map views based on user-defined points of interest, routes, and style preferences. Can overlay data layers.",
      "tags": ["maps", "customization", "visualization", "cartography"],
      "examples": [
        "Generate a map of my upcoming road trip with all planned stops highlighted.",
        "Show me a map visualizing all coffee shops within a 1-mile radius of my current location."
      ],
      "inputModes": ["application/json"],
      "outputModes": [
        "image/png",
        "image/jpeg",
        "application/json",
        "text/html"
      ]
    }
  ],
  "signatures": [
    {
      "protected": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJrZXktMSIsImprdSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vYWdlbnQvandrcy5qc29uIn0",
      "signature": "QFdkNLNszlGj3z3u0YQGt_T9LixY3qtdQpZmsTdDHDe3fXV9y9-B3m2-XgCpzuhiLt8E0tV6HXoZKHv4GtHgKQ"
    }
  ]
}
By , No comments:
Tags , , , , ,

HTTP 2 vs HTTP 3 — What's the Difference?

Mike's Notes

Useful background information.

Resources

References


  •

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Level Up Coding

Last Updated

23/03/2025

HTTP 2 vs HTTP 3 — What's the Difference?

By: Nikky Siapno
Level Up Coding: 23/03/2025

HTTP 1 started in 1996. The very next year HTTP 1.1 followed. It was another ~20 years until HTTP 2 became standardized in 2015. And in recent years (2022), HTTP 3 was officially standardized.

But what’s the difference?

Starting at the foundation:

HTTP 1.1:

  • Persistent connections — Reuses connections instead of opening new ones
  • Chunked transfers — Sends data in parts instead of waiting for the full response
  • Improved caching — Introduced headers for better caching and connection management
  • Sequential requests — Requests block each other (HoL blocking at the request level)
  • Multiple connections needed — Browsers used multiple TCP connections for speed
  • It introduced core features still used today.

HTTP 2:

  • Multiplexing — Multiple requests in a single TCP connection
  • Header compression (HPACK) — Reduces metadata size
  • Stream prioritization — Ensures critical resources load first
  • Head-of-line (HoL) blocking — A lost packet blocks all streams
  • While HTTP 2 optimized TCP, it remained constrained by TCP’s head-of-line blocking.

HTTP 3:

  • Built on QUIC (UDP) — No more TCP bottlenecks
  • Independent streams — Packet loss in one stream doesn’t affect others
  • Faster handshakes — Combines transport + encryption setup in one step
  • Mandatory encryption (TLS 1.3) — Security by default
  • Connection migration — Seamless across network changes

In a nutshell: HTTP 2 optimized TCP, but HTTP 3 rewrites the game with QUIC, making it faster, more reliable, and encrypted by default.

Which fact surprised you?

By , No comments:
Tags ,

Progress on the block protocol

Mike's Notes

Joel Spolsky has some ideas about the semantic web.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

18/05/2025

Progress on the block protocol

By: Joel Spolsky
Joel on Software: 19/02/2002

Since the 1990s, the web has been a publishing place for human-readable documents.

Documents published on the web are in HTML. HTML has a little bit of structure, for example, “here is a paragraph” or “emphasize this word.”

Then you stir in some CSS, which adds some pretty decorations to the structure, saying things like: make those paragraphs have tiny gray sans-serif text! And then people think you are hip. Unless they are older, and they can’t read your tiny gray words, so they give up on you. That’s “structure,” as far as it goes, on the web.

Imagine, for example, that you mention a book on the web.

Goodnight Moon
by Margaret Wise Brown
Illustrated by Clement Hurd
Harper & Brothers, 1947
ISBN 0-06-443017-0

There’s not much structure there. A naive computer program reading this web page might not realize I was even mentioning a book. All I did was make the title bold.

So, also since the 1990s, people have realized that we can make the web a much more useful place to publish information if we applied a bit more structure. As early as 1999, Tim Berners-Lee was writing about the Semantic Web:

“I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which makes this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize.” - Tim Berners-Lee, Weaving The Web, 1999 HarperSanFrancisco (Chapter 12)

Using the Semantic Web you might publish a book title with a lot more detail that makes it computer-readable. To do this, you would probably start by going to schema.org and looking up their idea of a book. Then you could use one of a number of formats, like RDF or JSON-LD, to add additional markup to your HTML saying “hey! here’s a book!”

Ok, well, doing that is kinda hard to figure out, and, to be honest, it’s homework. Once your beautiful blog post is published and human-readable, it’s hard to gather the mental energy to figure out how to add the additional fancy markups that will make your web page computer-readable, and, unless there is already a computer reading your web pages, at this point, you usually give up. So, yeah. That was 1999, and not much progress has been made and there is very little of this semantic markup in the wild.

Well.

We would like to fix this, because human progress depends on getting more and more information in formats that are readily accessible, both by regular humans, their dumb A.I. li’l sibs, and your more traditional computer programs.

Here is something I believe: people will only add semantic markup to their web pages if doing so is easier than not.

In other words, the cost of adding semantic markup has to be zero or negative, or this whole project is not going anywhere.

Now imagine this world for a second:

I want to insert a book into my blog post

  • I type /book
  • A search box appears where I start typing in the title of my book and choose from an autocomplete list.
  • Once I find the book, a block gets inserted in my blog post showing details of the book in a format I like, with nice semantic markup behind the scenes.
  • In this world I did less work to insert a book (because I was assisted by a UI that looked up the details for me).

You can imagine the same scenario applying to literally any other kind of structured data.

I want to insert an address into my blog post

  • I type /address
  • A search box appears where I start to type a location, which autocompletes in the way you have seen Instagram and Google Maps and a million other apps do it
  • Once I choose the address, a block gets inserted showing the details of the address complete with semantic markup behind the scenes.
My “address block” might have any visual appearance. Visitors to my web page might see the address, or a little map, or a little map in Japanese, etc. etc. The semantic content is there behind the scenes. So, for example, my web browser might know “gosh this is an address!

Maybe you want to do address-y things with it, like go there,” and then my browser might offer me options to summon a self-driving car and even call an ambulance when the self-driving car self-drives into a snowbank.

My two simplistic examples of “book” and “address” are interesting right now because (a) you can probably think of 1,000,000 more data types like this, and (b) none of these things work right now, because even though almost every web editing environment has a concept of “blocks,” none of them are extensible. WordPress has (oh gosh) hundreds of block types, but they don’t have thousands or millions, they don’t have “book” or “address” or “Burning Man Theme Camp” yet, and there’s no ecosystem by which developers and users can contribute new block types.

So I guess I gotta wait around for someone at WordPress to develop all the blocks I want to use. And then someone at Notion, and then someone at Trello, and then someone at Mailchimp, and someone at every other vendor that provides a text editor.

I have a better plan.

The web was built with open protocols. Suppose we all agree on a protocol for blocks.

Any developer that wants to create a new block can conform to this protocol.

Any kind of web-text-editing application can also conform to this protocol.

Then if anyone goes to the trouble of creating a cool “book” or “address” block, we’ll all be able to use it, anywhere.

And we shall dub this protocol, oh I don’t know, the Block Protocol.
And it should be, I think, 100% free, open, and public, so that there is no impediment to anyone on earth using it. And in fact if you want to make blocks that are open source or public, good for you, but if for some reason you would like to make private or commercial blocks, that’s fine too.

Where we’re up to

It’s been about a year since we started talking about the Block Protocol, and we’ve made a lot of progress figuring out how it has to work to do all the things it will need to do, in a clean and straightforward way.

But this is all going nowhere if it requires 93,000,000 humans to cooperate with my crazy scheme just to get it off the ground.

So what we did is build a WordPress Plugin that allows you to embed Block Protocol blocks into posts on your WordPress sites just as easily as you insert any other block.

Since WordPress powers 43% of the web, that means if you build a block for the Block Protocol, it’ll be widely usable right away.
Here’s a video demo:

The WordPress Plugin will be free, and it will be widely available in February, when we’ll also publish version 0.3 of the Block Protocol specification. You can get early access now.

In fact, if you were thinking of writing a plugin for WordPress for your own kind of custom block, you’ll find that using our plugin as your starting point is a lot easier, because you don’t have to know anything about WordPress Plugins or write any PHP code. So even if you don’t care for any of my crazy theories and just want to add a block to WordPress, this is the way to go.

Ultimately, though, we just want to make it easier to add useful semantic, structured information to the web, and this is the first step.

PS We just set up a Discord server for the Block Protocol where you can participate, ask questions, and meet the team.

By , No comments:
Tags ,
Subscribe to: Posts (Atom)