Name: Mateusz
OS+lang+version (if applicable):
Title: app-key create missing from the import key part of tutorial
!!! attach blender-yapapi.log, zipped data-dir !!!

    the scenario -> 
    1. not purged directory
    2. import key section: [https://golem-network.gitbook.io/golem-sdk-develop/payments/using-golem-on-mainnet#restoring-your-backed-up-golem-wallet](https://golem-network.gitbook.io/golem-sdk-develop/payments/using-golem-on-mainnet#restoring-your-backed-up-golem-wallet)

    (no mention about the need to create a new app-key)

    3. install new yagna (without purging dir): https://handbook.golem.network/requestor-tutorials/flash-tutorial-of-requestor-development

    4. seems my yagna app-key create requestor doesn't do anything as it 

the first one (the default in the newest ya-runtime-dbg) launches the shell

and the latter uses system execve call

the main difference is that the shell has some environment set and e.g. doesn't require full paths to executables

the exeunit uses exec mode so there's an important difference in that the command that run correctly in the shell, will fail in exec mode - and will fail when run on an actual provider

blue - macos mojave - the double-line instruction to purge the dir somehow didn't work for me even though I definitely put "yes" as the answer there...

Add a comment in Dockerfile in "Golem Hello World" above the line COPY worker.py /golem/entrypoint/ mentioning that during development it might be better to upload the code in runtime rather than bake it in the image

reported by @shadeofblue

• mainly simplified payment flow

needs adding in mainnet handbook

yagna payment status --network mainnet

yagna payment status --driver erc20

yagna payment status --network mainnet --driver erc20

https://golem-network.gitbook.io/golem-sdk-develop/payments/using-golem-on-mainnet#enable-the-mainnet-account

Expected behaviour

If there's a typo or some addition I would want to add to the docs, considering its GitBook, I would like to see an "Edit in GitHub" button enabled at the top of a page so I could send a PR with the documentation.

Current behaviour

There's no "Edit in GitHub" button at the page I'm looking to edit and instead had to go to the Golem Factory GitHub manually. It is not really an issue for developers, but for non-technical people that aren't aware of GitBook <> GitHub it could take a few minutes to bridge the gap, and we could miss their help with typos.

Steps to replicate

• Go to any page in the docs.
• Identify a typo or a suggestion to change.
• Realize that you don't know how to quickly do that and weep a bit.

Suggested changes

In your GitBook documentation, under "Integrations", you can enable the "Display Edit Button" under the settings for the space of this particular repository.

Remove solution described in https://handbook.golem.network/troubleshooting/common-issues#io-error-no-such-file-or-directory from the docs (unless you find a reason to keep it – then fix the command to return 0 exit code so that ctx.run() does not raise an exception).

requires: golemfactory/golem-js#170
requires: #33

Write an overview article explaining the service model (including state diagram and logic of transitions).

See here: https://app.gitbook.com/@golem-network/s/golem-sdk-develop/requestor-tutorials/service-development/how-does-it-work-dive-into-requestor-agent-service-model/@drafts

add documentation for goth to handbook:

• introduction to goth
• interactive mode tutorial based on @zakaprov 's video

include instructions on how to prepare a Docker image for Golem in the "convert Docker image" article

or maybe create a subsection of the handbook that discusses preparation of VM images

It is no longer an issue:
golemfactory/yagna#1354

But the troubleshooting section is still here:
https://golem-network.gitbook.io/golem-sdk-develop/troubleshooting/common-issues#multiprocessing-python-library-not-working-on-providers

(as above)

Golem overview intro

the image at the beginning of "Golem Overview" might benefit from adding a "Custom runtime" to the right-hand part of the graph to ensure that readers understand that the payloads are not limited to just VM and WASM but that they can be virtually anything...

https://app.gitbook.com/@golem-network/s/golem-sdk-develop/introduction/golem-overview

or maybe there should be a suggestion that it's an open list (like having an empty container with three dots in it?)

Provider vs services

https://app.gitbook.com/@golem-network/s/golem-sdk-develop/introduction/provider

We might want to show that it's not always "input->processing->output->payment" but rather that it may also be something more services-related ... like "deploy-> .... run service .... -> payment (in set intervals?)" ...

for some reason, we have lost the content of the "writing your own market strategy" page...

https://github.com/golemfactory/yagna-docs/blob/c7e6ee29c9ae907775126c11df066cc94f8d38a7/requestor-tutorials/writing-your-own-providers-market-strategy.md

Gert-Jan - Mainnet requestor handbook import guide needs hint about note

add docs that introduce zksync to Golem users

reported by @maaktweluit

$ read -e -p "Backed up keys? (type "yes"): " YN && [[ $YN == "yes" ]] && rm -rf $HOME/Library/Application\ Support/GolemFactory.yagna
read: -p: no coprocess

2rec - handbook amendment request: add a tip when to import id (with mainnet funds). Two ppl from within Golem misunderstand our notion page, so it will help us internally at least, and I belive it will not hurt community readers, as they may also want to do this.

https://www.notion.so/golemnetwork/Developer-experience-gunicorn-on-provider-e5f7c037768147d7a7619903e2a57018#8b3f180625404f4cb49535f0f5d9142b

As implemented in golemfactory/yapapi#561

(excerpt from the yacat tutorial)...

On the provider side, all the content of the VOLUME directories is stored in the provider's os file system.
All the changes in other (non VOLUME mounted) container directories content are kept in RAM. The rest of the VM image file system (not changed, non VOLUME mounted) content is stored as VM image in the provider's os file system.

Please mind that tasks within a single worker instance - so effectively part of the same activity on a given provider node - run within the same virtual machine and share the contents of a VOLUME between each other.
That means that as long as the execution takes place on the same provider, and thus, on the same filesystem, files in the VOLUME left over from one task execution will be present in a subsequent run.

If your provider-side code creates large temporary files, you should store them in the directory defined as VOLUME. Otherwise, the large files will be stored in RAM. RAM usually has a capacity limit much lower than disk space.

Gert-Jan - All OS-es - pip3 and python3 are not needed in handbook AFTER venv is loaded...

Doc over on Discord pointed out that it might be smart to let testers know that their machines user must belong to the docker group before the gvmkit-build command will work. It might save users some time troubleshooting in the future.

Name: blue
handbook

https://handbook.golem.network/payments/using-golem-on-mainnet#restoring-your-backed-up-golem-wallet
we should probably link the appropriate provider/requestor installation docs there

Name: GJ

yagna versions (and link) in the gitbook are not changing automatically (and maybe they could: https://app.gitbook.com/@golem-network/s/golem-sdk-develop/requestor-tutorials/flash-tutorial-of-requestor-development#running-the-yagna-daemon )

Costanza — Yesterday at 6:17 PM

Hi! I was going through the SDK and I saw that here there might be a missing link (or so it seems to me )
https://handbook.golem.network/introduction/requestor
Requestor
The requestor actor in the Golem

"For instance, you could think of training a large ML model in seconds instead of hours, there are many interesting business use cases described in the:"

Add a comment in Dockerfile in "Golem Hello World" above the line with FROM python:3.8.7-slim mentioning that slim image is used to avoid having providers download lots of data but for development using a non-slim version might be more useful

requires: golemfactory/yapapi#330

possibly, we could provide two tutorials:

• one on just utilizing the HL Services API with our VM-based exe-units (essentially, port the toy service to the HL Services API], which could be more familiar to those who have had some experience with yagna app development already
• and the more high-priority one, utilizing the provider-end service wrapper and running Turbogeth

the video: https://www.youtube.com/watch?v=gWRqu7IvYfk

Currently yapapi receives image_hash and assumes this image is hosted on the central server.

Alternative approach would be to provide a full image URL (or maybe image_hash + base url).

The main purpose is to allow users with large images (e.g. Galatea project) to host them somewhere from where they would be downloaded faster. Also the "central golem image repo" was intended as a temporary solution (I'm not 100% sure abot this?).

NOTE: this should be included in the handbook.