Re: making the webcredits.org spec more strict about 'source' and 'destination' fields.

On 28 April 2012 12:53, Michiel de Jong <michiel@unhosted.org> wrote:

> On Sat, Apr 28, 2012 at 12:07 PM, Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> >> Good point, I should mark all the fields in the spec as mandatory.
> > Done.
>
> Great!
>
> Btw, i think amount should be an number value, not a string value? and
> how about making 'created' a date value instead of a string? Right now
> using strings instead of data types we're sort of violating the
> 'structured' star of 5-star open data.
>

very good point ... actually yes they should be float and date types, tho
actually I think that's already taken care of in the payswarm vocab (this
is the magic of @context in LD) .. i will double check this


>
> Still, i'm struggling with the vagueness of not the syntax but the
> meaning of a webcredit. you say that we should allow people to do
> produce semi-broken webcredits, and make the best of it. i have two
> questions for discussion though:
>
> 1) app A starts to willingly use mailto: URIs as currency, because its
> vendor knows app B errors on that. the users of app B angrily phone up
> the vendor, and app B blaims app A for diverging from the standard.
> Which app is at fault here?
>

sounds like a hack attempt ... it all depends on the laws in your
jurisdiction ... trying to make apps error is not to be encouraged and
could be considered criminal in some areas

financial law is a huge topic, and it's definitely not something web
credits spec wants to get deeply involved with, more a data format, that
other things such as auth, legal, contracts etc. can be layered on top


>
> 2) i buy your car, and give you a webcredit for amount: 2000,
> currency: 'EUR'. after a month you say 'hey, you still owe me 2000
> euros!'. i say 'no, who says so?'. you say 'the webcredit you signed
> does'. and i say 'that webcredit is in grains of sand. all my
> webcredits are. where does it say it was in euros?' you look up the
> spec, and effectively, it turns out that the webcredits spec treats
> the 'currency' field as 'it can be an ISO code', but nowhere does it
> state what that means.
>

as above, conflict resolution is out of scope ... trust is the third actor
in any transaction


>
> in other words, i propose adding something like:
>
> a webcredit is a document representing a credit, owed by the Source
> Agent, and owed to the Destination Agent, whose value is calculated by
> multiplying the Amount by the Currency.
>

nice wording ... tho it's not a document it's an IOU really ... IOUs can be
recorded on documents as in real life


>
> The Source Agent of a webcredit is:
> - if the "source" field is the URL of a document, then the agent
> described by this document (e.g. foaf).
> - if the "source" field is the URI of an interface, then the agent
> reachable through that interface (e.g. the user of an email address).
>

it's any URI ... so http is well defined ... perhaps we should give
specific guidance for each scheme in an implementors/examples doc

so a line for mailto: one for xmpp: one for tel: one for http:


>
> The Destination Agent of a webcredit is:
> - if the "destination" field is the URL of a document, then the agent
> described by this document (e.g. foaf).
> - if the "destination" field is the URI of an interface, then the
> agent reachable through that interface (e.g. the user of an email
> address).
>

I can definitely make wording changes based on that, to make the spec
accessible to a wider audience.


>
> The Amount of a webcredit is the number in the "amount" field.
>
> The Date of a webcredit is the date in the "created" field.
>
> The "comments" field is not meant to contain machine-readable content,
> although it might be used to remedy the absence of a  machine-readable
> 'intention' field.
>
> The Currency of a webcredit is:
> - if the "currency" field contains a 3-letter ISO code, the
> corresponding real-world currency.
> - if the "currency" field contains the URL of a document, then the
> currency described in this document.
> - if the "currency" fields contains the URI of an interface, then the
> agent behind that interface is free to choose and change the currency
> of the webcredit at any time (e.g. self-signed money issuing).
>

really all id expect as currencies to start with are things like:

EUR
or a currency from dbpedia

as things get more advanced you can have

derivatives
exotics
OTC contracts

I would not expect this use case for a while tho, but the URI system is
extensible arbitrarily


>
> The existence of a credit as described by a webcredit document does
> not preclude the existence of another credit between the same Source
> Agent and Destination Agent, except when the 'created' field also
> exactly coincides. There is no way to indicate that a webcredit
> represents a 'balance', so the credits represented by webcredit
> documents should always be treated as additive, and never as "[Source
> Agent] currently owes [Destination Agent] (only) [Amount] [Currency]"
>

I thought about balance but that's out of scope.  It's easily modeled by
systems that want to do that.  But given that I could have many sources for
IOUs (eg public and private) the balance is not always known in an open
world.

The ability to have a private wallet (eg security by obscurity) is an
absolute must for data freedom.


>
> There is also no field for 'intention' or 'gesture', so deriving
> rights from e.g. the fact that someone signed a webcredit document is
> hard, unless something is said about intention in the comments.
> Possible interpretations (it is recommended to add these in to the
> 'comments' field:
> LOAN:
> "I will pay you back without delay"
> "I will pay you back if at a later time I have the money"
>

Yes, workflows are out of scope, since there are so many possibilities and
I want to spec to be 2 pages rather than 200 pages.

Workflows can be modeled in secondary structures.  Just as if you have an
SQL schema you'll probably have several table to do different things.  Web
Credits is a system to show you how to build the IOU table, and from that
you can extend it, using the same patterns, to do pretty much anything you
want.


> BUDGET:
> "This credit is earmarked and reserved specifically for travel costs.
> I will pay you up to the quoted amount, but only in recompensation for
> travel costs you may have due to X"
> "I have no intention to pay you back, unless you get into money
> trouble and call on me for help; then i'll remember this credit, and
> try to return the favour"
>
> GIFT:
> "I have no intention to pay you back, even if you ask me to, but I'm
> grateful for your gift"
>
> SALE:
> "this webcredit document represents the money i owe you for the blue
> Suzuki Alto you sold to me on date X"
>

as above ... there's many more ... including payswarm as a workflow,
opentransact, ripple, etc.