concepts overview for devporta

2024-09-30 18:13:43 +02:00
parent 859e8aecf8
commit b577fd7a29
8 changed files with 100 additions and 3 deletions
@@ -0,0 +1,31 @@
+{
+  "index": {
+    "display": "hidden"
+  },
+  "network": {
+    "title": "Network",
+    "type": "page"
+  },
+  "developers": {
+    "title": "Developers",
+    "type": "page"
+  },
+  "sdk": {
+    "title": "SDKs",
+    "type": "menu",
+    "items": {
+      "rust": {
+        "title": "Rust SDK",
+        "href": "/sdk/rust"
+      },
+      "typescript": {
+        "title": "Typescript SDK",
+        "href": "/sdk/typescript"
+      }
+    }
+  },
+  "operators": {
+    "title": "Operators",
+    "type": "page"
+  }
+}
@@ -1 +1,5 @@
-stub
+# Core Concepts
+
+We are working on making the Mixnet as easy as possible to use; that said, it is at the moment still quite an unusual system in terms of how it works and the required parts.
+
+We are working on abstractions to emulate more traditional networking such as reading from / writing to TCP sockets, and have plans to modify the internals of the clients to remove some of the required architecture and slim down the parts required to use the Mixnet.
@@ -1,5 +1,6 @@
 {
  "required-architecture": "Required Architecture",
  "messages": "Message Based Paradigm",
+  "message-queue": "Message Queue",
  "abstractions": "Connection Abstractions"
 }
@@ -0,0 +1,2 @@
+
+2) actually waiting on messages: `send()` **just puts the message in the queue of cover traffic** so dropping a client before its actually sent is something that is possible and should be avoided (see the troubleshooting example TODO LINK) for more on this.
@@ -1 +1,3 @@
 stub
+
+1) working on messages not streaming / bytes which can be a pain : check the use of the bytecodec logic in the tcpproxy for looking @ how we handle this there
@@ -0,0 +1,6 @@
+- what do i need? clients on both sides
+  - take a traditional client / server app setup: we need to put the mixnet betwen them to get the privacy properties, and each of them need a client in order to connect and authenticate with the mixnet to send and receive messages: since a lot of the functionality happens client-side and the sphinx of it all
+
+- what dont i need? to run your own infra
+  - you can basically use the mixnet as a black box
+  - maybe if you're expecting a load of traffic / dont want to rely on other people's gateways, you could run your own and then connect to them specifically (qu: can we configure the client to connect to a particular gateway?)
@@ -1,7 +1,7 @@
 # Introduction
-Nym's developer documentation covering core concepts of integrating a Nym client, an overvie of the avaliable tools, and our SDK docs.
+Nym's developer documentation covering core concepts of integrating with the Mixnet, interacting with the Nyx blockchain, an overview of the avaliable tools, and our SDK docs.

 ## Where to Start?
 If you are completely new to Nym, it is suggested to start with the top sections covering the core concepts, integration options, and the clients and tools available to you.

-If you feel like starting with more practical examples, check out the SDK docs.
+If you feel like starting with more practical examples, check out the relevent SDK docs in the sidebar to the left.
@@ -0,0 +1,51 @@
+import { Callout } from 'nextra/components'
+
+# FFI Bindings
+
+<Callout type="info" emoji="ℹ️">
+  We are only working on the intitial versions of the FFI code to allow developers to experiment and get feedback. Please get in touch if you think the FFI bindings are lacking certain functionality.
+</Callout>
+
+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.
+
+### Mixnet Module
+This is the basic mixnet component of the SDK, exposing client functionality with which people can build custom interfaces with the Mixnet.
+
+| Rust Function                                    | Go   | C/C++ |
+| :----------------------------------------------- | :--: | ----: |
+| `MixnetClient::connect_new()`                    |  ✔️   |  ✔️  |
+| `MixnetClientBuilder::new_with_default_storage`  |  ✔️   |  ✔️  |
+| `MixnetClientBuilder::OTHERS`  | | |
+| `MixnetClientBuilder::OTHERS`  | | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
+
+
+> 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.
+
+### 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.
+
+| Rust Function      | Go   | C/C++ |
+| :----------------- | :--: | ----: |
+|                    |      |       |
+|                    |      |       |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
+
+
+----------------
+for copypaste
+  ❌  ✔️
+----------------
				`@@ -0,0 +1,2 @@`

				2) actually waiting on messages: `send()` just puts the message in the queue of cover traffic so dropping a client before its actually sent is something that is possible and should be avoided (see the troubleshooting example TODO LINK) for more on this.