SMIFT Protocol 0.2 - Alessandro-Salerno/SMIFT GitHub Wiki

The SMIFT Protocol, or SMIFTP for short, is a set of rules used by clients and servers to communicate on a SMIFT Network. The SMIFT Protocol defines the type and structure of messages, alongside timings, accepted values and other technical details.

History

Development on SMIFTP 0.2 started on August 30th, 2024. This version builds on SMIFTP 0.1 and introduces special features to facilitate the operation of wholsale foreign exchange markets over SMIFT.

NOTE: This version has not been finalised yet.

Technology

Messages in this version of the SMIFT Protocol are sent via TCP through an unsecured channel.

Encoding

Messages in this version of the SMIFT Protocol use UTF-8 encoding and are zero-terminated. Lines are terminated by the CRLF sequence.

Glossary

Certain terms used in this page may be ambiguous. When reading, keep in mind this table:

Term	Meaning
Server	Minecraft/Game Server
SMIFT Routing Server	The server software acting as SMIFT middleman
Transaction	Any SMIFT operation that needs to be forwarded to a third node, such as a transfer or message
Node	Programme used by Minecraft/Game server owners to interact with SMIFT
Client	Node that is requesting a service, such as a transfer

Message sequence

SMIFTP is a fully asynchronous protocol. Exchanges generally start with a request from a client and end with a response from another client. The SMIFT Routing Server acts as a middleman between nodes, forwarding messages from one to another. Due to the asynchronous nature of SMIFTP, the Routing Server and clients use the initial request hash, unique transaction ID, and state machines to keep track of requests.

Message format

Messages in SMIFTP 0.2 are comprised of three sections separed by empty lines:

The Header section is a single line stating a version phrase, the message type and additional attributes
The Body section contains important message attributes in a STOMP-like syntax
The optional Payload section contains additional information in JSON format

SMIFT/0.2 <MESSAGE TYPE> <ARGUMENTS>

<KEY>: <VALUE>
...
<KEY>: <VALUE>

[<PAYLOAD>]

The contents exchanged in the Body and Payload sections are detailed in the "Attributes" and "Paylaod" sections for each request, response, and forward. Messages that do not support one or both of these sections lack the dedicated paragraphs in their documentation. NOTE: Some generic attributes are defined in the message types section.

Following is an example of a valid message in SMIFTP 0.2

SMIFT/0.2 RESPONSE 500 Hello world

Property-X: hello
Property-Y: world
Timestamp: 2024-05-12 00:00:00

{ "message": "Hello, world!" }

Data types

Body attributes can have one of several data types:

Type	Description
`INT`	Positive integer
`DECIMAL`	Decimal value
`TEXT`	Text string that contains a maximum of 200 characters. All non-alphanumeric characters are escaped using `\`
`SHORT`	Text string that contains a maximum of 24 characters. All non-alphanumeric characters are escaped using `\`
`SSID`	SMIFT Server Identifier
`SCC`	SMIFT Currency Code
`STID`	SMIFT Transaction Identifier
`SAID`	SMIFT Account Identifier
`SHA256`	UTF-8 representation of SHA256 hash
`TIMESTAMP`	Date and time using the syntax `YEAR-MONTH-DAY HOURS:MINUTES:SECONDS`

Message types

Messages can be one of three types

REQUEST
RESPONSE
FORWARD

Request messages

Requests are initiated by a client looking to communicate with another client and use the following header:

SMIFT/0.2 REQUEST <COMMAND>

Request messages ALWAYS have a Timestamp field in the body. This timestamp is used to store the time and date on which the request was originally generated and is of type TIMESTAMP. This is useful to ensure that message hashes are always different.

The full list of commands can be found in the dedicated section.

Response messages

Response messages are either sent from the Routing Server to a requesting client, or from a handling client to the Routing Server. These messages use the following header:

SMIFT/0.2 RESPONSE <CODE> <PHRASE>

Response messages ALWAYS have a Timestamp field in the body. This timestamp is used to store the time and date on which the response was originally generated and is of type TIMESTAMP. This is useful for deferred responses.

Response codes and phrases can be found in the dedicated section.

Forward messages

Forward messages are used by the SMIFT Routing Server to forward an incoming request to a handler node. Forward messages differ from request messages in commands and body contents, but use a similar header:

SMIFT/0.2 FORWARD <COMMAND>

Forward messages ALWAYS have a Timestamp field in the body. This timestamp is used to store the time and date on which the request was originally generated and is of type TIMESTAMP. This is useful for deferred requests.

The full list of commands can be found in the dedicated section.

Request commands

Request messages can be used to issue the following commands:

Name	Code	Description
Authenticate	`AUTHENTICATE`	Authenticates a newly connected node
Transfer	`TRANSFER`	Issues an order to transfer funds
Cancel transfer	`CANCEL TRANSFER`	Issues an order to cancel an unsettled transfer
Message	`MESSAGE`	Sends a message to another node
FX publish	`FX PUBLISH`	Publishes an offer to the FX Bulletin Board
FX revoke	`FX REVOKE`	Revokes an offer published to the FX Bulletin Board
FX trade	`FX TRADE`	Issues an OTC order to purchase or liquidate currency
FX pull	`FX PULL`	Pulls one page of data from the FX Bulletin Board

Authenticate

This is the first message a client sends to the SMIFT Routing Server after establishing a connection.

Attribute	Type	Description
`Server-Identifier`	`SSID`	Specifies the Game Server's SMIFT Server Identifier
`Password`	`TEXT`	Specifies the user's password

The SMIFT Routing Server can reply with one of the following responses: 200, 300, 301, 302.