v3.2.0-beta.2

3.2.0-beta.2 (2024-08-02)

Bug Fixes

• exe-unit: fixed RemoteProcess.isFinished termination detection, no assumed timeout in waitFor (d5d16e2)
• fixed TcpProxy implementation so that it works with non-http use-cases as well (8aabace)

v3.2.0-beta.1

3.2.0-beta.1 (2024-08-01)

Bug Fixes

• market: exposed memoryGib and storageGib from ScannedOffer, deprecating old methods (c3682bd)

Features

• market: add GPU support properties and payment platform addresses (56dd575)
• market: added offerId to ScannedOffer (9416359)

v3.1.1-beta.1

3.1.1-beta.1 (2024-07-31)

Bug Fixes

• fixed the issue blocking GolemNetwork.disconnecte because of missing gftp (50633ef)

v3.1.0

3.1.0 (2024-07-18)

Bug Fixes

• add missing conditional export for browsers (2776386)
• fix draft offer pool locking by using acquire queue (a0d4bda)
• fix rentals not being taken from the pool if acquire is stuck creating a new one (64cdf97)
• fixed retrying errors during fetching activity results (7c4ba84)
• job: fix jobs stopping immediately after starting (a1da9d1)
• job: fixed aborting work in exe-unit in Job (cc48eed)
• job: fixed rental finalization after job completed (22856f1)
• jobs: fixed the issue with agreements getting terminated before job work is executed (f62a9f2)
• resource-rental: fixed error handling when creating an exe-unit (70fa746)
• separate yagna-api related logs to a child namespace for readability (dfd6241)
• use the correct types file for experimental exports (6edd190)

Features

• added RemoteProcess.isFinished to allow tracking when streaming was completed (4989850)

v3.1.0-beta.3

3.1.0-beta.3 (2024-07-18)

Bug Fixes

• fixed retrying errors during fetching activity results (7c4ba84)

v3.1.0-beta.2

3.1.0-beta.2 (2024-07-17)

Bug Fixes

• jobs: fixed the issue with agreements getting terminated before job work is executed (f62a9f2)

v3.1.0-beta.1

3.1.0-beta.1 (2024-07-17)

Bug Fixes

• fix draft offer pool locking by using acquire queue (a0d4bda)
• fix rentals not being taken from the pool if acquire is stuck creating a new one (64cdf97)
• job: fix jobs stopping immediately after starting (a1da9d1)
• job: fixed aborting work in exe-unit in Job (cc48eed)
• job: fixed rental finalization after job completed (22856f1)
• resource-rental: fixed error handling when creating an exe-unit (70fa746)
• separate yagna-api related logs to a child namespace for readability (dfd6241)

Features

• added RemoteProcess.isFinished to allow tracking when streaming was completed (4989850)

v3.0.2-beta.1

3.0.2-beta.1 (2024-07-09)

Bug Fixes

• add missing conditional export for browsers (2776386)
• use the correct types file for experimental exports (6edd190)

v3.0.1

3.0.1 (2024-07-08)

Bug Fixes

• market: proposals are now estimated with 1h duration by default (11823b7)

v3.0.0

3.0.0 (2024-07-01)

Features

For the list of currently supported features, check the Feature Guide.

Introduced GolemNetwork root module

We know that our users love the single entry-point approach used by golem-js. In the absence of TaskExecutor which is removed in this release, we stick to the approach by exposing you to the GolemNetwork class which now will be your starting point in all of your interactions with golem-js.

It's a high-level abstraction over the SDK that is designed to navigate you through other concepts in a fluent way.

That's achieved by:

• providing oneOf, and manyOf methods that help you to rent resources from Providers on the Golem Network and utilize common usage patterns
• exposing configured and operational core modules if you want to access the lower-level APIs and implement advanced usage patterns

// Create a new instance (yagna URL default will be used, YAGNA_APPKEY env
// variable will be inspected for application key
const glm = new GolemNetwork();

// Establish the connection to your yagna node
await glm.connect();

// Rent out resources from a single Provider
const rental = await glm.oneOf({ order });

// Rent out resources from many Providers (n = poolSize)
const rentalPool = await glm.manyOf({ poolSize, order });

// Access core module that's fully configured (ADVACED USE)
glm.market.buildDemandDetails(/* ... */)

// Cleanly close the connection
await glm.disconnect();

Introduced modular design and exposed it to developers

The domain of Golem Network could be easily sliced into a few distinct subdomains. Take for example:

• Market - where we browse and negotiate offers with providers and reach final agreements
• Activity - where we execute various processes related to running workloads using the rented resources
• Payment - where we accept debit notes during the activities or accept invoices for the resources used

In the previous version of the SDK, these areas were not accessible to the users. Well, technically they were, if someone got around TaskExecutor, but that was something that we were discouraging.

With this release, we made such modules our first-class citizens, and we opened access to them so that more advanced and knowledgeable users can implement their sophisticated use cases.

Feel invited to explore the glm.market, glm.activity, glm.payment, glm.rental, glm.network properties to access these modules directly once you connect GolemNetwork in your codebase.

Introduced ResourceRental and ExeUnit models

With this release golem-js leans towards the original whitepaper of Golem Network which pictures it as an ecosystem where Requestors rent out computation resources from Providers. This specific viewpoint became the central theme for the SDK and the 3.0 release.

The APIs are no longer oriented around sending tasks to a group of providers whose resources were hired to run computation jobs. We soared to a higher altitude where we provided a model of resource rental that aggregates various bits of information from the Golem Network Protocol to make them usable and accessible for Requestors. A dedicated exe unit abstraction has been provided to allow quick access to the execution environment hosted on the rented resources.

