- From: Nathan Rixham <nathan@webr3.org>
- Date: Fri, 3 Jun 2016 18:05:17 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Web Payments CG <public-webpayments@w3.org>, Manu Sporny <msporny@digitalbazaar.com>
- Message-ID: <CANiy74y=V+kLysgsrwsHB2G_-K4PTBKeYCAevFkQodAEomP3zg@mail.gmail.com>
Also, currency uri rather than literal On 3 Jun 2016 5:10 pm, "Melvin Carvalho" <melvincarvalho@gmail.com> wrote: > > > On 3 June 2016 at 17:14, Manu Sporny <msporny@digitalbazaar.com> wrote: > >> We're releasing some preliminary R&D work on generalized Web-based >> decentralized ledgers today. This is the first public announcement about >> the technology that we've made. >> >> Problem Statement: Current Blockchain solutions (aka decentralized >> ledgers) are fairly rigid, coupling many implementation details to the >> data model. This results in various hacks to shoe-horn data into the >> blockchain, side-chains, and a very high barrier to entry to when >> launching new decentralized ledgers. >> >> We claim that it would be useful to decouple: >> >> 1. the data model (what is stored) >> 2. the operational model (how you decide what is stored - e.g. >> consensus/proof-of-work mechanisms), and >> 3. the access protocol (how you access/append to the ledger) >> >> The work we're publishing today is primarily about #1 above (the data >> model). We're loosely calling this technology "Flex Ledger", or "Flex" >> for short. It is incredibly rough and experimental, but we're releasing >> early and often in order to keep this community in the loop. >> >> By decoupling data, operations, and access, we hope that decentralized >> ledger technology becomes more modular and thus easier to configure and >> deploy for different use cases. This enables a world where ledgers are >> very modular, letting people independently choose the best type of data >> to store in the ledger, the best consensus algorithm, and various other >> configurable options based on specific use cases. There may be thousands >> of different types of ledgers, just as there are millions of different >> types of websites that exist today. >> >> If there are no significant objections from the Web Payments Community >> Group, we'd like to fold this set of Ledger specifications into the work >> we're doing here (transferring ownership of the documents from Digital >> Bazaar to the Web Payments Community Group). >> >> The introductory portion of the Flex Ledger specification may be useful >> to those that want to get an overview of decentralized ledger >> technologies in general: >> >> http://digitalbazaar.github.io/flex-ledger#introduction >> >> There is also a Linked Data Vocabulary that formally defines what can be >> placed into the data model: >> >> http://digitalbazaar.github.io/flex-ledger/vocabulary.html > > > Looking at : > > "source": "https://example.org/accounts/jane/7", > "destination": "https://foo.com/accounts/bob/3", > "remoteLedger": "https://foo.com/ledgers/blah/3445", > "transfer": { > "amount": "23.45", > "currency": "USD" > } > > > Having coded in this area Im super nervous about sending money to > documents (ie without a fragment ID). In this case ... jane/7 > > I strongly suspect this is an anti pattern and perhaps should be > considered harmful. Just consider, all possibly http headers (present and > future) that apply to this entity also apply to the entity you are > transferring money to. Is this not an accident waiting to happen? > > >> >> >> These specifications, a part of the "Credentials on Public/Private >> Linked Ledgers" project, has been funded in part by the United States >> Department of Homeland Security's Science and Technology Directorate. >> The content of these specifications do not necessarily reflect the >> position or the policy of the U.S. Government and no official >> endorsement should be inferred. >> >> -- manu >> >> -- >> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >> Founder/CEO - Digital Bazaar, Inc. >> blog: The Web Browser API Incubation Anti-Pattern >> http://manu.sporny.org/2016/browser-api-incubation-antipattern/ >> >> >
Received on Friday, 3 June 2016 17:05:49 UTC