short answer is : we don’t know.
We first need to prepare catapult for deployment in private environment.
when that step will be done, we’ll need to add changes required by public-chain.
(There are some estimates when will this happen, but besides speculators, no one will make a use from that information)
2 Likes
I think otherwise. devs working for their own pleasure is the best this community can have
I understand your frustration, but you have to understand that the NEM devs are making a blockchain from scratch, and not just “a” blockchain, but they are trying to make “the best” blockchain. There really isn’t a set timeline for that. They are in unknown territory. This isn’t like an app on the Apple App Store where there are millions of apps and often any one app has 100 apps just like it. People making that kind of software can have set timelines. Seriously, how many quality blockchains are there in the world written from scratch? Only a handful.
I can assure you I talk to the devs many times a week and they are working seriously hard coding. This thread is not about hype or big promises; you won’t find that here. There is literally more than enough of that on every other blockchain website. This thread is for updates on real work that has been completed. These guys are building things that nobody has ever built before and because of that it is hard to really pinpoint what quarter it will be ready. That is why they say, it will be ready when it is ready.
We actually went through this same thing with NIS1 before launch. It took more than a year of writing code and people were going crazy demanding a day for launch, and the NEM devs constantly said, “it will be ready when it is ready”. And when it launched… guess what? It was ready! No major fork, no network implosion, no lost funds, no hacks. It was really ready. Not one, and I mean this seriously, not one other chain can say that.
So basically, they will not ever give you a date on when this will be launched, because if it wasn’t 100% ready, they don’t want to be pressured into launching. Instead, they will do the right thing and launch it when the code has passed all the tests.
If you want to see something, look at this.
That is a report from CERT. and there are a bunch of chains that launched because they set dates, then there is nem.core which was launched when it was ready.
The only things more secure than our “Core” were other people’s block explorers and super light wallets.
6 Likes
I’m following monti in this, there is just so much obscurity in the whole process. We understand that everybody is very busy seeing the number of code written and number of tests made, but for most of the people these numbers do not mean anything.
Is it not possible to split the whole project into multiple smaller projects (you can call them milestones for example). Perhaps something like multisig/mosaic/namespaces/… and then let everybody know that something is finished, or something is working but not yet finished?
Also are there going to be smaller updates to the working software or is there going to be one mayor update with the release of the catapult core?
Catapult will be released and stressed tested on private networks first. After the devs are completely sure it is really ready, it will be released on the public chain. So when you hear about companies using “Catapult” you know that a major milestone has been reached.
2 Likes
not sure in anyone follows OP anymore, but updated
well, you should be able to partially figure that out based on the things I’m posting…
we have internally working namespaces and mosaics, we’re working on what you currently know as multisig, but what will be much more interesting and flexible… (cannot spoil the fun yet)
probably one huuuge change, but that’s not anywhere on horizon yet, as @jabo38 mentioned, private chain goes first.
5 Likes
How fitting Jaguar the animal… 
…owning those commits. 
Catapult will bring us at least a fee steps closer to world peace.
Great read! Any news on the dev front that you can share with us?
Funny to see old names from back in 2014 that are still around.
Nice read to see the internal workings by the Developers. Personally I’d rather be patient and wait for a fully tested software rather than something that is released to the public and is full of bugs - which isn’t good for reputation or investors.
I’m in it for the long term, and can wait a few years if the end product is optimized and superior. I can cash out now and be a millionaire, or I can be patient, wait a few years and be a multi-millionaire and/or live off the transaction fees. By that time the Devs would be billionaires I hope as a result of their commitment and hard work, and they can enjoy the fruits of their labor.
2 Likes
@gimre in regards to websocket support, is goal of catapult to support both http/2 and websockets, or http/1.x + websocket support?
Also side couple side questions:
- will, or is target, of api layer to be little more “REST-full” in paths and ID handling?
- see references to plugin and the like, is the storage/indexing going to be pluggable? ie: if running a private chain and my org uses xyz as our canonical store/search solution would i be able to support that?
1 Like
sorry for late answer:
right now it’s http/1 + ws, but due to more modular architecture of catapult, supporting http/2 shouldn’t be a big problem.
we’re trying our best, but it’s hard to judge, it’s possible we’ll share the docs for APIs earlier than catapult itself
there are two things: main p2p network storage - you probably won’t be able to change this.
api layer storage - that is pluggable, and if all will go well, you should be able to replace it, but you’ll have to write appropriate plugin on your own.
.
thanks for follow up,
couple ideas for you to think about as things progress:
- maybe implement the “v1” api as-is or as close to possible of current NEM for backwards compat and then do some proper /api/v2/xyx, etc for “catapult proper”
- if pretty modular on connectivity front highly recommend looking into supporting a gRPC interface as it would give you a significant starting point for supporting multiple languages for clients out of the gate
actually it’ll be in reverse order, first we’ll have normal api, then we’ll add backward-compatibility layer.
gRPC - probably won’t be an option, cause p2p use custom binary format, but there’s catapult-sdk, that you’ll be able to use to talk to catapult p2p servers directly if you’ll need it
For gRPC was more referring to alternative/addition to the REST interface/layer. Its built in communication/streaming capabilities are great and auto built in support for generating many language bindings for 3rd party product integrations vs writing REST sdk’s from scratch in each language.
Hi,
Have you considered to use Akka (http://akka.io) for the catapult WebSocket support? It comes also with messages based on the Actor model. So you get a highly concurrent, scalable, event driven architecture, built on reactive streams, with only one package.
What was the reason to choose ZMQ over such a technology?
Best regards,
Christian
1 Like
Catapult is written in c++ (server) and javascript (rest).
Akka on the other side is written in java, so it doesn’t fit in there.
Thanks for your response. I thought the REST API is written in Java. So it means that the new catapult REST API is based on node? If so, how do you make use of multiple threads for concurrency in node? I haven’t used node for server applications and I know there are options to bypass the single thread limitation.
This takes me also to the question why a dynamic typed, single threaded, node based solution was choosed for the API part instead of Akka or a similar technology?
Sorry if this sounds critical. This is not my intention. I’m only interested on which aspects technologies will be choosed for the NEM platform.
Best regards,
Christian
REST API is indeed based on node. All db calls are async (and mongodb is multi-threaded) so they should not be a bottleneck.
Node is widely used in many project. It looked like a good approach to us.
1 Like
That’s interesting. Didn’t see that coming.
I always thought about looking at node but never really saw a reason to switch to it. Then there also were the forks and the left-pad incident which really turned me off to it.
I trust you guys though 