They gave multiple opportunities for people to ask their question in person. The meeting was extended by thirty minutes to help answer additional questions. Not all questions could be answered in that amount of time.
i lodged my questions very early on. I am in a completely different timezone to Storj or do you expect me to stay up until 4am to participate? I ALSO DONāT HAVE A TWITTER ACCOUNT.
Storj was selective as to the questions they answered.
The first time I participated in one of these events I was told I lodged my questions too late - get them in early and they will be answered. This time I indeed logged them early - I am second on this thread - and still didnāt get them answered. I am left with the conclusion it is a waste of time asking as Storj doesnāt want to answer.
These were covered, although the answer to 2 kind of tied in with the answer to 1 and wasnāt discussed as a separate issue.
Iām guessing they arenāt to worried about this at the moment as they decided to slowly reduce payouts over the course of the year which will give a better idea of how reduced payouts effect the network overall.
Yeah and they also say donāt buy any hardware. I wouldnāt read to much into it.
This Iām actually curious about too but itās not really all that important. Iām sure someone could probably answer it here though.
I donāt really think this is a fair question. Nobodyās forcing anyone to to run test nodes. Itās a choice anyone can make for themselves if they want to do more to help the project. I only just found out there is still a test network and am now considering running a test node. Of course if payouts drop so low for regular nodes that itās no longer worth doing, I will of course be dissapointed and just shut everything down and thatāll be the end of it.
Hi All, Thank you to all of you who have submitted questions and participated in the twitter space yesterday. Here are some responses to the major questions we have received. I am sure we are not covering everything that has been asked but hopefully this answers most of the items that have been discussed.
Q. Why the focus on SNO costs? What other things are we considering to reduce costs beyond just SNO Payouts?
When thinking about our costs it is important to understand that there are two main buckets of costs within the company, COGS (cost of goods sold) which are expenses directly related to the delivery of the product. In our case these are things like SNO payouts, the cost to run the metadata database, the salaries for Dev Ops people, and the gateway infrastructure. Then there is OPEX, which is other expenses such as R&D, Sales, Marketing, Finance, Travel etc. Right now our OPEX is much larger than COGS since most of the employee salaries fall into this category, including most of the engineering team since the majority of what they do is R&D not Dev Ops. This means that if you look at our token report SNO payouts look small relative to other expenses because we pay most peopleās salaries with STORJ. But the goal for all start ups is to first get to gross margin profitable which means that revenues minus COGS is a positive number. Once you have that then you can increase volume and scale to overall profitability in time. Right now we are not gross margin profitable. And the biggest driver of that is SNO payouts which are 66% of our total COGS. In addition our costs and revenues are such that if we eliminated all other COGS we still wouldnāt be gross margin profitable. So we know that we must change SNO costs for the business to be viable
That being said there are many other things also in flight to reduce the other costs buckets within COGS and many of these have been brought up by the community
Reed Solomon code scheme changes
This is a very high value target, but it has significant implications throughout the service (ex. impacts edge bandwidth usage, longtail cancellation, average piece size, compute required for client, repair bandwidth usage, overall performance, overall durability). Also,(other than the SNO costs based on expansion factor) it is otherwise not broken and there is a large amount of downstream work in terms of engineering effort, QA, documentation and tooling that needs to be changed if we change it. This means it is a large and risky effort, as it could impact data durability and we want to be very thoughtful and intentional about it. So while we are looking into it, it will be a slow careful process before we roll anything out.
Free tier adjustments
The free tier is currently growing but customers donāt seem to be using it to transition to paid customers as we had hoped. Because of this we do anticipate changing the structure of the free tier both to improve our costs and to better support our efforts to grow revenue
Incentivizing gateway ST or native integration
We already work with customers to utilize native integrations where appropriate. The dominant integration pattern for cloud storage is S3. We start with the gateway and then help customers get greater value from the larger integration effort for native. Native makes sense where throughput is important, where there is sufficient compute and bandwidth to be successful. We have Web2 (Univ. Edinburgh, GBLabs, Comet Backup, Rclone) and Web3 (Ankr, Pocket, Harmony) using native integrations. We canāt force it. It has to fit the use case.
Reducing our infrastructure costs further
Our other costs such as our metadata database as well as the Gateway infrastructure are things that we are constantly looking to improve. We know that we are sub-scale on many of these resources and so as we go per TB costs will improve, but there are also code changes and other implementation changes we can make to improve costs and these are all in flight.
Q. Have we considered raising prices, or charging fees for value added features and services?
We have explored raising prices for premium services, typically through partners like Ankr(chainsnap.io), GB Labs or private label partners, but we havenāt seen sufficient market pull for our current pricing to justify a general increase at this point. Growth is good and steady and we donāt want to add any friction at this point
We are evaluating several options in packaging and pricing, including
Reducing the free tier or transitioning from a free tier to a free trial
Conversions from free tier have not yielded sufficient benefit to justify the expense
We have also considered splitting some services to a paid tier only, or as a value added service, for example
Linkshare service
CustomTLS for Linkshare
Edge Services
Enterprise support
Q. What is the time frame for making changes to SNO payouts?
Weāve tried to be clear that we want to avoid a shock to the system or a dramatic drop in node payouts. From a rough timeline perspective, our goal is to get to unit profitability by the end of the year.
What SNOs can expect is the following
As customer usage increases, we will reduce test data from the network at a rate that matches the rate of growth
This started last year and will continue until the test data no longer represents a subsidy, but is restricted to what is needed to validate product capabilities and for QA
We will reduce the payout amount slowly throughout the course of this year
While weāre reducing SNO costs, weāre also working equally hard on the other COGS to ensure that we hit our end of year objective
As we make changes, we want this dialog to stay open.
We may find more opportunities where we can offer higher price points and better returns for SNOs
Weāll continue to find a balance that works for both SNOs and Storj
Q. We have an oversupply of storage and not enough customer data. What are STORJās plans to find new customers? Who are these customers? Who are these customers? What do they currently use? What advantages can STORJ offer them? What does STORJ do to convince them to switch?
It might help to share the general approach we take to sales and marketing, which is not dissimilar to what you might find in any disruptive startup.
We have a marketing team that is very focused on the target customer and target use cases. The largest areas for rapid growth are in higher egress use cases for existing customers of hyperscale providers. The marketing team drives leads to the sales team and provides assets and touchpoints to help nurture leads into sales opportunities.
We have increased the size of the sales team by 4x over the last year. This team is responsible for leveraging the leads generated by marketing as well as identifying prospective customers and converting them to paying customers.
Weāve started with early adopters and have many referenceable customers. They are growing in number and size. Early adopters tend to be small and innovative disruptors. They help you move up market to SMB (Small and Medium Businesses) and those SMB references allow you to break into the enterprise market.
Other things that end to help include third party validations from tech media, analysts and external reports published by partners and customers.
Who have an exceptionally high customer NPS. Many of our customers and partners are now participating in our webinars and joint presentations a t conferences.
Ex. Livepeer and Storj workshop at ETH Denver
Iconik and Storj presentation at IBC
In addition we are also working to make the creation and operation of community satellites more accessible and hope that over time other individuals or organizations beyond Storj Labs will be able to drive demand to the network
Q. Since changes have huge economic impact on SNOās will Storj also review or remove restrictions currently in place including IP /24 rule & the Vetting period
RESPONSE:
There are a few points to address in this question
Vetting period - Weāre already horizontally scaling audit workers to address the vetting period
IP /24 rule
This restriction is in place to help preserve the distributed footprint of the data stored on the network. It is really about how data centers co-exist in the network with individual contributors. Data centers already participate but adding a lot of capacity isnāt advantageous as all nodes tend to fill at similar rates. We are looking at how data centers can participate in the network without introducing a category of node that can disproportionately outcompete individual operators.
Q. Where are with compliance / certifications
We are working on our SOC2 certification and are more mature in terms of the less complex frameworks such as HIPAA and GDPR
Have listened to the Twitter, and I think we should acknowledge that the guys did a good Job with a difficult topic to cover - Iām not sure who thought that was a good idea, but well done anyway - sometimes announcements are better when all the information is available, but youāve opened the can of worms now.
My favourite bit, probable lost in translation is that SNOās are referred to as āSNOWā, made me smile anyway - had to listen a few times, as thought I had it wrong.
In the early days when they were working on the web version of the node dashboard it was often refered to as the SNOboard. Iād still love to have an app for the multimode dashboard we could then call the SNOmobile. I mean the name is right there!
Iāll change my browser bookmark for Node Dashboard in SNOboard . Thanks for sugestion. Fun factā¦ my nick is derived from SNO also . It just took me a few seconds to come up with it.
@Bryanm can we expect other questions, either from here or āthe long topicā, be answered as well? For now Iāll just ask about mine, ones from the post I make this one a reply to. To phrase them anew:
How does Storj Labs envision future network? Is it still mostly small drives of non-technical people? Or maybe is there a plan to have a more formal āyes, we want some people to run multiple nodes on a dedicated (at least drives) hardwareā?
Why am I asking? Cause as a somewhat technical person, I would want to expand my setup to both make my earnings higher (to stay profitable) and make sure the network grows and stays healthy. If thereās going to be a clear voice āwe want you!ā, then Iāll be fine with buying a 16+ TB drives to run my nodes on, as well as plugging in a UPS.
iām lucky enough that my power is so stable that i can avoid having a UPS, instead iāve focused on having hardware/software support so that data will not get corrupted in case of a random power outage.
tho i understand that some will need to use UPS in their setup to ensure reliability.
PLP is a nice inventionā¦ help me mostly deal with that and ZFS does the rest.
i donāt think single node operators have any good chance to compete with multinode operatorsā¦ its simply a matter of basic mathā¦ multinode operators have much more time to learn and optimize their setup, something which would never be viable for single node operators.
UPS takes away most worries. Even after the batteries wear out a bit, I can just set the shutdown to be immediate on power loss (communicated via USB). Most of the time itās also a surge protection, so my main hardware can be re-plugged afterwards without the need to buy a new power supply.
But this is getting offtopicā¦
Iād still love to have an app for the multimode dashboard we could then call the SNOmobile. I mean the name is right there!
. It just took me a few seconds to come up with it.