Idempotent Proxy Show: proxy HTTPS Outcalls to any Web2 service

Showcase
1

Project Highlights

The idempotent-proxy is a reverse proxy service written in Rust with built-in idempotency support. This project addresses the need for consistent and reliable request handling by caching responses to repeated requests with the same idempotency key. The target users are developers and enterprises who require dependable HTTP request handling and integration with Web2 services, specifically through HTTPS outcalls for ICP canisters.

image
image1104×760 70.8 KB

Web3 Advantages

While there are numerous reverse proxy services in the Web2 world, the idempotent-proxy differentiates itself by integrating seamlessly with Web3 technologies, particularly the Internet Computer Protocol (ICP). Unlike traditional Web2 proxies, idempotent-proxy supports idempotent operations, ensuring consistent responses to repeated requests, which is crucial for blockchain applications where determinism and consistency are paramount.

How It Is Built

The project is built using Rust and Cloudflare Worker. It leverages open-source libraries and integrates Redis (or DurableObject in Cloudflare Worker) for caching responses. The architecture includes:

  • A reverse proxy server to handle incoming requests
  • Caching responses in Redis to ensure idempotency
  • Filtering responses and headers to return only necessary data
  • Implementing access control using Secp256k1 and Ed25519 for secure operations

Internet Computer Superpowers

The Internet Computer’s advanced features like HTTPS outcalls and robust canister support are crucial for this project. The ability to proxy HTTPS requests directly from ICP canisters enables seamless integration with Web2 services, enhancing the overall functionality and user experience of decentralized applications.

Go-To-Market Strategy

To attract users, the project will focus on:

  • Engaging with the ICP developer community through forums and social media
  • Collaborating with DFINITY and other Web3 projects to demonstrate use cases
  • Offering comprehensive documentation and support to facilitate adoption

Monetization

The project is open-source and aims to generate revenue through support services, custom implementations, and possibly premium features in the future.

Status of the Project

The project has successfully implemented the core features, including idempotent request handling, response filtering, and access control. It has received a $5k Developer Grant from the DFINITY Foundation, highlighting its potential and value. The proxy service is fully functional, and integration with ICP canisters has been demonstrated.

Resources

Future Plans

Future plans for the project include:

  • Recommend this project to potential clients to increase usage cases
  • Enhancing performance and scalability
  • Adding support for more complex product demand
5 Likes
2

This is great ! Well done

1 Like
3

:wave: @zensh

First I’d like to thank you for the awesome work you did with the idempotent-proxy. It’s been a month we are using it and it works very well. One thing we would like to do though is to reduce the number of cycles it consumes. It currently consumes almost 1T cycle/day. I have been trying to increase the proxy_token_refresh_interval but it didn’t change the cycle consomption. Do you have any idea what else I could try?

Thank you :pray:

4

The proxy_token request is infrequent, and its cycles consumption is negligible. The main source of cycles usage is the HTTP Outcall, which depends on your business needs. To reduce cycles consumption, you can:

  1. Minimize HTTP calls.
  2. Reduce the size of request and response payloads, such as using response headers filtering and JSON response filtering.
5

Thanks for your answer. This is surprising to me, because my app has currently almost no user, so most of the time there is not a single http outcall made. However, the burn rate is very stable as you can see:

image
image1013×715 46.8 KB

6

You can find details about signature costs at Threshold signatures | Internet Computer. A simple calculation:

  • Using test_key_1, each signature costs 0.01 T.
  • With a single proxy agent refreshing the signature hourly, the daily cycles consumption is:
    24 * 0.01 T = 0.24 T.

Including business-related cycles, a daily consumption of 1T seems reasonable.
You can reduce the update frequency, such as refreshing the signature every 24 hours.

1 Like