Re: modeling wallets

On 17 May 2015 at 00:50, Jorge Zaccaro <jorgezaccaro@gmail.com> wrote:

>
> On Sat, May 16, 2015 at 7:17 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>> During my implementation of a proof of concept for virtual wallets, ive
>> been trying to lock down the concept of wallet.
>>
>
> Is there a link to the implementation/demo?
>

I've learnt the hard way not to publicise alpha code to a general audience
before it's finished, but all my work is public under MIT license, ill be
happy to share with other implementors-list


>
>
> "A wallet is a container of money"
>
>
> +1. However, I agree with Timothy, not only 'of money'. I rather think of
> wallets as containers of credentials (e.g. identity, payment).
>
>
>
>> #user   namespace : wallet  <URI>
>
>
> I totally agree. Regardless of the definition of wallet, everything should
> start with a wallet URI. Then you can access to the attributes/details of a
> wallet by appending different endpoints, or navigate to related resources
> following the links embedded in its representation. The way I model wallet
> URIs in the API specification I'm working on (outdated spec
> <https://github.com/playbanq/WebWalletAPI#what-is-a-webwallet>, current
> spec (in progress)
> <https://github.com/webwallet/swagger/blob/master/swagger.yaml>) goes
> something like this:
>

This is really neat!


>
> Host: wallet.example.com
>
> /address
> /address /*walletAddress*
> /address /*walletAddress */balance
> /address /*walletAddress */balance /limits
> /address /*walletAddress */balance /limits /upper
> /address /*walletAddress */transactions
> /address /*walletAddress */transactions /count
> /address /*walletAddress */transactions /*transactionID*
>

We're thinking along the same lines, I think.  Where I may differ slightly
is as to the container / content boundaries.  I'm particularly careful to
use an HTTP document as a container of content, and not a concept in
itself.  This is because I can then monitor things like the request state
of the document, when it was last accessed, the etag etc. without confusing
it with the data.  I suspect this is going to be the magic sauce when this
work goes to production, at least, that's my bet.


>
> (Different verbs are used for performing different actions on the same
> endpoint. For example, GET /transactions would retrieve a list of
> transactions, while POST /transactions would send a transaction (request)).
>

I use GET to get balances, initially ive started with PUT to create a new
tx, but im moving to POST in the next few days.


>
> In this context, a wallet would be a container of such addresses (i.e.
> wallet account ≠ wallet address).
>

>From a modeling POV

The first challenge is going from a user to a wallet.  Of course the user
may have more than one wallet.  So what do you think the predicate should
be called?

1. Alice  wallet  <URI>
2. Alice hasWallet <URI>
3. Something else

I'm working on the assumption of (1) at the moment.  Notice at this point
the idea of wallet and payment processor for me I dont think matter.

Presently in the wallet file I have a link to a description, an api and an
inbox, tho these fields I suspect will be in flux over the next few days