Good to see the feedback and discussion. Thanks Desrever, Chronos and Sentinelrv.
I decided to respond in a more structural way so it is easier to read for others instead replying to each of you and easier to incorporate in the proposal. Hope you don't mind and please fire at will if I didn't answer your questions or addressed your concern.
Starting with the requirements/features:
The proposed wallet is built on the open source Android client with the so-called Schildbach architecture. You can find the original source code here:
https://github.com/schildbach/bitcoin-wallet. Have a look at the screen-shots of the Bitcoin client here: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
Here is the feature list for the Bitcoin app:
• No registration, web service or cloud needed! This wallet is de-centralized and peer to peer.
• With exception to the Abe explorer API used for block hash validation, no registration, web service or cloud will be needed for end user. The wallet is de-centralized and peer to peer.
• The initial blockchain download will be headers only. Subsequent block downloads will be full blocks.
• Display of Bitcoin amount in BTC, mBTC and µBTC.
• Conversion to and from national currencies
Basically fiat exchange rates in many currencies with ability to set default fiat currency
• Sending and receiving of Bitcoin via NFC, QR-codes or Bitcoin URLs.
• Address book for regularly used Bitcoin addresses.
• When you're off-line, you can still pay via Bluetooth.
• System notification for received coins.
• Sweeping of paper wallets (e.g. those used for cold storage).
• App widget for Bitcoin balance.
• Ability to make backups
• Generate new addresses
• Specify the amount send in your own fiat currency
• QR codes and scanning integration
• Address book
There will NOT be any specific NuBits/NuNet features e.g.:
- Use of NuShares
After verifying with the developer, we may be able to customise a little bit with the NuBits colours and fonts assuming the fonts are existing on Android (which is a limited set). Therefore marketing will need to provide style-sheets and colour codes which I think can be done.
Known issues with App:
- App can be slow with time-outs on older or slower devices
- No password/PIN when sending coins
Hope that helps. Not perfect, but I still think it is a good starter package.
As said before the main attraction of this wallet is that it can be delivered relatively fast. Any further additions might add weeks or maybe months to the development and the costs. Also any issues with it are relatively well-known, so we will have a good benchmark to determine what issues are in the original source code and what might be conversion issues which the developer will need to fix.
I suggested a two week window after initial release for bug testing. Myself and others will have to test, but I won't be contracting community or shareholders to do so. There should already be enough incentive to test this and report any bugs in my opinion. Any bugs found will be fixed before the second and final payment is made to the developer. The test criteria will be just verifying the functionality as stated above. Just replace Bitcoin with NBT. Open to any additional suggestions regarding specific criteria, but please accept that this is based on existing software. This won't be a tailored solution.
Agree that paying in advance in not that common in the software world where you are dealing with known entities. In the crypto world this is not the case yet. So from a risk perspective I don't think we will be able to contract a serious developer without having any established relationship. I hope to establish this relationship and that any further contracts e.g. for iOS version or adding features etc. can be on more favourable terms for the Shareholders. I do not think a motion followed by a grant is a sensible and working approach given the above. When the project never starts or due to performance rebates any NBT is remaining the Custodian returns the NBT to a core development fund. This assumes trust in the Custodian to do so.
Support and Maintenance
The support for bug fixing would only be contracted for the first two weeks. In that period we will have the bug fixes. The maintenance will be maintaining the back-end of the app. The developer will host this. There are options:
1) Developer hosts in standard way (no fail-over) at no additional cost
2) Developer hosts a fail-over solution at an additional cost of US$400
3) NuBits Shareholders provide a root-access server to the developer which he can use to built and deploy the back-end on.
With the objective in mind to have a solution running in a relative short timeframe I'm defaulting to option 1 in my proposal. I think we can discuss later to improve and strengthen the solution if we all think it is worth investing further in it. Happy to raise additional grants for this work at a later stage. BTW Challenge with option 3 that the focus of our core team is on the core during the first weeks of the launch.
The license is GPLv3 for the client and AGPLv3 for the back-end (ABE explorer). This cannot be changed. On delivery/final payment we will be able to make a snapshot of both code bases in case the developer is no longer in a position to support or shareholders' wish to have others to add features and support solution going forward.
The developer I'm talking with is MatthewLM, who also delivered the Peercoin Android client. He has been working on several other coins and apps for both Android and iOS before that. Although I have verified some of his work and online identity there is no such a thing as a 100% guarantee in this world. However the combination of his track record and reputation, the payment schedule and the requirements mitigates most of the risk to an acceptable level in my opinion.
I suggest to add the above paragraphs into the proposal. Initially I hoped that we could separate the contract details between custodian and developer from this proposal, but I understand that the trust levels are inadequate to do this, which is totally understandable at this stage. I definitely didn't want to shy away from details, but thought it might be a little overwhelming.
The developer thinks that he will require access to the source code contrary to what some believe is required. I will provide the binary to the developer to have him making a quick assessment why that isn't adequate. This may hold up the release and the voting for this proposal.