Adding Outbound support information to provider Offer

[golmek]

User Story: As a Requestor I would like to know beforehand that a provider is not supporting outbound

Potential solution: Extending Offer to convey information about outbound support.

[cryptobench]

As a requestor I would like to know before investing all of my time into this platform whether or not my usecase fits the platform. If I need outbound networking, then I should be able to browse the stats page for example to see which providers has outbound enabled/disabled. The stats page should parse this from the offer template of the providers on the network.

The reason for this is to increase the UX of our requestors by having all of this information available UPFRONT to actually starting their work vs having them to invest a lot of time into the platform to then be able to know if the provider supports it or not.

I find this particular topic essential for outbound 2.0 to be a success

[evik42]

The reason for this is to increase the UX of our requestors by having all of this information available UPFRONT to actually starting their work vs having them to invest a lot of time into the platform to then be able to know if the provider supports it or not.

This feels counter intuitive because it takes into consideration only the current state of the market. For example now there are not really any requests that would require outbound so it would not have an effect if everyone turns it off. When demand is present on the market it should balance with the available providers and their offerings, meaning that if large amount of requests are coming in that require outbound, providers will be present who will take those tasks to get better monetization for their providers.

I felt that your analogy comparing developing for golem to using a library does not fit well as golem is a marketplace where demand can drive the availability of providers.

Not to mention that this is not a new thing, a provider can empty the whitelist and remove the certificate from the keystore and essentially disable outbound right now.

[cryptobench]

I think there's a misunderstanding. This is not about any current state of the market, instead it's about the UX of being a requestor on the network.

If I am going to invest my time and money into using Golem instead of a cloud provider like AWS, then I expect the experience to be seamless and provide me the information required upfront prior to actually investing my time into the platform.

I want to know what the platform can offer me.

I want to avoid this bad user experience like we already have when it comes to getting to know the performance of individual providers CPU, memory and disk ... there's no sane person who is going to spend their own money on benchmarking a network just to know if the platform is a fit for them or not.

In the same case there's no sane person who will invest their time into a platform to perform a check just to see if there's any providers available in the network that actually has outbound networking enabled.

There's also no people who is going to pay just to create some reputation system to keep track of good or bad providers.

• [ ] My point is, if we actually want some requestors in the network then we really really gotta double down on the user experience and not force everyone to conduct the test themselves. There's no point in 100 different requestors creating and spending their own money on a solution that should be globally available to everyone which will benefit everyone. If we continue this practice then golem will never get any requestors.

[evik42]

I see your point and I think the difference is how we think about providers.

I understand that you expect golem providers backed by dedicated hardware that can reliably run a workload on the long term with predictable performance.

Based on the restrictions I encountered when developing core components, I expect providers that sell the extra resources on a computer while that system is being used. Based on the current actions of the user of that system, the performance of the provider can change drastically even during a tasks and the change might be temporary or longer term. So I think that Golem and AWS (or any other commercial cloud provider) are not in the same league and cannot be really compared.

I think it would be great to have a clearer picture about what kind of providers we expect / assume and work with a shared understanding.

[nieznanysprawiciel]

I want to avoid this bad user experience like we already have when it comes to getting to know the performance of individual providers CPU, memory and disk ... there's no sane person who is going to spend their own money on benchmarking a network just to know if the platform is a fit for them or not.

That's why we need services around Golem that will provide this information for Requestors. As I understand, you need a service where you can take a quick look to find out if there are any Providers having required resources. You don't want exact numbers, you want to know in general if market is big enough to invest time in using platform.

Having this information in Offer doesn't solve to much. You can have Providers that accept only whitelist or have specific rules set. This single flag could be misleading, because after negotiation it could turn out that you can't use outbound anyway. To make this property useful, we would need to include much more information, otherwise it is only optimization that will allow Requestor to filter Providers that don't support outbound at all.

And id you are running some kind of aggregation service, you can run more complicated checks on Providers, so you can find out what you can really expect in the network.

[cryptobench]

My main issue is that with more and more features being added to Golem, it seems that we keep adding more complexity for our requestors to just get started. I think we drastically need to think about the UX if we ever want any requestors on this network. Right now the investment of time is huge just to get started with Golem.

Requestors already need to do the following for a production app:

• Build their own blacklisting mechanism for bad providers

• Build their own market strategy to properly select providers with certain pricing

• Figure out how to install a SSH client in your requestor and use something like the Yapapi socketProxy to enable SSH access into the provider to help with debugging

• Figure out some way of monitoring the providers VM resources (CPU, Memory and Disk) - which is an important thing to have available in case that something starts running in some odd way. If I can take a quick look and see that CPU is peaking at 100% then I know , okay it needs more resources. Where as if I don't have this info available, then I have to start looking into this black box.

• Now if i'm in need of network access on the task, then I need to first create my task and everything and then get hit by this random error where networking doesn't work or it doesn't pick up on any provider. The requestor would probably first look into the terminal running the actual script, but that doesn't inform them about the provider doesn't have outbound enabled or whatever the error message might be.

• If you're looking for a HA setup of requestors , then you can't use the same wallet to pay for tasks so you must implement some kind of mainnet faucet service for your own requestors. You probably would also like to have some kind of private key recovery incorporated in case the requestor crashes and you want to extract the funds from the newly funded wallet.

• I also don't know the network speed of requestors, so if my app runs slow on Golem but not locally then I need to scratch my head wondering what the issue is. If this was also advertised in the offers, then I would have some sort of idea if the provider is just slow or not.

@nieznanysprawiciel If i understand your message correctly, then you mention something about services on top of Golem who will do this - but I don't think that anyone will do this. Who would want to spend money on machines to just get some information thats expected to be available before buying a "product" somewhere? I don't buy a pair of shoes in hopes that it fits me , but instead I buy a pair of shoes because i know the size fits me.

[nieznanysprawiciel]

These are all valid issues. The problem with the things you mentioned earlier (benchmarks, network speed etc) is, that you would like to implement them on wrong layer. Network speed given by Provider is not so useful, because the real speed depends on latency between Nodes, so it would be rather misleading for Requestor. Benchmarks ran by Provider are problematic, because you measure performance in special moment, not in normal usage, when Provider can do many other things on his computer at the same time. Random sampling performance by external service would give more reliable results. Other thing is that different tasks need different characteristics of benchmark.

Here the problem could be similar, that this single property could be misleading, because Provider can reject Proposals anyway, when he has specific rules settings.

We need a service collecting and aggregating these data anyway. And on the beginning we will need to facilitate this, we can't count that someone will do this himself. Maybe when the network will grow larger, then someone might be willing to create such a service, either out of need or because he found a way to monetize it.

Other thing here, I think you are assuming that we are targeting anonymous Requestors in the wild. I rather think that in current stage of development we are aiming mainly to cooperate directly with some chosen companies, to understand better Requestors needs and collect knowledge how to improve the network. And I don't think, inability to check what resources are available in the network is the biggest blocker to larger adoption.

That's said, I think it would be useful to collect knowledge, how Providers are configuring their Nodes. Maybe we could implement something like this as experimental feature:

"golem.activity.!exp.outbound" : {
    "open": "unrestricted|whitelist",
    "audited-payload": "unrestricted|whitelist",
    "partnership-certificates": "unrestricted|whitelist"
}