RFP-2: Agents - Libraries for secure integration with the IC
domwoe opened this issue · 8 comments
Overview
An IC (Internet Computer) Agent is responsible for encoding and decoding messages used to communicate with the IC via its HTTPS interface, as well as verifying responses from the IC by checking the signature against the public key of the IC.
DFINITY is maintaining two IC agent implementations which can be seen in a template:
In addition, there are currently the following community-driven IC agent implementations with varying completeness:
- icp-client-cpp (C++)
- ic4j-agent (Java/Kotlin)
- agent_dart (Dart/Flutter)
- ic_dart_tools (Dart/Flutter)
- agent-go (Go)
- IC-Go (Go)
- ic-py (Python)
- ICP.NET (C#/.NET/Unity)
- agent-unity (partial) C# wrapper of agent-rs))
- ic_agent (Ruby)
- ICPKit (Swift)
We are open to supporting work on existing agent implementations if features are missing, and we might support additional implementations for languages/frameworks that already exist if there is a good reason for this. In addition, the following agent implementations are desired:
Currently, there are active projects for all agents that have been requested. If you need another client library, please get in touch.
Requirements
- Implementation of the HTTPS interface as defined in the IC Interface Specification. In particular, the following endpoints must be implemented:
call
,read_state
,query
andstatus
. - Calculation of the
request id
using representation-independent hashing - Authentication: A request may be either anonymous or authenticated via signatures. For authenticated requests delegation should be supported.
- CBOR: Requests and responses are CBOR encoded, hence, an IC agent needs to be able to encode/decode CBOR.
- Candid: The IC uses Candid as the interface description language (IDL). An IC agent needs to be able to encode/decode arguments between candid and the agent's programming language.
- Support of
Principal
data type. - IC certificate verification: Responses from the
read_state
API include a certificate that needs to be parsed (to look up the relevant information from the state tree) and verified. The public key of the IC must be hard coded in the software. For verification of responses from a local replica the public key needs to be fetched first.
Acceptance Criteria
- Unit tests
- E2E tests, e.g. using IC-Ref, See example in agent-rs.
- Documentation
- PR to Agents section on internetcomputer.org
References
I found the Ruby agent.
I will tell you where it is if you give me collaborator status.
Hey @icwizardmonke,
we are aware of the Ruby agent (https://github.com/dfinity/awesome-internet-computer#ruby). There's no way to collaborate on a GitHub issue.
Okay last time we spoke you didn't know where Ruby agent is
I saw a Dfinity tweet mention the Ruby Agent but had no link.
I replied asking for link. No response.
I replied again explaining I had searched the discord and asked you
https://cdn.discordapp.com/attachments/1056016593261445122/1126168858600943626/Screenshot_2023-07-05-08-12-26-254.jpg
No response.
On the relevant page, here in repo, there is no link to the Ruby Agent.
I could have simply added it through pull request.
Instead we have wasted time discussing here.
If I am unable to be commit code and gain Contributor status, why would I participate in project?
Edit: I just got caught up in the Discord. I see external contributions will be allowed soon. Thank you.
I came across the repo for the Ruby agent only after our discussion, and I couldn't find our discussion anymore, because I just have too many Discord chats (I tried). Hence, I only added it to https://github.com/dfinity/awesome-internet-computer (btw this repo accepts external contributions).
As mentioned in my first comment, Github doesn't allow PRs/contributions to issues.
@icwizardmonke FYI, this repo should be ready to accept external contributions now.
We are open to supporting work on existing agent implementations if features are missing, and we might support additional implementations for languages/frameworks that already exist if there is a good reason for this.
Are you open to supporting work on new agent implementations in programming languages that don't have them? E. g. Haskell.
Hi @gromakovsky,
yes, we are! The main ones we'd be interested in are a swift agent and driving the C++ for multiplatform Unreal Engine Development.
Edit: If you are only interested in Haskell, I think the more interesting project would be a Haskel Canister Development Kit.