NEM Framework - Community Proposal

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!

1 Like

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!

1 Like

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.

2 Likes

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.

3 Likes

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!

4 Likes

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…

1 Like

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.

2 Likes

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.

2 Likes

Thx for your answers. Now that i know that you work fulltime to make it happen it sounds alot better :grinning::+1:

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 :wink:

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

1 Like

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. :wink:

4 Likes

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 :slight_smile:

5 Likes

@patmast3r’s last point is probably meant to be “NEM Health Report”.

thx, corrected :wink:

Thanks for the explanation. Is the transaction through the proxy synchronous or asynchronous e.g. does the proxy wait for blockchain confirmation before signalling commit to the client?

@patmast3r Thanks for your input.

After reading some more of the docs, really appreciate the effort put into the proposal, and understand a little more of their intention. This is not some fly-by-night team who slapped together an idea overnight.

While I’m onboard, also feel the price is somewhat high.

Seems though this whole process is lacking in terms of negotiation. As a community we can only vote yes/no, which doesnt leave any room for dialogue in coming to an agreement.

What if we agree with the whole proposal but feel it’s only worth 10million XEM or a flat $2million USD? or we don’t like the DSL component but everything else. Not quite sure if each of the milestones are dependent on each other or do they stand alone, which would allow breaking the milestones into separate proposals with separate budgets and voting on each one. Just thinking out loud …

2 Likes