Why not contributing to the existing one ? It’s open source.
- Golang is not my prefered language for such project.
- The existing approach might be a dead end. I would rather build something new from scratch.
You can start your own satellite and develop your node connected to that. Otherwise, you have to use the official storagenode.
I’m noone by the way
I think the point was more about developing your own storage node. You would need to contact a satellite for that and currently there is none that would upload to your self developed storage node version. So at least initially you would have to setup a small test satellite by yourself. Once your development is finished and stable enough there might be a way to connect to the official satellites and the test satellite can be sunset.
Connecting to the official satellites is the only goal that could justify to start such development. This obviously needs storj to agree, thus my question.
Wouldn’t it be welcome if it was for the common good?
Probably would be ideal to learn the language and work within the existing framework.
Dumb question but couldn’t you just run a node without explicit permission? The node software is open source and the identify files can be generated, so you just need to impersonate the existing nodes.
I’m not sure if Storj legal will give you the green light but if you have something compelling developed I’m sure they will be all ears to integrate (maybe less so if not written in Go). Using your Chia reference, like how madmax is now working for Chia officially.
The thing is, this is one of the use cases where Golang is pretty good. You’d be hard-pressed to make something that performs better in another language.
Not to mention, reimplementing all the functionality that already exists in go libraries.
Starting from scratch makes zero sense in project like this. You don’t want to step through the same pitfalls and debug bugs that have already been fixed.
If you have improvements in mind - submit PR. If your PRs keep getting rejected and you are at the point when your vision drastically diverts from the storj teams’ vision – fork the project and drive it. (Or join the team and transform the company from inside. Up to you. But starting from scratch is a dead end.)
Go is one of the easiest and simplest languages out there.
Anecdotally, C/C++ developer for few decades, and recently I had to do something in Python and Go. It took me an order of magnitude less time to figure out Go compared to Python.
And besides, some features there are just magnificent (I’m talking go routines and channels).
You can start with the tutorial on the official web site to get a quick grasp on the syntax, and then go watch Rob Pike’s talks on YouTube to understand the motivation behind the concepts.
In small numbers that will work. Scale this up and storj will be forced to implement counter measures. We are talking about customer files that are at risk here. This is not chia where worst case you just don’t get the reward. We are talking about customer data here and if that gets lost we all go home with no payout. So lets better play this safe. Make it an alternative node software that the official satellites don’t select for uploads, work on it until it is proven to be stable and safe to use. Lets not start from the end and just pretend this alternative storage node would be magically free of bugs.
How long do you think a non compliant node will last on the official network or do you expect Storj to give you a free pass to do whatever with customer data?
That alternative node would respond to any request just like the official one. So what do you mean by ‘compliant’?
It has to respond in the same way as the original client, and be always up to date with changes. Otherwise the clients are not interchangeable. Not being interchangeable means also custom changes to the satellite.
It would be better to submit RFCs towards better algorithms. The programming language doesn’t matter in the end. What matters is how the software works.
It doesn’t have to be free of bugs. All it has to be is to have less bugs.
(that would still be quite an achievement, obviously!)
The reason for asking this question is performance not bugs. A software free of bugs doesn’t exist.
Then golang is not the bottleneck. Algorithms and persistent data structures are.
The number of bugs isn’t that important. There are certain code paths like for example customer downloads or garbage collection that need some stability. Also the rollout strategy of new versions makes a difference. In return feel free to implement as many bugs as you want on the dashboard. I don’t mind a broken dashboard at all. I can work around that. But you know there are a few people that will call every bug a high priority that needs to be fixed yesterday. It will be interesting to see how that dynamic plays out.
Me neither, but I’m sure @Alexey would complain with the increased forum moderation workload.