Now that NCC is Open-Source, we really would like to get community developers involved in contributing. The core dev team has been brainstorming and came up with a list of tasks that interested developers can work on:
* Prepare the graph view
* Review the code / unit tests and determine weaknesses
* Add REST API tests
* Make the 'create timestamp' and 'Timestamping service' view
* Fix any of the github issues
* Improve our settings handling
* …
If you're interested or know someone who is, please let us know!
Still looking forward to getting some more pull requests. Is anyone in the community working on a fork?
Don't like the current state of the NEM monitor and are / know a developer? Then improve it :D!
In case people are lazy and don't want to search, NCC repository is here: https://github.com/NewEconomyMovement/NemCommunityClient
I have 0 Java experience, although I'm proficient at Javascript (both server and client side)
I'll try to improve the UX a bit
An important addition would to abstract the NCC library so it can be reused standalone in websites.
Although Require.js is a good way to help organize frontend code, the code is tied to DOM at the moment.
A full blown refactor should be needed so people can communicate using JS on their localservers / crossdomain using AJAX / WebSockets without the need to build something else for this communication to happen.
I have a strong Angular bias, and they usually 'force' you to write everything that is stateful into services. Services do no DOM manipulation, although they can emit events. Also, I'm an 'evangelist' of using dual apis for Promises, it's the current "state of art" of asynchronous programming right now. (Angular uses it everywhere too)
It would be nice having a one click payment page accessible without previous authentication
Imagine publishing a link such as
http://127.0.0.1:8989/send?to=TA2RTA-J57GHB-RFYL3A-PUGRD5-EQNBW4-PLYJUI-DALH&amount=12.3&message=hello&encrypt=true
someone with a running NCC just has to click on it, enter his wallet password and click Ok
It would be nice having a one click payment page accessible without previous authentication
Imagine publishing a link such as
http://127.0.0.1:8989/send?to=TA2RTA-J57GHB-RFYL3A-PUGRD5-EQNBW4-PLYJUI-DALH&amount=12.3&message=hello&encrypt=true
someone with a running NCC just has to click on it, enter his wallet password and click Ok
That would be dangerous as hell. It's called CSRF :)
It would be cool though if a link would fill out everything needed in NCC (amount, fee, receiver) but not autmatically make the tx. Mutlibit supports that for example.
It would be nice having a one click payment page accessible without previous authentication
Imagine publishing a link such as
http://127.0.0.1:8989/send?to=TA2RTA-J57GHB-RFYL3A-PUGRD5-EQNBW4-PLYJUI-DALH&amount=12.3&message=hello&encrypt=true
someone with a running NCC just has to click on it, enter his wallet password and click Ok
That would be dangerous as hell. It's called CSRF :)
It would be cool though if a link would fill out everything needed in NCC (amount, fee, receiver) but not autmatically make the tx. Mutlibit supports that for example.
Isn't it the same I wrote?
I imagine the link showing a form where I have to insert my password and confirm.
The only danger I can see is someone making a form similar to this one to steal my password but the same can happen also with current login form.
@pocesar: We definitely are in need of javascript developes
A fullblown refactoring is probably very time consuming and would have to be coordinated with the other frontend developers.
But I think there are tons of other things where you can help as well. I will discuss it with the other developers.
@BloodyRookie Well, a standalone lib is a must for seamless integration with HTML/Javascript interfaces (almost everything today). From Windows 8 apps, to hybrid HTML5 mobile apps, they all use Javascript for some kind of communication, even when contacting with the native interface.
@rigel funny, I proposed to NXT coders the possibility to issue limited liability tokens. that means, it's a token that has a short lifetime, and can be used to withdrawl funds from an address (an inversion of control), like redeeming a $ voucher. it must be explicitly created by the wallet owner and it's broadcasted to the blockchain. https://nxtforum.org/index.php?topic=4848.msg92624#msg92624
It would be nice having a one click payment page accessible without previous authentication
Imagine publishing a link such as
http://127.0.0.1:8989/send?to=TA2RTA-J57GHB-RFYL3A-PUGRD5-EQNBW4-PLYJUI-DALH&amount=12.3&message=hello&encrypt=true
someone with a running NCC just has to click on it, enter his wallet password and click Ok
That would be dangerous as hell. It's called CSRF :)
It would be cool though if a link would fill out everything needed in NCC (amount, fee, receiver) but not autmatically make the tx. Mutlibit supports that for example.
Isn't it the same I wrote?
I imagine the link showing a form where I have to insert my password and confirm.
The only danger I can see is someone making a form similar to this one to steal my password but the same can happen also with current login form.
patmast3r, rigel is proposing to pre-populate the form inputs with the GET parameters. He is not proposing to have the transactions auto-submitted, which would indeed be dangerous.
@BloodyRookie Well, a standalone lib is a must for seamless integration with HTML/Javascript interfaces (almost everything today). From Windows 8 apps, to hybrid HTML5 mobile apps, they all use Javascript for some kind of communication, even when contacting with the native interface.
@pocesar - can you elaborate on your thinking around a standalone lib? What scenarios are you thinking about (merchant wanting to accept NEM, developer building on top of NEM, other)? I'm still unsure whether third parties will be more likely to build on top of the NIS APIs or the NCC APIs, so I'm curious what kinds of things you're thinking about? (The main difference is that the NCC APIs are wallet-centric, whereas the NIS APIs are not).
@BloodyRookie Well, a standalone lib is a must for seamless integration with HTML/Javascript interfaces (almost everything today). From Windows 8 apps, to hybrid HTML5 mobile apps, they all use Javascript for some kind of communication, even when contacting with the native interface.
@pocesar - can you elaborate on your thinking around a standalone lib? What scenarios are you thinking about (merchant wanting to accept NEM, developer building on top of NEM, other)? I'm still unsure whether third parties will be more likely to build on top of the NIS APIs or the NCC APIs, so I'm curious what kinds of things you're thinking about? (The main difference is that the NCC APIs are wallet-centric, whereas the NIS APIs are not).
well, look at stellar-lib (https://github.com/stellar/stellar-lib) it works out of the box in node and in the browser because it's DOMless. it comes with everything you need to kickstart any development that will eventually connect to a booted node and issue commands. when in the browser, on public nodes that accept cross domain websockets and AJAX calls using CORS, it can work without even talking to the server, which is great if people doesn't have a managed backend.
My main concern that other coins doesn't have good support for is merchant tools. Cumbersome "donate" buttons for example or transparent one-page checkouts
@BloodyRookie Well, a standalone lib is a must for seamless integration with HTML/Javascript interfaces (almost everything today). From Windows 8 apps, to hybrid HTML5 mobile apps, they all use Javascript for some kind of communication, even when contacting with the native interface.
@pocesar - can you elaborate on your thinking around a standalone lib? What scenarios are you thinking about (merchant wanting to accept NEM, developer building on top of NEM, other)? I'm still unsure whether third parties will be more likely to build on top of the NIS APIs or the NCC APIs, so I'm curious what kinds of things you're thinking about? (The main difference is that the NCC APIs are wallet-centric, whereas the NIS APIs are not).
well, look at stellar-lib (https://github.com/stellar/stellar-lib) it works out of the box in node and in the browser because it's DOMless. it comes with everything you need to kickstart any development that will eventually connect to a booted node and issue commands. when in the browser, on public nodes that accept cross domain websockets and AJAX calls using CORS, it can work without even talking to the server, which is great if people doesn't have a managed backend.
My main concern that other coins doesn't have good support for is merchant tools. Cumbersome "donate" buttons for example or transparent one-page checkouts
I think most 3rd parties will connect to NIS directly instead of going through NCC.
But that doesn't mean there's nothing for you todo. You could build our equivalent stellarlib :). You could build the js library that works with NIS out of the box. This would imho make a lot more sense than reworking NCC for that purpose.
In fact maybe we should build a collection of such libararies in differnet languages.
The only danger I can see is someone making a form similar to this one to steal my password but the same can happen also with current login form.
Good point. Any ideas to make phishing scams recognizable for a normal user?
Is NIS open source too?