Safecoin Wallet requirements brainstorming

#1

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.
19 Likes
#2

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.

8 Likes
#3

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.

4 Likes
#4

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.

So in my mind optional is a must.

9 Likes
#5

Hi @bochaco

It seems like @Seneca was already experimenting with a wallet

9 Likes
#6

Hi @19eddyjohn75, it would be beneficial to hear @Seneca 's experience and input then to enhance the reqs. I’ll PM him also. Thanks!

4 Likes
#7

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

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)!

But Yay! SafeCoin Wallet!! :slight_smile:

5 Likes
#8

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

7 Likes
#9

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.

…sorry! Doing great work!!

7 Likes
#10

Not at all! I’m just doing some research before replying.

1 Like
#11

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

5 Likes
#12

Seems like a fine way to go, since that’s how SafeCoin does it automatically by default already anyway

#13

Yes, personally I think it should show your history by default. A clear and obvious ‘delete history’ button is enough imo.

3 Likes
#14

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

Some notes:

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

8 Likes
#15

It looks like your alternative will become the standard, because StructuredData and AppendableData will be combined into a new single data type, MutableData. I admire @Seneca coin mining, but maybe coins could also come into existence like they do now with Ethereum, send Ether receive coin, maybe we should also take that in to account if possible.

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

4 Likes
#16

I believe wallets should not be tied to accounts. Or, they could be throwaway, anonymous accounts, something like what BIP32 makes possible.

#17

we can do that anyhow, there will be throwaway public/private IDs, thus their associated wallet IDs can be throwaway (or not)

4 Likes
#18

Yea, I guess that’s the way to go.

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.

#19

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.

1 Like
#20

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.

4 Likes