The Osiris Registry

The Osiris Registry is an BSC-165–compliant14 smart contract on the Binance blockchain that stores organizations, services, and type repositories. AI developers use the Registry to announce details of their services, and consumers use the Registry to find the services they need. When a user searches for a service in the Marketplace DApp, the DApp reads details of the services from the Registry. The Registry also allows tagging of services and type repositories to enable searching and filtering.

The Registry stores four main pieces of data: organizations, services, type repositories, and tags. It supports creation, removal, editing, and reading for all of these, and contains several view functions for retrieving data.

An organization is an umbrella for services to be grouped under and is at the top of the Registry’s data hierarchy. Service developers can (and should) register an organization and then put all of their services underneath it. An organization registration record has a name, an owner address (in the identity sense), a collection of member addresses, a collection of services, and a collection of type repositories.

Services and type repositories registered under a given organization are said to be owned by that organization. The list of members is a primitive access-management structure; members of an organization can do everything except change the organization owner and delete the organization.

A service represents a single AI service. Its Registry entry contains all the necessary information for a consumer to call that AI service. The entry contains a name, tags, and IPFS hash. The name is an identifier for discoverability, the tags help a customer find a service without knowing its name, and the IPFS hash is the link to the metadata file on IPFS. DApps and smart contracts can use the listServicesForTag view function to discover services.

All service metadata is stored off-chain in IPFS for performance and gas-cost reasons. This metadata includes

● basic information such as version number, service name, description, etc.;

● code-level information for calling the service, such as encoding (protobuf or JSON) and request format (gRPC, JSON-RPC or process);

● A list of daemon endpoints, aggregated into one or more groups;

● pricing information; and

● an IPFS hash for the service API model.

The CLI provides a convenient API and library for manipulating this metadata.

A type repository is a Registry entry where a service developer lists service metadata, such as the service model and the data types used. The entry contains a name, some tags, a path, and a URI. The name and tags are for discoverability, the path is an optional identifier for the organization’s internal management, and the URI allows the client (whether an end user or an application making calls through the Osiris SDK) to find the metadata. DApps and smart contracts can use the listTypeRepositoriesForTag view function to discover AI services. The URI is an IPFS hash, and the hosting itself can be done by either Osiris, the service developer, or any IPFS pinning service, such as Infura.

Tags are completely optional but recommended for discoverability. Registry functions allow tags to be added to services and to type repositories. After that, the tags are displayed and searchable on the DApp. Thanks to a reverse index built into the Registry contract, other smart contracts can also search the Registry directly. This is the foundation for the “API of APIs” functionality discussed below.

The Registry provides all the information needed to find and interact with AI services on the platform, either by listing the information in full or, when it is too long, by listing the IPFS hash. The Marketplace DApp is a convenient interface for end users, and anyone can use the information in the Registry to build similar marketplaces.