36 lines
1.7 KiB
Plaintext
36 lines
1.7 KiB
Plaintext
# Message-based Paradigm
|
|
|
|
For the moment, Mixnet clients work assuming they will have atomic messages given to them to packetise, encrypt, and send through the Mixnet looking something like this:
|
|
|
|
```
|
|
MixnetMessage {
|
|
Message: Message_Bytes,
|
|
To: Nym_Address,
|
|
Attached_SURBS: Number_Of_Surbs
|
|
}
|
|
```
|
|
|
|
Likewise, they assume that once they have received and decrypted a Sphinx packet, reconstruct messages with a structure something like this:
|
|
|
|
```
|
|
ReconstructedMessage {
|
|
Message: Message_Bytes,
|
|
From: SURB_Sender_Tag
|
|
}
|
|
```
|
|
|
|
Examples for:
|
|
- [Standalone Websocket Client]() TODO LINKS ON ALL
|
|
- [Rust SDK Client]()
|
|
- [TS SDK Client]()
|
|
|
|
This is obviously quite different to e.g. simply being able to read/write from a stream returned from a function call to create a TCP connection, but there are several approaches that developers can take to dealing with this right now.
|
|
|
|
_We are planning future developments to make a more developer-friendly interface for our clients, but this will not be released before early/mid 2025_.
|
|
|
|
## Message Abstractions
|
|
- Rust/Go/C++ developers can use the `TcpProxy` [stream abstraction](./abstractions).
|
|
- Developers who are using Typescript/Javascript can also avoid having to deal directly with messages via using [MixFetch]() TODO LINK...
|
|
- ... As can developers who are bundling and running the standalone [socks5 client]() using some form of init script.
|
|
- There will be a seperate pair of binaries coming soon which other developers can use to run as a persistent secondary proxy process based on the [zcash gRPC demo]() codebase, built using the `TcpProxy` abstraction. These will simply expose a `localhost` socket port to pipe traffic to and from in the same way as you would a TCP connection.
|