There really needs to be more status reporting from the platform

For some reason, my storage drive dismounted on the test system I operate, but I only noticed because I accessed the dashboard around the same time and it was no longer possible to select a satellite from the drop-down list.

As there is data and money at risk the platform really should be better at providing issue notification from both the node(s) and the satellites. I know some people have started to develop ad-hoc solutions to improve monitoring, but it really should be baked into the core code rather than via addons that have their own life cycles.


This is an open source project. Everyone can integrate his ideas into the core code. Everyone can implement addons. You may or may not like that but at the end this is the open source idea to allow it all.

While posting the source code to a public site, with the correct license does make the system open source, it does not help.

Having all the code published is a great way to improve confidence in the project as it allows the system to be checked over by external players, but an average node runner is not going to fork the node code, make changes and then run a recurring cycle of merges as new releases are made. They also have zero ability to make changes to code that affects the way the central systems operate via a personal fork.

Now if you are a highly skilled developer in the right languages and have the ability to write code and modify the container environments storj operates in you could start to contribute/commit to the main project. Such contributors are shown on GitHub and are few in number and the majority work for storj.

Most changes to the storj platform will come from requests being made via these forums and the work being prioritized by storj and if of a high enough priority being carried out by storj staff. A good recent example of this cycle has to be the removal of the estimator page, which on github can be seen here

I am not saying that everyone can do it. I am saying that the same persons that are currently developing third party addons could integrate that into the core project. You specifically asked for that. The problem is that this is not our decision. If they want to continue it as an addon we will respect that decision. If they want to get it into the core repository we are happy to help. If you have any specific addon in mind we could reach out to them and ask.

You haven’t mentioned a specific addon and for that reason, I think your intention was to “force” us, in general. You would like us to watch out for addons and basically steal their ideas. Ofc these are now my words and not yours. Short term that might be good for us but long term we would damage the open-source idea. Let’s ask them first and find a solution that works for both sides.

I am glatt that you have that feeling even if that is not the case. This means that we are selling our ideas in a way that the community believes it would have been their own idea :smiley:

(I would say involving the community into our decisions helps a lot. There is still a lot of work to do for improving the connection even more. The current situation is better but not ideal.)

I get that contributing to the code is not for everyone. I am on the list for a very tiny bugfix I contributed quite a while ago now, but I don’t have the Go skills and time to invest in building larger features either. That doesn’t mean I can’t help in some way. Storj Labs is incredibly open to community input and this shows in several ways.

I would say it’s definitely not most changes. Most originate from backlogs that were generated internally and features Storj Labs came up with themselves. But that doesn’t mean community input doesn’t play a big role as well.

I’ve personally posted 4 suggestions.

In short, Storj is very responsive to these requests. The system works.

Additionally I think showing what we want as a community with third party tools is not a bad thing either. The earnings calculator I built showed the kind of information SNOs would want to see, and I’m betting it’s not a coincidence that the later implemented payouts pages on the dashboard have a suprisingly similar layout and terminology. (I made it no secret that I hoped my earnings calculator in the end would no longer be needed and Storj Labs was free to use any ideas from it)
So that’s another way that these separate initiatives end up making the core product better.

And then there are many less clear ones. Just discussions popping up around specific topics that get picked up and improved. I’ve pointed out specific segments of code for node age calculation, I thought had an issue, which got fixed in the next update. But if you don’t build the code yourself, you do agree that it’s up to Storj Labs to prioritize and implement. And you should also give them the time to do that. They iterate pretty quickly, but you can’t expect fixes to be available within a few days. That’s not how software development works. But generally a few weeks actually has been enough time for them to fix major issues so far.

In general I’m really happy with how this community can contribute even without direct code contributions. I appreciate that Storj Labs is not entirely happy yet and wants to do even better. But if you ask me, they’re already doing a pretty damn good job with this.


You are taking me a bit out of context there. My comment was far more about the number of likely changes being made via direct code contributions to Github vs issues/requests being raised within the forums and storj taking a view on if it makes sense to commit internal resources to develop a solution for the issue/request.

Storj’s own backlog and product enhancement cycle are very different cycles, where they may or may not find overlaps with items raised on this board.

I think we have somewhat different views of what third-party add-ins are going to do for the platform. I personally would not consider handing the lose of the storage disk a task for an add-in or the notification of a node operator that the node is no longer servicing requests from the satellites correctly.

Providing such a solution even after third party solutions have shown up is not “basically steal their idea”, but rather catching up with the backlog of core features that any new software has. A notification/monitoring sub-system is somewhat required to support the terms of the T&Cs that Storj node operators work under and the well being of the whole platform. It’s also something that requires node and satellite integration/deployment, which I am guessing would mean a Storj lead project.

The links provided by Alexey showed that the issue I was raising had been raised in the past and that work on a resolution of sorts is in progress, where a node will at least protect itself from the worst aspects of a lost drive - the DQing of the node within just a few hours. Having a working notification process may just end up in the to be considered queue for another time, or when a larger ‘epic’ type task is raised.

Got it. I didn’t quote you out of context intentionally, I just didn’t realize the context.

I would agree on the first one and luckily that one is already being built into the node software. As for monitoring and notification there are definitely upsides to using external tools. You could incorporate it in already existing dashboards or include stuff from other systems in those dashboards. Additionally the node can’t notify you if it doesn’t have a connection. So using something like uptime robot has the upside of also notifying you when your internet connection is down. (Assuming your phone isn’t solely relying on that same connection)

I think you’ll find that most of this stuff you would consider core functionality is already being worked on. I recommend posting in the voting areas any specific feature requests as those can then be prioritized using community input as well.

Elsewhere there was mention of some notification updates in the works as well, so hopefully you’ll soon get something closer to what you are looking for.

Don’t get me wrong, having a full monitoring interface with over time stats, performance metrics and event info that can be linked to a full management system would be nice. It would also be a major project in its own right and most likely a major long term commitment.

Current needs I think are far more basic - email messages from the satellites saying I can’t contact your node and/or the node is reporting xyz to an email address of my choice would allow node operates to have a chance to recover their node before a DQ event. Notification messages from the node are less important as many node issues will also mean that the node can’t send a message.

The storage node is proving an API endpoint for that. You can monitor a lot of values.

We had that. Uptime robot is still better because it will notice the mistake within 5 minutes while the satellite might only contact you 3 times per day. It would take several hours before you get the email. Better use uptime robot.