W3C home > Mailing lists > Public > public-webpayments@w3.org > May 2015

Re: modeling wallets

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Sun, 17 May 2015 12:16:39 +0000
Message-ID: <CAM1Sok2BH_G++J4nGWK0MPJixRj-Uumf259tXAfJFHFPdEs3Vg@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>, public-webpayments@w3.org
If users can issue their own credentials, wouldn't they be able to
establish their own ledgers?

Otherwise, +1

Web has an identity problem, which is v.complicated, especially for
grandma, or the newborn.

Don't want to spend another (?)x000+ hours on it.

I'm also sure what Melvin is attempting, will contribute...

Whatever that is, overall.

Yet, credentials imho, needs implementations that are more accessible, ie:

Perhaps also objections exist that I'm not aware of.?


On Sun, 17 May 2015 at 11:55 am, Manu Sporny <msporny@digitalbazaar.com>

> On 05/16/2015 09:22 PM, Melvin Carvalho wrote:
> > <Alice> <com:account> <Alice:#account1> <Alice:#account1>
> > <com:currency> "USD". <Alice:#account1> <rdfs:label> "Party Money".
> > <Alice:#account1> <com:ledger> <Alice:#ledger1>
> >
> > I'd been using DCT : description for the "Party Money" part, I can
> > switch to RDFS label, that looks better.
> IIRC, we chose rdfs:label because it was more "low level" than
> dct:description in that it was a part of the core RDF stack. Either
> should work just fine, but it would be nice to know why dct:description
> essentially duplicates the RDFS term.
> > I've been thinking quite a bit about ledgers based on accounts and
> > ledgers based on users.  My current conclusion is that I'd like to
> > try both.
> We used com:account primarily because we needed to group other things w/
> the abstraction (name, currency, etc.). Not all accounts have ledgers,
> so that also influenced our decision to use 'account'.
> > The issue with user based ledgers is that they need a default
> > currency, so I've selected bitcoin for that.
> I don't think you need a default, do you? You can just assign a currency
> to the inbox?
> > My idea for a wallet so far is that it points to an API which allows
> > the user to be input as a query string.  Then it has an inbox where
> > there user can send transactions based on their user name.  One inbox
> > per user.
> The PaySwarm API abstraction level is a bit more low level - one API per
> ledger/account. So, restructuring the previous example:
> <Alice> <com:account> <Alice:/account1>
> <Alice:/account1> <com:currency> "USD".
> <Alice:/account1> <rdfs:label> "Party Money".
> <Alice:/account1> <com:ledger> <Alice:/account1/ledger>
> <Alice:/account1/ledger> <com:api> <https://w3id.org/apis/ledger/v1> .
> > One thing that seems to be slightly different is that I would
> > consider a wallet to be a container of many accounts/users, but can
> > be used with one account/user.
> >
> > <Alice> <cc:wallet> <Alice:#wallet> <Alice:#wallet> a cc:Wallet
> > <Alice:#wallet> <rdfs:label> "Main wallet at ACME inc".
> > <Alice:#wallet> <cc:api> <http://acme.com/api/v1>. <Alice:#wallet>
> > <cc:inbox> <https://acme.com/etc/wallet/>.
> Yeah, that's another way to model it. I think we chose to say an account
> can:
> 1) have multiple entities that have access to it
> 2) have N ledgers, but most likely it'll be 1 for most transactional
>    mechanisms
> We avoided the whole "wallet" modeling approach because it seemed more
> like a "UI" thing than a fundamental modeling thing. For example, a UI
> could use the concept of a wallet to group multiple accounts together,
> but that would have no functional changes on how one would access
> accounts and ledgers.
> > The fields above are still very experimental, and I'd be happy to
> > change them.  Just trying to get a prototype working and reusing some
> > common patterns.
> +1 - let us know how it goes. Interested to hear how the "user based
> ledger" concept pans out.
> -- manu
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
Received on Sunday, 17 May 2015 12:17:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:40 UTC