A key objective in SDK Development is the interoperability that becomes a natural design of the XPX-Chain-SDK. This guideline will show how to collaborate creating a XPX-Chain-SDK, achieving the best quality with the less effort.
Learning about Sirius Chain
In case you haven’t used XPX-Chain-SDK or Sirius Chain in general, you need to do the following:
- Review the technical documentation to become familiar with the Sirius Chain built-in features.
- Setup the Sirius Chain in local environment via docker or enroll the beta program to access a Sirius Chain Test Net without the need to run it yourself.
- Check the API reference and play with the API endpoints.
- Become familiar with the current xpx-chain-sdk via code examples & xpx-chain-cli .
GO sdk uses crypto library to sign transactions and utils to simplify usage of some commands. The structure of SDK is not defined, but you can find implementation of all transactions, websockets and notifications, examples transaction's usage and sdk's API.
The SDKs you create does not require this separate implementation.
Regularly check the releases to be sure you didn’t miss any code change update.
- Be sure no one is already working on the SDK you want to create. Check the repository list, if someone is already working on it, we suggest you collaborate with that person.
- Claim the SDK forking this repository and adding a new entry to the repository list.
- Consider using one of the suggested licenses.
Creating the project
- Add a README with the instructions to install the SDK.
- Add a Code of Conduct.
- Add a Contributors guidelines to help others know how they can help you.
- Setup the Continuous Integration system. We use travis-ci, but feel free to use the one suits you best.
A project with good test coverage is more likely to be used and trusted by the developers.
The API generation can be done with Swagger Codegen. It supports multiple languages. Hopefully, yours in the list.
The API swagger file definition can be found here.
Java example. The code generated by swagger are the
List of interfaces:
Check the HTTP implementations in case you doubt about some API endpoint.
The repositories return Models instead of DTOs. You will need to code the Models before finishing the API wrapper.
The models are by default immutable. The models aim to hide the complexity, like type conversion or relationship between objects.
You will find in the different implementations different invariants to ensure the object is well constructed.
Particular decisions to consider:
uint64use that implementation. Otherwise, adapt the
UInt64.tsimplementation to your language.
- API conversions: The API returns the data sometimes compressed, you might need to convert that types for the user.
- Mosaics & Namespaces IDs: The namespaces and mosaics are not strings any more compared to NIS1. As you can see in the class, the
stringname is optional. At creation time you add the string name, but when you receive the Namespace/Mosaic from the network, it comes in formatted as
uint64ID. A specific endpoint returns the Namespace/Mosaic
stringname. We created a service to return the Mosaic with the
stringname automatically for the user, check the implementation here (only available in TypeScript SDK version).
A Transaction needs a particular serialization schema in binary optimized in size. The transaction serialization has multiple steps to keep easy to create transactions and maintain the schema serialization.
Generating the buffer classes: The easy part
- Install the flatbuffers tool, you might need to compile it. Use version 1.7.1 or newer.
- Compile the schema for your language. Download the flatbuffers files here.
- Move the generated files to your
model/transactionSDK folder. Example.
Creating the Schema class: The difficult part
- Create the Schema class.
- Create the SchemaAttribute class.
- Create the ScalarAttribute class.
- Create the ArrayAttribute class.
- Create the TableAttribute class.
- Create the TableArrayAttribute class.
- Constants class.
Creating the Transaction Schemas
Each transaction has a Schema. It has the same type as
flatbuffer schemas but using the
Schema class. It is used to know where each component is located in the
flatbuffer schema and remove the unnecessary bytes to create the optimised serialization.
Using the Schemas in the Transaction Models
The Transaction class has the abstract method generateBytes(). Each Transaction has to implement and use the previous classes, the Buffers and the Schemas, to serialize the transaction.
Do not forget about Cosignatory classes, it has to be done too.
KeyPair and Cryptographic functions
This section is incomplete.
Documenting your SDK
SDKs need to be adopted by other developers. As a contributor, no one knows better than you how a determined SDK works. Provide the content for its documentation to help spread the use of your SDK. the following documentation.
Publishing the SDK as official
When you open-source your code, submit the repository to this page.
To become an accepted SDK, it should be proposed as a NIP. The reason behind the XPX Improvement Proposal is to ensure that the new libraries are reviewed, tested and shared among Sirius Chain developers.)
The current guideline shows what is done up to the time of writing since all the SDK are not complete. It will get updates according to the latest architecture/features.
- MIT: Expat/MIT/X11 license
- Apache-2.0: Apache License, version 2.0
- BSD-2-Clause: OSI-approved BSD 2-clause license
- BSD-3-Clause: OSI-approved BSD 3-clause license
- CC0-1.0: Creative Commons CC0 1.0 Universal
- GNU-All-Permissive: GNU All-Permissive License
- LGPL-2.1+: GNU Lesser General Public License (LGPL), version 2.1 or newer