The following snippet shows a working example of placing an order, obtaining a single resource rental object, and accessing the exe-unit to run a command using these resources.

import { MarketOrderSpec, GolemNetwork } from "@golem-sdk/golem-js";

const order: MarketOrderSpec = {
  demand: {
    workload: { imageTag: "golem/alpine:latest" },
  },
  market: {
    rentHours: 5 / 60,
    pricing: {
      model: "linear",
      maxStartPrice: 0.5,
      maxCpuPerHourPrice: 1.0,
      maxEnvPerHourPrice: 0.5,
    },
  },
};

(async () => {
  const glm = new GolemNetwork();

  try {
    await glm.connect();
    
    const rental = await glm.oneOf({ order });
    
    await rental
      .getExeUnit()
      .then((exe) => exe.run("echo Hello, Golem! 👋"))
      .then((res) => console.log(res.stdout));
    
    await rental.stopAndFinalize();
  } catch (err) {
    console.error("Failed to run the example", err);
  } finally {
    await glm.disconnect();
  }
})().catch(console.error);

Introduced budget estimation with linear and burn-rate pricing models

When specifying your pricing requirements for the rental in the market parameter of the market specification, you specify the expected rental duration and the pricing parameters. Previously the SDK assumed that you would use the linear pricing model, which required 3 parameters: START, ENV/sec, and CPU/sec prices.

From version 3.0 you can also use a new scheme called burn-rate, and provide a single pricing parameter: avgGlmPerHour that will be used to filter the market offers and also estimate your budget.

const order: MarketOrderSpec = {
  demand: {
    workload: { imageTag: "golem/alpine:latest" },
  },
  market: {
    rentHours: 0.5,
    pricing: {
      model: "burn-rate",
      avgGlmPerHour: 1.5,
    },
  },
};

NOTE ABOUT burn-rate model

The burn-rate pricing model is not part of the Golem Network Protocol. This solution is specific to the golem-js library and was designed to simplify the pricing for Requestors. The SDK deals with aligning this model with the linear pricing model on the level of the Golem Network Protocol.

The previously implicit linear model is still available in 3.0, but it has to be configured explicitly and with 3 price parameters which are now defined in units per hour instead of per second.

We changed the unit to make the UX more consistent when someone's looking at the prices displayed on the Golem Stats Page and then tries to configure the SDK with these pricing parameters.

const order: MarketOrderSpec = {
  demand: {
    workload: { imageTag: "golem/alpine:latest" },
  },
  market: {
    rentHours: 0.5,
    pricing: {
      model: "linear",
      maxStartPrice: 0.5,
      maxCpuPerHourPrice: 1.0,
      maxEnvPerHourPrice: 0.5,
    },
  },
};

With version 3.0 it's no longer possible to manually set the budget as a config parameter. If you wish to control the overall budget necessary, you can create a fixed-size allocation and instruct the SDK to use that pre-created allocation.

Introduced VPN support

With this release, you can access the GolemNetwork.network module and create a VPN that can be used to provide connectivity between different providers that you interact with, opening the way for building workflows that require direct communication between these providers.

// ✨ Create the network
const network = await glm.createNetwork({ ip: "192.168.7.0/24" });

const order: MarketOrderSpec = {
  demand: {
    // as usual
  },
  market: {
    // as usual
  },
  // ✨✨ Pass the network as part of the market order specification
  network,
};

const pool = await glm.manyOf({
  poolSize: 2,
  order,
});

const rental1 = await pool.acquire();
const rental2 = await pool.acquire();

const exe1 = await rental1.getExeUnit();
const exe2 = await rental2.getExeUnit();

await exe1
  .run(`ping ${exe2.getIp()} -c 4`)
  .then((res) =>
    console.log(
      `Response from provider: ${exe1.provider.name} (ip: ${exe1.getIp()})`,
      res.stdout,
    ),
  );

await exe2
  .run(`ping ${exe1.getIp()} -c 4`)
  .then((res) =>
    console.log(
      `Response from provider: ${exe2.provider.name} (ip: ${exe2.getIp()})`,
      res.stdout,
    ),
  );

Introduced passive market scan functionality

Both Providers and Requestors are interested in the offers and prices for computation resources available on the Golem Network. Doing a market scan was possible with the previous versions, but required deeper knowledge of the SDK from the users.

With this release we leverage the new feature of yagna 0.15.2 which is the passive market scan. Researching the market just has been simplified for all who's interested.

Added support for re-using externally created allocations

With the previous SDK, the GLM allocation used to settle payments was internally manged by the SDK. While this is still the case in 3.0, you can now configure GolemNetwork or oneOf/manyOf to make use of an existing allocation. In such case, the SDK won't be creating new allocations and just continue using the one that you provided.

Introduced direct GVMI upload from Provider to Requestor

With this release, Golem Virtual Machine Images that you want to deploy on the Providers can be directly served from your Requestor machine to the provider. This removes the need for using Golem Registry to store your images before they are downloaded by the Provider. Another step towards decentralisation in Golem Network.

Introduced new Event API

In the previous version of the SDK when you wanted to listen to certain events, you had to utilize the EventTarget class which was not really that convenient for developers. With this release, we moved to EventEmitter3, and now you can access the events from the SDK in a more developer-friendly way:

glm.market.events.on("agreementApproved", ({ agreement }) => {
  console.log(
    "Agreement '%s' approved",
    agreement.id
  );
});

Exposing Observables

Where applicable, methods exposed by the SDK modules can now return rxjs Observables for situations where multiple values can be returned over time. The SDK also makes use of rxjs internally.

Fixes

1. **Fixed the iss...