After some discussions in another thread, it was proposed that a list of requirements for a safecoin wallet application can be worked out by the community, and it will potentially result in an RFP as part of the CEP.
This is just a draft I put together in order to trigger the discussion and refinement of each them as needed.
Please note this is based on my current understanding and personal assessment.
Purpose:
Create a first version of a safecoin wallet application with a reduced/minimum set of features which can provide us with a basic tool for testing safecoins (whenever available), help us with safecoin related designs and/or implementations activities, as well as being the foundation for expanding it to support more advanced use cases in subsequent versions.
Assumptions & Constrains:
Given that the safecoin is still not available in the SAFE network, a tag type for StructureData can be elected to create the âsafetestcoinâ coins.
Coin divisibility support doesnât need to be part of the first implementation, but the app shall be designed so it can support it in the future.
* A single wallet address (clientâs public key) is associated to a SAFE user account in this first implementation.
The application can be a web app, a browser plugin, or a desktop application. This can otherwise be pre-defined and made explicit as part of the RFP, or it can be left open allowing the proposals to define it.
The application should not (or it should be discouraged to) access the SAFE network through the SAFE Launcher API as it will not be the way forward once the SAFE Authenticator is in place. Using the safe-js library, or safe_core library directly, should be favoured.
Technical Requirements:
The wallet application shall be able to handle âsafetestcoinâ coins transactions within the SAFE network.
The application shall be able to display the walletâs âsafetestcoinâ balance.
The application shall be able to display the wallet address.
The app shall be capable of sending âsafetestcoinsâ to another SAFE wallet address.
The wallet shall request just the recipientâs wallet address and coin amount to perform a transaction, any other information like a description can be requested as optional fields.
A simple contact list shall be provided to store wallet addresses with a label.
The application shall allow the user to manually enter the recipientâs wallet address or select it from the contact list.
The app shall allow the user to see its transaction history.
The app shall differentiate incoming from outgoing transactions in the transaction history.
The wallet shall periodically sync up with the SAFE network, e.g. every 2 minutes.
The wallet shall display an alert upon an incoming transaction.
I believe that an account should be able to have multiple wallet addresses
And any public or private ID should be able to the wallet address.
This would have to be optional since some people may not wish a history to be kept at all anywhere[quote=âbochaco, post:1, topic:11812â]
The wallet shall periodically sync up with the SAFE network, e.g. every 2 minutes
[/quote]
What purpose?
Supposedly a message is sent whenever a coin is sent to your address, so really it just needs to check messages.
What would it sync to? It cannot search out all the coins to find which ones belong to it.
I donât really disagree with this, but I thought we may want to keep that out of the scope of a first version of the app.
Yes, maybe we can make it optional so the user can switch it off, although this would be only accessible by the user and the wallet app.
Yes, I was thinking about reading the messages periodically, as my understanding is there is no push, is there? so analogous to the email app that you have to refresh the inbox, having the app to do it automatically without the userâs intervention.
Actually you put it into the scope by limiting it to one of the many public IDs an account can have (3 limit mentioned for an initial implementation during alpha/beta)
The APP in my mind should be able to work on any public/private IDâs wallet thus not part of the scope and simply the wallet address.
Unless compelled to by a court. Some may prefer to comply with court orders rather than face the 6 month to 5 years imprisonment (in Australia) for not revealing passwords/keys and proving access
If the data is NEVER kept then there is nothing to reveal.
It sounds like you think it would be more difficult to allow multiple SafeCoin addresses / IDs and like @neo correctly says thatâs not the case. Itâs how SafeCoin works by design and limiting that feature would be the path that is more complicated and would be harder for you to complete. SafeCoin Wallet is a much needed and crucial part of SAFE so lets not look for ways to cut corners anyway
Also, I strongly second @neoâs idea of tx history being not only 100% optional, but OFF BY DEFAULT, for exactly the reasons he gives, and more. People who seek SafeCoin seek it for itâs anonymity first, and your idea undermines that default tx privacy in perhaps the greatest possible way.
My suggestion is to kill the history idea so you have more time for the other parts, or if you think itâs a cute handy idea etc like a BTC wallet (which I disagree with, but) then at least pleeeeeeeease must leave it: 1 Optional and 2 OFF by default.
Donât want to bin SafeCoins best features early on (or ever, hopefully people donât adopt open history wallets ever, down the line, and give up freedom without knowing)!
It also depends on how much the wallet wants to frontrun MaidSafeâs work on SafeCoin. A basic wallet can be developed merely with transferable StructuredData, but since there wonât be a native receipt âpushâ mechanism that will have to be manually implemented. This could be implemented either with AppendableData or StructuredData (similar to how Project Decorumâs proof of concept worked).
Hope I didnât sound too harsh; just re-read my message.
I just get this way when I see something I care alot about / think is important. So itâs definitely a complement to your project and Iâm just trying to be clear about a few points.
I just blurred the line which mentioned about managing one single public key.
Some more thoughts regarding the transaction history. Perhaps it can contain only the recent transactions, i.e. the latest incoming transaction for each coin by only showing previous owner of each incoming tx. So in this case the app is not keeping any extra information but just showing the information kept in the coinâs SD.
I just keep thinking that itâs useful for the user to have at least this minimum information to understand its current balance and how it has been affected by the transactions made. E.g. if you are receiving payments from many people, you would need to understand if someone claiming to have sent you the coins is telling the truth, by confirming that your balance was incremented by X coins is not good enough in this scenario (specially if you are receiving the same amount from several people).
I created this very basic safetestcoin data layout I thought I could share just for the sake of opening the discussion, and possibly towards agreeing on the one to be implemented in the first wallet app (thanks to @neo, @Seneca and @Southside for helping me in understanding some aspects of the safecoins in gral. I recommend this post to anyone trying to understand about safecoin and/or altcoins in SAFE).
SafeTestCoinâs IDs are generated by the vaults when farming.
AppendableData has a size limit, my understanding is that using StructuredData for the wallets would prevent some additional complexity in this regard.
The ID of a wallet is calculated from the PublicKey, so it contains the list of only the coins owned by the same PublicKey. Coins owned by another PublicKey shall be kept in a separate wallet.
If the app can generate a deterministic string, based on the accountâs private information (âŚI didnât dig into this to understand exactly which info and/or how thoughâŚ), which can then be prefixed to the PublicKey. If we make this standard, any wallet app should be able to retrieve/import/read the wallets as long as it is provisioned with the PublicKeys.
An alternative could be just a single MutableData:
If you think this should be kept in a separate discussion please let me know or just split it.
Sorry this is a little off topic, but when I look at coinmarketcap I see over $14B, that could all become mutable data. I hope that the tool that Maidsafe will use to translate Maidsafecoins to SAFEcoins will work across all blockchains (bitcoin Port 8333), that way we can get other coins moving from blockchain to SAFE Network data. Imagine no more waiting (yeah i know people are experimenting with lightning network etc), no more blocksize debate, more people interested in what the SAFE Network can do.
Payments just need a signature, right? While nobody stops you from using that same private key for other things as well, there are few times when you would want to (or that a random user would assume it is.)
It is best to treat wallet keys separate from accounts.
Note: This doesnât mean wallet keys could not be generated from account keys in a similar way as hierarchic wallets (the above mentioned BIP32) work for bitcoin; I do believe thatâs a great idea, worthy of reuse.
In the Dev branch of the Core both, StructuredData and Appendabledata, not longer exist and have been replaced by MutableData so work only with MutableData seems the most intelligent.
I am of the opinion that having the wallet address the same as the public/private ID allows greater simplicity in that people can send you coins by just knowing your public/private ID. Also you can simply generate a throwaway public/private ID and use it to send** coins anon to another wallet.
** firstly you would send the coins to the throwaway wallet (public/private) ID address then send those coins anon to another person. If you didnât then the previous owner would not be the throwaway ID.
