We’re excited to announce that we’re creating a number of bounties to celebrate the Beta 2 release. The Golem Network offers an unstoppable, inexpensive and censorship-free environment. These bounty projects are taking in mind what’s awesome about the 2nd major release from a development perspective, such as the Services API and the possibility to create custom runtimes.

Further technical information, and a SDK, can be found here. The bounty submissions will be aggregated to our awesome-golem directory and social media, and in the future, potentially featured in a website section. If you’re considering participating in the bounties, please also read the section at the end of this blog.

And the 3 bounties are!

(Please click on the bounty headers for the link to go to the Gitcoin bounty)

PostgreSQL runtime

Since Beta.2 Golem offers developers a possibility to create custom runtimes that can be installed by providers to extend their computational capabilities and offer new kinds of services in the Golem Network we want to create a bounty to incentivize this. The goal of this project is to develop a new, self-contained runtime exposing PostgreSQL database. The runtime would serve as a wrapper around an actual PostgreSQL service running on a provider machine. By installing the runtime, providers would be enabled to offer a PostgreSQL database as a service on Golem Network.

Requirements

• The runtime should be compatible with yagna v0.7.1.
• The runtime should run on at least one of the following operating systems:
  - Ubuntu,
  - Windows,
  - macOS.
• Starting an activity on the runtime should output all connection parameters necessary to use the database (address, port, database name, user name, password).
• Connection parameters mentioned above should enable the user a PostgreSQL database running on the provider node.

Non-requirements

• The runtime doesn't have to include PostgreSQL service. It is meant to be a wrapper.
• The runtime is not supposed to facilitate the communication between the service and its end-user.
• The runtime is not required to perform any network configuration. It can be assumed that the provider machine running the runtime has a public IP address and appropriate ports are open.

Deliverables

• A GitHub repository with the following:
  - The runtime code (a Rust crate),
  - A testing script allowing to check if the runtime works as intended,
  - Basic usage instructions,
  - GPL license.
• A video recording demonstrating the usage of the runtime.

Resources

• ya-runtime-sdk – SDK for implementing runtimes.

Estimated time to allocate: 24 hours

Interactive image classifier

Since Beta.2 Golem supports a new model of computation – services. In contrast with batch tasks such as what developers were initially limited to in the Beta.1, services are expected to be long-running processes that don't have any natural completion point but rather are started and stopped on explicit command. The goal of this project is to build a service on Golem which enables interaction with an image classifier. The service is expected to allow its users to train the classifier on-line as well as submit images for classification. Details of the classification algorithm are not specified and can be decided by the implementer of the project.

Requirements

• The service should be compatible with yagna v0.7.1.
• Starting the service should deploy an interactive image classifier ready to be used.
  - The classifier should be pre-trained for image recognition so that it can be used without excessive further training.
• The service should respond to two kinds of requests:
  - "train on provided data" – includes an image and a label (or a batch of images with labels), no output expected;
  - "classify an image" – includes an image, expected to output a label.
• The classifier should have a decent accuracy when trained on sufficient amount of data.

Non-requirements

• The implementer doesn't have to build the model from scratch. Using publicly available pre-trained models is allowed.
• The classifier doesn't have to allow multi-label classification, single-label is enough.
• No scalability is required, the implementer might put reasonable constraints on image size.
• No graphical user interface is required (although it is welcome).
• No direct communication between the user and the provider is required. It is assumed that all communication with the service will be mediated by the requestor application.

Deliverables

• A GitHub repository with the following:
  - The service code,
  - A testing script (with training set) allowing to check if the service works as intended,
  - Basic usage instructions,
  - GPL license.
• A video recording demonstrating the usage of the service.

Resources

• Service Model development – an extensive tutorial on Golem services.
• yapapi-service-manager – a high-level Python library for developing services.

Estimated time to allocate: 48 hours

Full-text search engine

Since Beta.2 Golem supports a new model of computation – services. In contrast with batch tasks, services are expected to be long-running processes that don't have any natural completion point but rather are started and stopped on explicit command. The goal of this project is to build a full-text search service on Golem. The service would allow its users to perform search queries over a corpus of documents submitted by the requestor during deployment.

Requirements

• The service should be compatible with yagna v0.7.1.
• Requestor is expected to provide a set of plain-text documents to be indexed during service startup.
• Once the indexing is done, the service is expected to respond to search queries.
  - Query input could be any arbitrary string to be found in the corpus.
  - Query output should include a list of all occurrences of the searched string in the corpus, i.e.: filename, line, and position.

Non-requirements

• The implementer doesn't have to build the search engine from scratch. Using existing full-text search libraries is allowed.
• The service is not expected to apply any advanced search techniques such as boolean queries, wildcards, fuzzy search, etc.
• No scalability is required, the implementer might put reasonable constraints on corpus size and query size.
• No graphical user interface is required (although it is welcome).
• No direct communication between the user and the provider is required. It is assumed that all communication with the service will be mediated by the requestor application.

Deliverables

• A GitHub repository with the following:
  - The service code,
  - A testing script allowing to check if the service works as intended,
  - Basic usage instructions,
  - GPL license.
• A video recording demonstrating the usage of the service.

Resources

• Service Model development – an extensive tutorial on Golem services.
• yapapi-service-manager – a high-level Python library for developing services.

Estimated time to allocate: 24 hours

Things you will need to know when participating

Time

We include an estimated time however this isn’t a deadline, it’s to indicate the estimate we’ve come up with on the total amount of time that a developer would be reasonably looking to allocate in the vicinity of for the project and this estimated time is what the reward is based on. It doesn’t factor in for developers that might already be familiar with Golem. So if you’ve built on Golem before and you’re particularly familiar with what goes into each project then you might spend less time, that’s great!

For each bounty, we will open 1 slot (first come, first serve). Your working repository must be public the entire time of working for us to be able to judge the progress and whether we might eventually need to open a new slot. We will judge this based on whether we determine if the project looks like it will or won’t be completed in a reasonable timeframe. This will also give other potential candidates an indication on whether they will be able to complete their own project in a faster time, should a new slot be open. You can still complete your work and submit in the case that a new slot is opened. We reserve the right to open a new slot in cases we see fit, particularly extended inactivity and if there is no response from the participant in an attempt to reach out.

Legal

Any disputes arising out of or in connection with these bounties shall be exclusively decided by the ordinary courts of the city of Zug, Switzerland and in accordance to Swiss law.

Note

Make sure to read our privacy policy.

If you have any questions - please join us on discord or comment on the Reddit thread. We are very excited to host this set of bounties, we've included lots of love, work to prepare them and adjusted to the improvements offered in Golem's latest major release. We are looking forward to your participation!