reorg + added FFI table
This commit is contained in:
@@ -1,11 +1,8 @@
|
||||
{
|
||||
"development-status": "Development Status",
|
||||
"importing": "Importing",
|
||||
"modules": "Modules",
|
||||
"examples": "Basic Examples",
|
||||
"message-helpers": "Message Helpers",
|
||||
"message-types": "Message Types",
|
||||
"troubleshooting": "Troubleshooting",
|
||||
"development-status": "Development Status",
|
||||
"mixnet": "Mixnet Module",
|
||||
"tcpproxy": "TcpProxy Module",
|
||||
"ffi": "FFI",
|
||||
"tutorials": "Tutorials (Coming Soon)"
|
||||
}
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
# Development status
|
||||
The SDK is still somewhat a work in progress: interfaces are fairly stable but still may change in subsequent releases.
|
||||
|
||||
In the future the SDK will be made up of several components, each of which will allow developers to interact with different parts of Nym infrastructure.
|
||||
In the future the SDK will be made up of several modules, each of which will allow developers to interact with different parts of Nym infrastructure.
|
||||
|
||||
| Component | Functionality | Released |
|
||||
| Module | Functionality | Released |
|
||||
|-----------|---------------------------------------------------------------------------------------|----------|
|
||||
| Mixnet | Create / load clients & keypairs, subscribe to Mixnet events, send & receive messages | ✔️ |
|
||||
| Ecash | Create & verify Ecash credentials | 🛠️ |
|
||||
| TcpProxy | Utilise the TcpProxyClient and TcpProxyServer abstractions for streaming | ✔️ |
|
||||
| Ecash | Create & verify Ecash credentials | 🛠️ |
|
||||
| Validator | Sign & broadcast Nyx blockchain transactions, query the blockchain | ❌ |
|
||||
|
||||
The `mixnet` component currently exposes the logic of two clients: the [websocket client]() TODO LINK, and the [socks]() TODO client.
|
||||
The `Mixnet` module currently exposes the logic of two clients: the [websocket client]() TODO LINK, and the [socks]() TODO client.
|
||||
|
||||
The `ecash` component is currently being worked on. Right now it exposes logic allowing for the creation of Ecash credentials on the Sandbox testnet.
|
||||
The `TcpProxy` module exposes functionality to set up client/server instances that expose a localhost TcpSocket to read/write to.
|
||||
|
||||
The `Ecash` module is in progress. Right now it exposes logic allowing for the creation of zk-nym credentials on the Sandbox testnet.
|
||||
|
||||
@@ -8,44 +8,42 @@ import { Callout } from 'nextra/components'
|
||||
|
||||
We currently have FFI bindings for Go and C/C++. See the table below to check the coverage of functionality we expect devs would like to see.
|
||||
|
||||
The `sdk/ffi` directory has the following structure:
|
||||
|
||||
```
|
||||
ffi
|
||||
├── cpp
|
||||
├── go
|
||||
├── README.md
|
||||
└── shared
|
||||
```
|
||||
|
||||
The main functionality of exposed functions will be imported from `sdk/ffi/shared` into `sdk/ffi/<LANGUAGE>` in order to cut down on code duplication, and so that the imported bindings can be language-specific with regards to types and any `unsafe` code that is required, as well as allowing for the use of language-specific FFI libraries in the future (e.g. we are using `uniffi-bindgen-go` for Go, and at the moment have custom C/C++ bindings, which we might in the future replace with `cxx`).
|
||||
|
||||
### Mixnet Module
|
||||
This is the basic mixnet component of the SDK, exposing client functionality with which people can build custom interfaces with the Mixnet.
|
||||
This is the basic mixnet component of the SDK, exposing client functionality with which people can build custom interfaces with the Mixnet. These functions are exposed to both Go and C/C++ via the `sdk/ffi/shared/` crate.
|
||||
|
||||
| Rust Function | Go | C/C++ |
|
||||
| :----------------------------------------------- | :--: | ----: |
|
||||
| `MixnetClient::connect_new()` | ✔️ | ✔️ |
|
||||
| `MixnetClientBuilder::new_with_default_storage` | ✔️ | ✔️ |
|
||||
| `MixnetClientBuilder::OTHERS` | | |
|
||||
| `MixnetClientBuilder::OTHERS` | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| `shared/lib.rs` function | Rust Function |
|
||||
| ------------------------------------------------------------- | ----------------------------------------------------------------------- |
|
||||
| `init_ephemeral_internal()` | `MixnetClient::connect_new()` |
|
||||
| `init_default_storage_internal(config_dir: PathBuf)` | `MixnetClientBuilder::new_with_default_storage(config_dir)` |
|
||||
| `get_self_address_internal()` | `MixnetClient.nym_address()` |
|
||||
| `send_message_internal(recipient: Recipient, message: &str)` | `MixnetClient.send_plain_message(recipient, message)` |
|
||||
| `reply_internal(recipient: AnonymousSenderTag, message: &str)`| `MixnetClient.send_reply(recipient, message)` |
|
||||
|
||||
|
||||
> We have also implemented `listen_for_incoming()` which is a wrapper around the Mixnet client's `wait_for_messages()` which is exposed to Go and C/C++. This is a helper method for listening out for and handling incoming messages.
|
||||
> We have also implemented `listen_for_incoming_internal()` which is a wrapper around the Mixnet client's `wait_for_messages()`. This is a helper method for listening out for and handling incoming messages.
|
||||
|
||||
### TcpProxy Module
|
||||
A connection abstraction TODO LINK which exposes a local TCP socket which developers are able to interact with basically as expected, being able to read/write to/from a bytestream, without really having to take into account the workings of the Mixnet/Sphinx/the message-based TODO LINK format of the underlying client.
|
||||
A connection abstraction which exposes a local TCP socket which developers are able to interact with basically as expected, being able to read/write to/from a bytestream, without really having to take into account the workings of the Mixnet/Sphinx/the [message-based](../concepts/messages) format of the underlying client.
|
||||
|
||||
| Rust Function | Go | C/C++ |
|
||||
| :----------------- | :--: | ----: |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
> At the time of writing this functionality is **only** exposed to Go. C/C++ bindings will follow in the future in a larger update to the C FFI.
|
||||
|
||||
|
||||
----------------
|
||||
for copypaste
|
||||
❌ ✔️
|
||||
----------------
|
||||
| `shared/lib.rs` function | Rust Function |
|
||||
| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
|
||||
| `proxy_client_new_internal(server_address: Recipient, listen_address: &str, listen_port: &str, close_timeout: u64, env: Option<String>)`| `NymProxyClient::new(server_address, listen_address, listen_port, close_timeout, env)`|
|
||||
| `proxy_client_new_defaults_internal(server_address, env)` | `NymProxyClient::new_with_defaults(server_address, env)` |
|
||||
| `proxy_client_run_internal()` | `NymProxyClient.run()` |
|
||||
| `proxy_server_new_internal(upstream_address: &str, config_dir: &str, env: Option<String>)` | `NymProxyServer::new(upstream_address, config_dir, env)` |
|
||||
| `proxy_server_run_internal()` | `NymProxyServer.run_with_shutdown()` |
|
||||
| `proxy_server_address_internal()` | `NymProxyServer.nym_address()` |
|
||||
|
||||
@@ -1,11 +1,5 @@
|
||||
# Installation
|
||||
The `nym-sdk` crate is **not yet available via [crates.io](https://crates.io)**. As such, in order to import the crate you must specify the Nym monorepo in your `Cargo.toml` file:
|
||||
|
||||
```toml
|
||||
nym-sdk = { git = "https://github.com/nymtech/nym" }
|
||||
```
|
||||
|
||||
By default the above command will import the current `HEAD` of the default branch, which in our case is `develop`. Assuming instead you wish to pull in another branch (e.g. `master` or a particular release) you can specify this like so:
|
||||
The `nym-sdk` crate is **not yet available via [crates.io](https://crates.io)**. As such, in order to import the crate you must specify the Nym monorepo in your `Cargo.toml` file. Since the `HEAD` of `master` is always the most recent release, we recommend developers use that for their imports, unless they have a reason to pull in a specific historic version of the code.
|
||||
|
||||
```toml
|
||||
# importing HEAD of master branch
|
||||
@@ -14,10 +8,4 @@ nym-sdk = { git = "https://github.com/nymtech/nym", branch = "master" }
|
||||
nym-sdk = { git = "https://github.com/nymtech/nym", branch = "release/2023.3-kinder" }
|
||||
```
|
||||
|
||||
You can also define a particular git commit to use as your import like so:
|
||||
|
||||
```toml
|
||||
nym-sdk = { git = "https://github.com/nymtech/nym", rev = "85a7ec9f02ca8262d47eebb6c3b19d832341b55d" }
|
||||
```
|
||||
|
||||
Since the `HEAD` of `master` is always the most recent release, we recommend developers use that for their imports, unless they have a reason to pull in a specific historic version of the code.
|
||||
Work will occur in the future to break the monorepo down into importable features, in order to reduce the number of dependencies imported by developers.
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
import { Callout } from 'nextra/components'
|
||||
|
||||
# Mixnet Module
|
||||
|
||||
This module exposes the logic of creating and interacting with clients and Mixnet messages. This is recommended for those wanting to either start playing around with the Mixnet and how it works, or build connection logic.
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
|
||||
For developers wanting something more 'plug and play' we recommend the [`TcpProxy` module](./tcpproxy).
|
||||
|
||||
</Callout>
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"examples": "Basic Examples",
|
||||
"message-helpers": "Message Helpers",
|
||||
"message-types": "Message Types",
|
||||
"troubleshooting": "Troubleshooting"
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
# TcpProxy Module
|
||||
Reference in New Issue
Block a user