Implications of farmer selection and benchmarking on billing

[MeijeSibbel]

Currently it is not attractive to use Storj mainly because it offers nothing that other well known reputable storage companies already provide, Storj does not have a established reputation, its expensive for consumers and even industry, transfers are slow, the network is unreliable and there is a single point of failure of the Storj service.

As explained in detail in SIP-006 farmer benchmarking and selection based on different performance/reliability metrics (bandwidth, geographical location, uptime, timeout-rate...) is the way forward not only to make Storj more efficient but also to allow Storj Labs to target different audiences/landscapes within the Storage industry.

In order for Storj to survive it will have to specialize from the current uniform and on average low quality storage cloud to attract specific clients that are after a specific performance quality or metric of the Storj network.

This implies creating performance profiles renters can adjust after registering to app.storj.io, and adjacent billing for that specific user selected profile. These profiles are dynamically priced based on prices of other Storage competitors.

An example of the implementation:

• Renters create a storage profile of their choice on app.storj.io, then exports a settings file with the parameters that can be imported into say Libstorj or FileZilla, farmers will be automatically selected based on the parameters in the config file.
• Farmer creates a storage profile, the bridge remembers the profile linked to a specific account and only selects farmers that satisfy this profile, independently where users login, as long as they use the specific account.

[MeijeSibbel]

One that i messed was a retrievability (frequent - infrequent) scale, Another option for this would be three tier price approach. Backup, Normal and High

[RichardLitt]

See #67.