Search the Community
Showing results for tags 'lets'.
Found 1 result
Minimum search term is 4 characters long. Can't find what you want? Click here for the custom google search instead.
Within the Ripple ecosystem, I have been attempting to account for personal credit and an individual's responsibility within social credit systems such as LETS and Time Banks built on the public RCL. Since each individual must trust each identifier on the network tied to a known person you trust, personal credit and the responsibility of the individual can cause their IOUs to default if that person is unscrupulous, whereas the individual attempts to sell social credit IOUs for another asset with the intent to never settle the issued IOUs. Therefore, if two individuals implicitly always trust each other to honour their social credit IOUs, but trust this individual or become trusted by this individual while rippling is enabled (which would make sense to assist path-finding) could allow honest individuals to become defrauded for their social credit and thus devalues the overall issuances of the LETS/Time Bank IOUs on the market. So far, I have come up with two technical solutions to this issue, but they don't even really sound good to me therefore I decided to open this discussion to gather feedback. Authorization by Default I believe that all Ripple accounts should have the asfRequireAuth flag set to true by default when they are created on the Ripple network. This solves the issue of credit rippling into accounts/markets where they should not to some extent. Individuals participating within LETS/Time Banking systems built on Ripple are still at risk of allowing trust to be issued to 'the bad guy' I provided within the thesis. Gateways which are not private gateways (individual offering social credit) simply set the asfRequireAuth flag to false if they wish to go public. Built-in Reputation System If Ripple is working with the W3C on the specifications of how RCL and ILP will play into the development of 'the internet of value' then these specification absolutely cannot be deemed completed until a Reputation System is built into the Ripple network. If Ripple is actively developing a system (attesters) for attempting to account for which validating servers you can trust to add within your UNL, then Ripple definitely has the team of people with the necessary passion, talent, and skills to reserve the currency code REP and attempt to solve for honesty within a trust-less system. I honestly cannot comment much about these technical details because I don't know about the necessary changes for this solution unlike I was able to postulate above: But DJS will probably know what to say about these suggestions so I would love to hear his input! @JoelKatz