**Draft** proposal to develop a NuBits Android wallet

NuShares Grants
#1

Dear shareholders and community members,

Like to have your attention for a draft proposal for a custodial grant for the development of an Android wallet for NuBits. The proposal is still ‘draft’ as I would appreciate a discussion and feedback from this community about the proposal before voting takes place. I suggest to leave it open for comments for the next 2 days till about 22/9/14 9.00am UTC. At that time I will consolidate all the comments into a final proposal and republish that soon thereafter allowing voting to occur.

Having an excellent example from Kiara Tamm, I have also posted my proposal as a private Gist on my Github account. This was done so that the community can be made aware if any changes made to the document (through the version control system), and so that it can easily reviewed by Shareholders. If amendments to this draft proposal are required, I will clearly call them out within this topic and republish the final proposal for voting.

The draft proposal can be found here: Draft proposal for custodial grant for Android wallet v0.1

Overview of grant:

Custodian: Cybnate
Proposal: Development of NuBits Android wallet
Submission Date: 20-Sept-2014
Requested Grant Amount: 2500 NBT
Custodial Fee: 100 NBT
NuBits Grant Address: To be published with final proposal
Vote Amount: 2600 NBT

Specifically on the following items I like to hear your comments:

  • What about ongoing updates e.g. new wallet/protocol, feature requests? At this stage the proposal leaves this out of scope and it would therefore require a new grant.
  • Type client (lightweight) chosen, time-line of execution and whether this would indeed contribute to additional demand of NuBits early on as per proposal.

Looking forward to your responses.

– Cybnate –

1 Like
History of the Nu Network (Feedback Please)
**Draft** proposal to develop a NuBits Android wallet v0.2
Merchant Adoption - Earn 100,000 NuShares
#2

Thank you Cybnate for putting this together. This project is something in which I will put my votes. I have little time to review the proposal in depth right now, but I know its important to get some quick feedback from us. So, here is my quick feedback (apologies in advance for typos, misinterpretations, and repetitions)

They main flaw I found in this proposal is the lack of a metric to evaluate whether the wallet was built as expected. This is common issue to software projects and contractors.
To do that you should be way more specific with what you mean by “NuBits Android Wallet” . There should be a section with wallet minimum requirements, mockups and functionalities. For instance, I believe that with that sum only a very basic wallet can be put together, unless the dev forks an existing wallet which is already advanced. In that case, it must be clear.

  • Is it a NuBits-only wallets, so no NuShares. Correct?
  • Can I park?
  • can I scan QR Scanning?
  • Can I generate new addresses?
  • Can I make Backups?
  • Can I scan private keys?
  • Can I have multiple private keys and an aggregated balance?
  • Does it need to download the blockchain ?
  • HD?
  • Pin protected?
  • Will I be able to specify the amount to send (receive) in my own currency (EUR instead of NBT) ?
    … and so on and so fort.

You should start defining a minimum set of functionalities that must be in the wallet to be considered a success. I suggest the developer get paid in full only if 3 random shareholders can test the wallet and it satisfy the criteria you specified.

EDIT: Another suggestion. Since you propose that 50% of funds will be released on “Release of the final version” , it is likely that some NBTs will be laying around for a while. Maybe you should specify what you plan to do with them. Store them?(how) . Park them (how long, what to do with profits of parking)

EDIT2: I would start giving names to release versions. So, lets say that what you consider finish is “Final version”, lets call this 0.1.0 . What do you think that happens next? Who maintains it? . Maybe start thinking about having a plan for 0.2.0, 0.3.0 till version 1 with contracts of maintenance .

EDIT3 : will the source code be open source? which licence? to whom?

My 2 NBTcents

1 Like
#3

It is customary for work to be paid for after it is complete. What about using the following approach?

  1. This proposal is put forward as a motion instead of a custodial grant, but still specifies all terms that the grant proposal would contain (custodian, NBT vote amount, etc.)
  2. Once the motion is passed…
  3. Work is completed to the satisfaction of shareholders
  4. A custodial grant is put forward matching the motion
  5. The shareholders approve the grant, which pays for the work.

This model more closely matches what is already done the real world. It protects shareholders in the event that the project is never started, or is not completed according to the original requirements.

Thoughts?

2 Likes
#4

If I were that dev I probably will not start working on the project based on a promise (like in real life) .
A diluted payments with delivery milestones is what I d go for.

#5

The above plan could easily be adapted to use delivery milestones. Simply roll out a new grant each time a milestone is completed.

#6

Probably right. A drawback that I see is that it is quite time consuming if we need a new grant for each version of each project funded by shareholders grants.

#7

Just in case you guys didn’t read the proposal, she’s talking about a half now, half after completion payment to ensure all work is done…

#8

Are we going to find out who your developer is? I’m assuming it’s MatthewLM, who recently released the Peercoin Android wallet, but I’m only guessing.

#9

Payment before work starts is a very unusual arrangement in the software development world.

#10

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

  • Parking
  • 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.

Test criteria
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.

Payment schedule
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.

License
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.

Developer
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.

Issue pending
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.

#11

I hope you have contacted the developer before putting name in the proposal.

#12

I have a branding guide that can be sent if the proposal is successful. Our website vendors had excellent foresight in selecting the new version of Roboto as our branding font - it is a Google font that is available to Android developers.

1 Like
#13

@mhps I’m still talking with the developer. But he has all the draft contracts and information for sign-off. Technically he could still withdraw as I could, that’s why I flagged the issue around source code yesterday. It may have impact on price, timelines etc. or something else may come up in our talks. It is a thin line between providing confidence to voters on the development and confirming deals at the same time.

The alternative I had is negotiating a firm contract and then launching my proposal with the risk that I had to break open a carefully negotiated contract. This way of working is very new to me and I’m still learning what the best way might be to work through going forward. I think the slightly iterative process works best, but time will tell.

#14

I wonder if it is feasible to use a bidding process. You get authorization of a fixed cost maxinun amount from the shareholders and let market decide the price.

#15

Definitely something to explore for future proposals, but in this case it wouldn’t have worked as we have some urgency and there is no effective market basically.

#16

Just a quick update:
The Developer is still working his way through the contract and will assess the need for access to the source code later today as I understand. So I will put this proposal on hold until I have a Memorandum of Understanding with the Developer. Will keep you up to date here on any progress.

In the mean time I like to propose some ideas for v0.2 (or beyond) of this Android wallet:

  • Support for park functionality
  • Password / PINcode when sending coins
  • Increasing robustness/availability by adding fail-over solution or hosting on a NuNet controlled site.
  • Full integration between website, forum and wallet (links and visuals)
  • Add compatibility with Orbot (socks setting) so you may connect via Tor even without rooting.
  • Cold storage spending (importing QR code of private key)
  • Improve performance of app on slower devices

Feel free to suggest others. It is just a wish list, no guarantees at this stage and I suspect when the App is delivered we have a few more to add to it and may have to set some priorities for a follow-up proposal.

#17

Not sure about the urgency of this proposal. For example, Peercoin has seen huge successes so far, and has not had an Android wallet until very recently.

#18

@chronos Not sure about your comparison. Peercoin had huge successes as a commodity, not as a currency. The objective of NuBits is different as you know. We are looking for means of usage of this currency (see my objectives for the proposal). NuBits have almost zero speculative value.

1 Like
#19

Good point. I hadn’t considered that when thinking about the benefits of a mobile wallet.

#20

Yes, that’s why this is so important to have something ready as soon as possible.

1 Like