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
(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.
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.
