Files
nym/documentation/docs/pages/developers/concepts/messages.mdx
T
2024-10-09 11:30:38 +02:00

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.