The amount to be decided at once is too large
I think that it is better to do it separately for Milestone.
We are aware, and we do really love the features that Catapult will bring to us. We cannot predict the impact of Catapult in the whole NEM ecosystem, but we know that it will happen and we can design the framework with that in mind.
The NEM Framework aims to provide a higher abstraction for NEM native features, and a solution for non-existence features too. We would like to replace a non-native implementation done in NEM Framework when Catapult provides it, or even add the features provided by Catapult that are not considered in the development due the leak of information.
So, the NEM Framework architecture is aligned with NEM Core architecture, and it will be updated in order to be aligned with Catapult architecture once it is released.
Thanks to the first approach, and the higher level of abstraction, we the applications using NEM Framework will have a better codebase maintenance, and they could migrate faster to Catapult.
hey guys,
as i am no developer i dont get in detail what you are doing but based on the feedback from others it seems like its something which will help to make it even easier to develop on NEM.
as i said, i dont have technical question but iām wondering about the funding because you are asking for a large sum of XEM
- is it possible to tell how many hours you have to work for each milestone?
- how many people will work on the project?
- are you working fulltime on this?
a fulltime dev gets payed 100-150k$/year, so with 3+ million $ i can hire a dev for 20-30 years. as a ānon-devā i dont really see how much work it is to do what you are planning so it would be nice to get some āhour-numbersā
thank you
I think it is difficult simply to compare.
I only know the price of Japanese programmers. And I know that it is lower than the world average.
By the way, Japanese programmers work overtime for 6 hours every day, even if they make a full commitment per person is about 50,000 dollars a year.
Hi, thanks for forwarding this here.
At the moment NEM is a very powerful engine for Blockchain development. Comparing NEM and Ethereum development times may be easily 5/10 since already existing code needs to be fully rewritten and there are very few tools to do it properly. This is something our team has experienced since we have worked extensively with Ethereum and Hyperledger for multiple projects.
However, now that we are working exclusively on NEM we realized that building on top of it could be a lot easier if code was more modular, reusable and there was more developer documentation, skeletons and samples. All this would make working on top of the platform very easy (Hard to say but 2/10?)
As explained above, the budgets are basically set to get almost 50% in the final deliveries while maintaining a continuos flow so that we can pay for infraestructure. We will try to bring more detail to the milestones although we expect to discuss this with the core developers during the upcoming days as stated on the guidelines.
Precisely, that is our idea and is as well stated on the Community Fund guidelines.
Thanks!
Maybe not relevant for this project but:
Hmm from what you are saying it seems Ethereum is more developer friendly, may I ask why you chose NEM over Ethereum? As a developer wouldnāt it make sense to develop in an environment where you donāt have to develop such tools?
Hello,
would it be possible to get a discount since the price of NEM skyrocketed in the last months? This proposal looks great but there are some grumpy people on the forum saying this is way too much money.
Also there was an idea on the forum that part of the payment would be in NEM and the rest would be also in NEM but valued in USD (so that you would be paid like 2M NEM + 1M USD paid in NEM with the future exchange rate). This would be safer for both sides. No idea how voting works but multiple choice option would be nice if possible.
Also we would like to know the stance of NEM internal DEVS about this project.
Thanks!
Hi @spizzerb
Indeed, but this will not only affect developers but companies trying to decide what platform they should be using for Blockchain development.
That is very hard to say due to the many unknowns and the fact that we will not compromise security and features for time. The full project will last from 14 to 22 months.
Yes! And we will continue working on it after the last delivery. Our goal is to create a tool that any company working on NEM (such as Atraura) will continually use and evolve.
We chose NEM/Mijin over Ethereum because most of the companies do NOT really need to have their business logic decentralized, specially when they have been spending billions of dollars on building them and Ethereum requires them to start from scratch just to make it decentralized.
NEM allows them to use their existing systems and connect with a data layer that brings them the benefits of Blockchain technology without most of the pains.
Imagine if we had the proper tools.
Alright, so we have just updated the post in order to include our full documentation:
We look forward to your feedback and at the same time @b1 has proposed a very interesting idea: Letās have an AMA session through Youtube. This way we will be able to answer any questions that may arise and try to see what the best path forward should be.
We are proposing to host it Friday 9th at 12h GMT. Looking forward to meeting you all there.
Thanks!
Thanks for publishing the document.
Many of the terms in it are a little above my level of understanding but I certainly recognise the Agile approach and technologies that are being discussed. I like the idea of abstraction in terms of higher level API for integration with NEM, I like the idea of visual abstraction to make coding easier, faster and more secure.
I do feel uneasy about the Proxy concept, to me this appears like off chain transactions where as a developer and user I am having to place my trust on a centralised solution. Could you explain the benefits of the proxy functionality? How would address concern of off-chain transactions?
As another member mentioned, I also would like to see more concrete numbers as far as man hours for each milestone.
You say āmilestones are not time boundedā, but from a pure business point of view no one hires a company without deadlines regardless of project.
I know these are all estimates, but for each milestone (sub-milestone) how many developers/hours do you estimate it to take?
So for MileStone#1
Basic Framework PoC (NEM Authenticator) - # developers + estimated hours?
Framework basic Website - # developers + estimated hours?
Technical Reference Draft - # developers + estimated hours?
etcā¦
The Proxy Component aims to solve tricky business logic for applications that uses the NEM Blockchain but that the end user is not aware of it.
We are developing a project, Alertry, which uses the NEM Blockchain but the user is not aware of it. We provide all the blockchain benefits, but we need to remove all the difficulties of understand the concepts and how the blockchain works that the user faces when it discovers a new technology. So, the app has a better usability, adoption, and all the benefits of NEM Blockchain.
So, what we do in Alerty is: 1) app talks with NEM API, 2) resend the data to notify the backend system that it has done an action, 3) trigger the specific business logic.
What NEM Proxy will provide us is a base to listen and act when a NEM API calls is triggered, all the NEM calls are signed on client, so it will not be a security problem.
So, because as the application needs specific business logic, we need a backend system that know all the endpoints and just acts as a listener. Without this peace of software, the developers could start producing their own models, and rewriting the logic and not using the NEM blockchain due the time needed to be able to solve a specific business. If we make it easier to write specific business logic, more software using NEM will be wrote.
One benefit of NEM Proxy is to create a mobile app that uses the NEM-Library and it plug-and-plays with the NEM Proxy, and just listen specific endpoints to provide the best business solution.
Another industry that could benefit of NEM Proxy could be the financial industry, they could start to create prototypes based on NEM Proxy + NEM-Library.
If products are able to hide the complexity of the blockchain and they have the power to write specific business logic valuable for the user, it will be awesome! So, provide the benefits of the blockchain and the value of project, itās a win-win.
This project looks very promising to me and to my understanding itās not like we have developers lined up to work with nem so showing preparedness in supporting even large scale projects might arise the interest of other crypto/blockchain developers to start working with nem.
It looks like you have really prepared well and thought this through and itās always great to know you have already worked with nem so you know what youāre doing. However this stuff is just way too complicated for anyone not into software development to really grasp so i would really appreciate someone from the dev team weighing in after theyāve studied the documentation. The devs after all are the only people who know how this would work and how much of this would be necessary with the upcoming catapult features.
Thx for your answers. Now that i know that you work fulltime to make it happen it sounds alot better
Iāve looked at the previous documentation and this one is much more detailed and looks good and several examples introduce what you intend to do. Iāve already bought into this project but I agree with Jyrvalor that a core.dev should look into this for the technical aspects. They will have to look at it eventually if this gets approved.
Not sure if Iāve missed something in the post, but where are the instructions on how to vote for or against?
It will be announced, voting is done by sending message to corresponding NEM account, one for yes, one for no, send to just one
I didnāt want to comment until i get an idea about what is being proposed, and a bit after reading, this looks like something NEM needs on order to achieve higher level of implementation from third pary users.
Making a framework would motivate a lot of people to develop their own uses and applicatons for nem, as will it drop the price of development of future projects,
Finally i would love to wait for devs to discuss the technical possibilities since i am not competent in that field,ā¦
As for making things a bit slower, we used to wait in lines in banks for hours, what is a minute at home compared
Considering that they have already delivered on other projects Iād say the whole thing is worth a try.
On top it seems to be a well working / harmonic team which is something that is not easy to find.
Here are my thoughts on this after reading everything and considering it for a bit.
I wanna preface this by saying that Iām really happy to see a well thought out proposal. Itās good to see people who are serious about blockchains wanting to build something in the nem ecosystem.
Iām a little torn. I do think that this is something that nem needs and an initiative worthy of funding. On the other hand I donāt think itās worth THAT much money, Iām not entirely sure I agree on the technological decisions (always debatable) and furthermore some of it Iām not sure makes sense to build at all, at least at this point.
This is a big project made up of multiple parts and in my view it might be best to cherry pick and only fund those parts. For example fund nem library but not DSL.
nem library
Iām totally in favor of funding this part. nem needs something like this. If it was up to me Iād rather have a nem library in multiple languages than have DSL and nem proxy. That is something that would actually lower the entry barrier and it would let developers chose their language. I get that JS is all the rage right now but this is about driving adoption right ? So we should give people choices. Not everyone can chose to the language they use. Be it personal preference, company guidelines or shitty legacy software hat it needs to be integrated in. A great wrapper around the API could do wonders but we have to cater to what people actually need not what we think is best or what weād like them to use. People need different things, so giving them choices would imho make a lot of sense.
nem DSL
I donāt think we need it. I understand the intention but I honestly donāt think itās necessary and in my view it is certainly not worth the money (or effort for that matter).
nem View
This may be something nice to have but right now I donāt really have a picture of how much this would entail. Iām also not sure itās worth it to be honest. It would probably end up being used mostly for PoCs so I donāt know that we need it badly enough to pay for it.
nem Proxy
As mentioned before I think this could overlap with Catapult. I do not think that any work or funds should be spent building something that may very well be made obsolete by catapult. As a sidenote: the use case in that one linked write-up isnāt really clear imho. It is not being made clear how the proxy avoids polling (I suspect it just avoids it for the mobile app, not entirely, someone has to be looking at the blockchain right ?).
Even if Catapult does not have all the functionality that nem Proxy would have, clearly the API gateways that Catapult will provide are where that functionality should sit. It does in my view not make sense to introduce a 4th tier that is basically also just an API gateway with some extra calls for convenience. Whatever nem proxy would do, it would imho be better placed in the catapult api gateways. Itās a simply question of placement of functionality.
nem TestRPC
This sounds great. I wasnāt yet able to look into ethereums counterpart and donāt really understand how exactly this is supposed to work but I think giving people the possibility to develop and test applications without requiring them use the testnet for the initial stages of development would be awesome.
nem nem Health Report
Imho not necessary and hence not worth the money.
I hope this doesnāt come off too critical. Overall I really like the proposal and I hope it happens in some form