You must surround yourself with super, dilligent people then
Thats why I accepted being a moderator here. Surrounding myself with such people.
Yup, there are numerous problems with the UX of this approach, so thatâs why we are not going with it at this stage.
I do like these options though
- new person creates their account offline and friend uploads and pays for it.
- âaccount tokensâ, where the new person buys (or is gifted) a âcoinBalanceâ and its added to their offline account creation and thus can create their account using some of the balance in that purchased âcoinBalanceâ
- this is very much like purchasing phone recharges where the recharge is purchased and the person enters the code and magically their phone account has more balance.
- The security is similar to the phone recharges as any company generating these âaccount tokensâ would be trusted not to abuse the sold tokens. Most likely generated by an APP and pin number secured.
- and obviously the person buying the coinBalance is warned to never use that coinBalance other than to pay for things and âthrow it awayâ when used up. The warning could be included in the account creation APP
Nope. Sorry, I wasnât clear. Seems like you already have the idea now, but to clarify some:
What could be considered an âoffline walletâ: The secret key is not stored on the network. (Although perhaps the terminology of âoffline walletâ itself is confusingâŚ)
Anyway, as mentioned above:
To receive money (as things stand), a CoinBalance (data struct at the address of a PublicKey) has to exist.
Via a wallet app we could (and perhaps would normally) save this, alongside secret key to be able to manage your money easily (encrypted / non public data). This would be considered an âonlineâ wallet.
At the moment not, but there could be scope for the SafeKey
struct to be create by the network as you suggest, upon receiving money if the SafeKey
doesnât exist. This for eg, would happen with a new vault farming success. So similar strategies may be applicable to payments. (Though if thatâs desireable or no is anotehr Q).
But the main crux of this invite is that the person generating doesnât store/see the secret key, and that this is communicated via the invite itself to the user, to then move/use the safecoin therein.
Iâve tried to follow these explanations without success, and donât have time to dig for now.
Would anyone like to write a simple explanation of the mechanisms chosen by Maidsafe to make it more readily understandable?
Iâd suggest first describing the UX as Jim has done, then explain how that works under the hood with some diagrams? Maybe one post for each on-boarding mechanism to keep each one easily digestible.
I think this would be very useful for all us geeks, and any new geeks, and help us field questions about this process as the network gains interest.
Iâm not sure dWeb Blog would be the best home for this, but Iâm sure we can find somewhere else if not, or if a blog post feels a bit much then a forum topic would be great.
@JimCollinson , @Neo Is there any way that a checksum can be baked in with an address, similar to Bitcoin adresses that have built-in checksum?
Very good video, it had a nice setting and your voice, tempo, are great, Jim.
The option with âstart a vaultâ had me thinking of some possible problem. if people for example only create a vault too create an account and then turned the vault of when they get the account, would that maybe cause uneccessary strain/load on the network, especially in the beginning of the networks life?
I was a little worried when Safecoin was mentioned because of that other project that use the Safecoin name right now, but when @Cgray mentioned that the video was not public that made me more calm.
David doesnât count.
For the options we are moving forward with, this shouldnât be an issue, not for onboarding anyway, as there is no exchange of address at all. A new user will simply have a link to click, or QR code to scan, and then they have the funding they need to create an account.
When it comes to making Safecoin payments after youâve got an account, then predominant method will be via sending to a SafeID, for which the user has a human readable address, a Name, an avatar, profile etc. all of which can be looked up prior to sending, and in summary for before confirming.
More to come on that in future videos
Nice of you to say so. Thanks!
There is motivation to earn more SafeCoins to be able to use the SafeNetwork. It may takes more days to even get enough to make an account, because infant = less reward or no reward ?
But child/adult earn more. The details are not clear, because details of farming reward are not yet confirmed.
Perhaps we could start with the options we are moving forward with for FlemingâInvites and Using a Vault?
I think I described the Invite one in reasonable detail from the UX point-of-view in the video, but essentially, generating an invite, creates a throwaway wallet, with a special safe-invite://
address, that has just enough coins in it to pay for an AccountPacket
.
The recipient of the invite clicks the link, with initiates the account creation process, moving the funds out of that throw-away wallet, and into the new account. There should be enough in there to get the packet on the network, with some left over to create a SafeID, save preferences, and a few other bits and bobs.
Until the invite is redeemed, it stays in this wallet that the benefactor could take the coins back from âwithdrawingâ the invite should they choose to do so.
Iâll let others chip in with the specific network level detail, but thatâs the gist of it.
When it comes to creating an account from a Vault, we are working on the nitty-gritty of that UX at the moment. Itâs defo on the more complex end of the spectrum when it comes to designing a nice, structured and understandable flow, but weâll share more of our ideas there when itâs more solid.
The general concept is pretty much as youâd expect though: I offer up some space on my desktop computer, start the vault running, and when I have some farming success and have earned enough, I have an account generated, and Iâm ready to go.
On this concept, weâd originally planned to allow benefactors to add additional funds to an invite if they were feeling generous, to give people more of a head start. That would facilitate the sort of flow you are picturing here. However, we stripped this back out, in order to reduce the complexity, and number of features for the initial version.
Once the recipient has redeemed the invite, and chosen credentials, they are straight into the next step of the on-boarding which is to create a SafeID
though, which then makes it super easy for a friend to send more Safecoin their way.
All these options are ok, but for those less technically inclined I foresee some selection fatigue and a feeling of being overwhelmed by choice with the current presentation.
Three choices for onboarding should be sufficient. KISS. Invites could provide a theme of exclusivity⌠not sure if that is really the attitude you want to project.
IMO a âusefulâ proof of work with an interface much like a glorified captcha would go a long way towards simplifying things.
Just for the avoidance of doubt, there will be just two options initially for new users: Invite or Vault (setting aside the MAID convertion as a separate thing)
A third might be added once interfacing with an exchange is possible, but even then it will probably be based on purchasing an invite with fiat.
The full list of 7 options were the concepts we started with, these were whittled down, and then a short list was built into a protoype UI (the initial screens you see in the video) specifically designed to test the viability of the options, and reduce the options further.
As we found out, some of those tested very badly (the wallets concept) so weâre activly working on that at this time.
But why not put your machine to actual useful work, Proof-of-Resource, by running a vault, and then buying invites for people with the proceeds?
Quick rapid fire response here:
Possible, maybe even likely, but we donât know that yet.
You will only get a reward if your vault has proved useful.
But in this case I was talking about you wanting to run a vault for altruistic purposes, by generating invites and giving them a way, like your faucet idea. Better to be providing actual resource to the network, and helping its resilience, than just burning energy.
Vaults will be desktop only for the time being.
Also, on the faucet idea, whatâs to stop one individual just draining the faucet and filling their wallet?
I think that thatâs what the hour of browsing while the device does some pow is for.
edit: misread, ignore me
Ah, maybe Iâve misunderstood.
It would be interesting to understand deeper why âtop up a walletâ was not so popular. It would probably be my, go to, method. Just fill the tank and letâs get rollin.
Folk just didnât grasp it, and certainly not in the way necessary for them to engage with it.
There were questions like, âbut if I donât have an account, how do I get it topped up?â and numerous folk said, âoh I just ignored it because I donât have a wallet, or an account yetâ. Users only actually start to get exposed to wallets balances etc after they have and account, BTW, so it was alien to some, and still not preferred even by those people with experience with crypto currencies.
And then there are the inherent difficulties of passing a small arbitrary file about on mobile devices, via the clear net channels. It all just adds complexity and length to the flow of an already borderline understandable process. So we pushed most of the interaction over to the existing user⌠letting the request and initiation come from the new user in a familiar clearnet or IRL channel, and then its fulfilled by a simple link that gets all the hard work done.
All participants really quickly understood how invites might work, with enough clarity to make it workable, and most and already used something similar⌠so this stark comparison was enough to help us jump for the more straightforward invite process, which also happens to be quicker to build too.