The Skynet SDKs

Skynet SDKs — Developer Tools

One of our goals with Skynet is to make it as easy as possible for developers to create useful applications. We already have a powerful HTTP API documented here. Though this API can be called from your language and networking library of choice, it is not very convenient to do so.

That’s why we set out to create SDKs that let you quickly start playing with Skynet right from your favorite language. We currently have SDK support for several languages.

• Browser JS
• Node JS
• Python
• Go

We also are in the process of building a simple-to-use Skynet CLI for command-line scripts, written in Go and built on top of the Go SDK.

The SDKs are extensively documented in the Skynet Docs, complete with copy-paste-able code examples for each language. Language can be selected using the tabs in the upper right area of the docs.

Using Skynet SDKs

Let’s go through a quick example to familiarize ourselves with these SDKs. In this example, we’ll be using skynet-js, the Javascript SDK for the browser.

One of the most common use cases for Skynet is uploading files for reliable and decentralized storage. Let’s see how we’d do that using the library:

In all our examples, the first thing we do is create a client. The client by default will use the current portal that our app is running from, but you can pass a different portal when initializing it.

Notice that the upload returns a Skylink. We can use this to download the file from Skynet when we need it:

Now let’s try sending custom options in the request. For example, let’s say we’re using a portal which requires authentication, and that we need to send the API password. We simply need to include an object with the APIKey option with our upload call:

You can also use the uploadDirectory function to -- you guessed it -- upload directories. This example is a bit more complicated because we have to first extract the name of the directory from the given files, and construct a map of files indexed by their filepaths, before calling uploadDirectory:

Now, let’s say you uploaded a directory with the following structure:

dir1
| — file1
| — file1
| — dir2
 | — file3

You’ll get back a single skylink that can be used to access any of the files within the uploaded directory, using the paths of the files. The three files in the example can be accessed as follows:

...portal.../...skylink.../file1
...portal.../...skylink.../file2
...portal.../...skylink.../dir2/file3

Accessing one of the two directories…

...portal.../...skylink...
...portal.../...skylink.../dir2

will download it as a .zip archive (by default) containing the directory contents.

To wrap up, let’s look at how we would download file3 given that we uploaded dir1.

Technical Challenges

The main challenge involved in writing these SDKs was producing code that was idiomatic for each language — that is following good style, best practices, and using the proper libraries — while also keeping the SDKs similar to each other. Naturally, we didn’t want the SDKs to diverge from each other too much so as to maintain consistency and avoid any confusion. However, some differences still emerged, so watch out for them as you read the docs. We tried to call out the discrepancies as explicitly as possible.

How you can contribute

We’re looking for contributions for all four of the SDKs. Though the SDKs are already quite functional, there are many different options and endpoints that are still not supported. We maintain a map here of what’s implemented and what’s still missing for every SDK.

In every SDK we’ve put the infrastructure in place to make it as easy to contribute as possible. Notably, we’ve created stubs for all the missing endpoint functions. A stub is a function with its signature already in place, so all that needs to be done is to follow existing examples and fill it out. We also made the custom options easy to extend.

Automated test suites complete with working CI (continuous integration) are ready to go for all four SDKs. This makes it easy to contribute without worrying about breaking any existing code. We do ask that any new features come with corresponding tests. The existing tests can be used as templates. The tests should make sure that all new functions and options result in correctly-formed requests to Skynet. We don’t make any actual connections to Skynet in the tests — we use mocking libraries to intercept the network requests and to examine that they are correctly formed.

For example, here is a simple test in Browser JS using jest (for testing and mocking) and axios (a request library):

As you can see, this test mocks axios using jest and sets up an intercept for axios.post. Then it does some simple setup -- note that directory is a map of files indexed by their paths. Then it calls uploadDirectory, and finally checks that axios was called with the correct URL in the request.

Conclusion

We hope this crash course through the SDKs got you excited to use them. We only covered the surface of what you can do with these APIs! There’s a lot more waiting to be discovered and we can’t wait for you to give developing on Skynet a try. You would be reaping the benefits of a powerful decentralized and censorship-resistant platform, from the language of your choice!

The Skynet SDKs was originally published in Sia Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.