Remove Complete message type per updated TAIP specifications #21
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Remove Complete message implementation from tap-msg - Remove CompleteTool from tap-mcp tools - Update test files to remove Complete references - Update MCP integration test to expect 30 tools instead of 31 - Update README.md to list Cancel and Revert instead of Complete This aligns the codebase with the updated TAIP specifications where the Complete message has been removed in favor of using the standard TAIP-4 authorization flow (Payment -> Authorize -> Settle). 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Updated TAIPs submodule to commit 2f8e503 with significant enhancements: - Schema.org Organization attributes for Agents and Parties - AuthorizationRequired message moved to TAIP-4 - RFC 8905 PayTo URI support for settlement addresses - Fallback settlement addresses for Payment messages - Schema.org Product attributes for invoice line items - Enhanced IVMS101 data inclusion - ServiceUrl field for Agent DIDComm endpoint fallback - Added TASKS.md with TDD-focused implementation plan - Organized into 5 phases with test-first approach - Each feature has failing tests written before implementation - Maintains backward compatibility through optional fields
- Added schema.org Organization field accessors and builders to Agent: - name, url, logo, description, email, telephone fields - serviceUrl field for DIDComm endpoint fallback (TAIP-5) - All fields use existing metadata HashMap for backward compatibility - Added typed accessor methods and builder pattern support - Added schema.org Organization field accessors and builders to Party: - name, url, logo, description, email, telephone fields - Added with_metadata_field builder method - All fields use existing metadata HashMap for backward compatibility - Verified IVMS101 data can coexist with schema.org fields - Followed TDD approach: wrote failing tests first, then implementation - All tests passing, JSON-LD compliance maintained - Updated TASKS.md to mark Phase 1 as complete
…cation - Updated existing AuthorizationRequired struct in connection.rs: - Changed 'url' field to 'authorizationUrl' per TAIP-4 - Made 'expires' field required (was optional) - Added optional 'from' field for party type (customer, principal, originator, beneficiary) - Removed deprecated 'agent_id' field - Updated validation logic: - Validates expires is present and in ISO 8601 format - Validates 'from' field contains valid party type if present - Added comprehensive tests: - Creation and builder pattern tests - Serialization/deserialization tests - Validation tests for all fields - JSON compliance with TAIP-4 specification - Updated TASKS.md to mark Phase 2 as complete Note: AuthorizationRequired was moved from TAIP-15 to TAIP-4 as a standard authorization message, replacing the removed Complete message functionality.
- Applied cargo fmt to all modified files - Fixed formatting in Agent and Party accessor methods - Fixed formatting in test files - Fixed import statement formatting - No functional changes, only formatting cleanup
- Added test vectors for AuthorizationRequired matching TAIP-4 specification - Added test vectors for Transfer with PayTo URI support (RFC 8905) - Added test vectors for Escrow messages (TAIP-17) - Added test vectors for Payment with PayTo URI invoices - Fixed existing test vectors to match JSON schema requirements The AuthorizationRequired test vectors now correctly use 'authorizationUrl' field name as specified in TAIP-4, which matches our implementation.
…d TAIPs - Add PayTo URI support (RFC 8905) for traditional payment systems - Add SettlementAddress enum supporting both CAIP-10 and PayTo URIs - Add fallbackSettlementAddresses field to Payment messages - Add schema.org/Product attributes (name, image, url) to LineItem - Add LineItem builder for easier construction - Update all existing LineItem usages with new fields - Add comprehensive tests for all new features 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
…changes 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Mark all completed implementation tasks with [x]: - Phase 1-4: All tasks completed - Phase 5: Partial completion (integration and validation done) Remaining items are MCP-specific integrations and test vector validation which are separate from the core TAP message implementation. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Update workspace version from 0.4.0 to 0.5.0 - Update all internal dependencies between crates to 0.5.0 - Update CHANGELOG to mark 0.5.0 release 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Add v0.5.0 highlights to main README - Document PayTo URI support and settlement address flexibility - Add examples for fallback settlement addresses - Document enhanced metadata support for Agents/Parties/LineItems - Add code examples for new schema.org Organization fields - Add examples for Product attributes in invoice line items - Update tap-msg README with new features 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Implement Escrow message for holding assets on behalf of parties - Implement Capture message for releasing escrowed funds - Support both cryptocurrency assets (CAIP-19) and fiat currencies (ISO 4217) - Add automatic expiry handling for escrows - Enable payment guarantees, asset swaps, and conditional payments - Add EscrowAgent role with validation for exactly one per escrow - Add comprehensive tests for all escrow scenarios - Update TapMessage enum to include Escrow and Capture variants - Update CHANGELOG with TAIP-17 support documentation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
This commit extends the TAP MCP server to support Payment (TAIP-14), Connect (TAIP-15), and Escrow/Capture (TAIP-17) message creation and management alongside the existing Transfer tools. New MCP Tools Added: - CreatePaymentTool: Creates TAIP-14 Payment messages with asset or currency support - CreateConnectTool: Creates TAIP-15 Connect messages with constraints and limits - CreateEscrowTool: Creates TAIP-17 Escrow messages with automatic EscrowAgent validation - CaptureTool: Creates TAIP-17 Capture messages for releasing escrowed funds Key Features: - Full schema definitions for all new tools with parameter validation - Support for both cryptocurrency (CAIP-19) and fiat currency transactions - Connection constraint handling with transaction limits - Automatic validation of EscrowAgent requirements per TAIP-17 - Integration with existing TAP node message delivery infrastructure Technical Details: - Added comprehensive parameter structures for each message type - Implemented proper field mapping between MCP parameters and TAP message structs - Fixed Payment struct compatibility by adding fallback_settlement_addresses field - Enhanced error handling and validation for all new message types 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
…schemas
Add two new MCP resources to provide better access to read-only data:
1. Database Schema Resource (tap://database-schema)
- Provides comprehensive database schema information for agent storage
- Supports filtering by agent_did (required) and table_name (optional)
- Returns table structures, column info, indexes, and row counts
- Uses read-only SQLite connections for safety
- Replaces need to use database schema tool for read-only access
2. Enhanced TAP Message Schemas Resource (tap://schemas)
- Existing resource enhanced with individual schema lookup capability
- Supports tap://schemas/{MessageType} for specific schemas
- Includes comprehensive JSON schemas for all TAP message types
- Added version information and structured metadata
- Supports lookup by both message type name and URL
Technical changes:
- Updated resource registry to include new database-schema resource
- Enhanced schemas resource with path-based routing for individual lookups
- Added database connection logic to resources layer
- Updated tests to reflect new resource count (6 total)
- Updated tool count in tests (34 total)
- Refactored schema generation to support both full and individual access
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <[email protected]>
Apply standard Rust formatting to the new MCP resources code.
Apply standard Rust formatting to all files in the workspace. This includes formatting changes to: - tap-mcp tools and schemas - tap-msg message types and tests - Add Claude agent configuration file 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Update README.md to document the new MCP resources added in v0.5.0: 1. Database Schema Resource (tap://database-schema) - Document new resource for accessing agent database schemas - Show query parameters and usage examples - Explain relationship to tap_get_database_schema tool 2. Enhanced TAP Schemas Resource (tap://schemas) - Document individual schema lookup capability - Show examples for specific message types (Transfer, Authorize, etc.) - Highlight v0.5.0 enhancements 3. Updated Examples - Add examples showing how to use the new resources - Include database schema and individual message schema lookups - Maintain consistency with existing documentation style 4. Resource Count Update - Update tool count from 29 to 34 tools - Update resource count to 6 total resources - Reflect current capabilities accurately 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Changes Made
Code Changes
Removed Complete message implementation:
tap-msg/src/message/complete.rstap-msg/src/message/mod.rsUpdated MCP tools:
tap-mcp/src/tools/transaction_tools.rstap-mcp/src/tools/mod.rstap-mcp/src/tools/schema.rsUpdated tests:
tap-agent/tests/test_vectors_validation.rsto remove Complete handlingDocumentation Changes
Test Plan
cargo test --workspace)cargo build)Context
The Complete message was removed from TAIP-14 in favor of using the standard TAIP-4 authorization flow (Payment -> Authorize -> Settle). This simplifies the protocol by removing redundant message types.
🤖 Generated with Claude Code