For Service Consumers: Software Development Kit

The Osiris Software Development Kit (SDK) generates client-side libraries to seamlessly call Osiris services and interact with the Osiris platform as a whole.

While either the DApp or CLI is suitable for launching a small number of services, heavy and frequent production use of services on Osiris will be easier and faster through specialized client libraries generated via the SDK.

A generated client library should require only a funded wallet. It will be able to open and fund channels on behalf of the user with the multiparty escrow contract, generate well-formed requests to services, and correctly parse their responses, just like client libraries for traditional SaaS platforms.

The initial version of the SDK supports Python, currently the most popular language for machine learning and AI and a common language for glue code. In the near future, we will also provide versions in other popular languages, such as Go, Javascript, and Java.

The list of supported programming languages can be expanded at any time. Client libraries leverage the gRPC framework, so support for the programming languages targeted by gRPC “protoc” compiler is the straightforward initial step. Eventually, other languages could be supported; this would require plugins for the gRPC protoc compiler, either written by the Osiris Foundation or the open-source community.

As well as making service calls using gRPC, client libraries must be able to interact with Binance, IPFS, and other components of Osiris. This can be achieved with separate code for each language, or by wrapping generic libraries (for example in C or C++). For languages or operations that still are not supported, documentation will be provided to help developers integrate Osiris with their platforms.

A client library in a compiled language would generate calls for each service in the library and include additional helper functions to handle interactions with Binance, IPFS, the daemon, the MPE contract, and state channels. For example, a client library would interrogate the daemon at compile time for the encoding used by a specific service and generate method calls that would appropriately marshal requests and unmarshal responses. A client library would also store the list of channel IDs so that it does not have to rely solely on those provided by the Foundation or its partner in a transaction (which might fail, or act in an adversarial way) for such information. The developer would then integrate these libraries in their application code.

For interpreted languages like JavaScript or Python, two different options can be supported: both libraries can be generated at compile time for specific services, or more generic libraries could be used; they would download a service’s protobuf specification (or load it from local storage), compile client libraries for that service at runtime (or leverage a cached, pre-compiled client), and dynamically generate service calls. The latter design is used in the DApp, CLI, and beta version of the SDK.

At the moment, the main focus of the SDK is generating client libraries and making service calls. In the future, it will be expanded to incorporate other interactions currently handled by the CLI. For example, a user should be able to use SDKs written in different programming languages to list services on the Registry; change a service’s metadata; and gather and aggregate data, logs, and metrics from different daemons for different services that user controls. This would allow AI services to generate and register new services automatically, and it would enable artificial intelligence to deploy agents.