Jump to content


Coil Employee
  • Content Count

  • Joined

  • Last visited

About justmoon

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    San Francisco
  • Occupation
    Founder at Coil
  • Country

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It's any->any. Of course, the client can refuse to pay if they so choose. In practice, Minute will pay any site and Coil will pay any site in compliance with our Terms of Service. To be clear, there is no such thing as a "Minute meta tag". There is only the standard Web Monetization meta tag which is supported by Minute, Coil, and hopefully many others in the future.
  2. Hey all - I wanted to follow up to report that we've just released our new Terms of Service and Privacy Policy. We've incorporated quite a few changes, many of which were specifically intended to address issues raised in this thread and I'd be interested to hear your feedback. We've gone through the entire set of policies and clarified sections that were confusing before. We didn't intend to collect any data that isn't directly necessary for providing the service and neither did our external legal counsel who drafted the original policy. But due to a combination of legal jargon and poor wording, it sounded like we wanted to collect and even share information that in reality we have no interest in whatsoever. Keep in mind that to us, any data we collect from you is a pure liability - we don't make any money from it, we have to spend money to protect it from hackers, and if it makes someone think twice about signing up, we lose out on that revenue. The bottom line is that we spend a lot of time finding ways to collect less, not more. You may have seen our new passive Web Monetization meta tag - by switching from JavaScript to a meta-tag, we avoid calls to our server to fetch the JavaScript which would cause us to have more data to worry about. You can expect us to make more changes in that direction in the future as we improve the technology. Other changes in the policy are related to compliance (IRS form 1099, requirements from credit card processor) but once again, we'd much rather not collect anything because it just creates additional work and risk. So we did our best to describe as precisely as possible what we need to collect in order to comply with all applicable laws and regulations. We've also clarified what constitutes abuse of our platform. Most of these restrictions are driven by either legal restrictions (e.g. gambling) or risk-based restrictions (e.g. adult content) that our payment processor or the credit card network mandates. I would point out that Web Monetization is fundamentally open technology, so if you want to use it for (legal and ethical) purposes outside of our Terms of Service, you're free to bypass Coil and use the open-source implementation, Minute. We intend Coil as a platform to make Web Monetization available to a wider audience beyond crypto and lot of that audience uses credit cards today. Once again, I'm very interested to hear your feedback and we're committed to continuing to improve our policies in the future. It has been absolutely amazing to work with the XRP community and all the help that we've received during our closed beta so far.
  3. Hey all - thanks for the feedback, especially for breaking down the doc and highlighting the problematic sections. I just read through the thread and will be looking into this. The ToS were prepared by our external counsel and I wasn't part of that process, so I'll find out why those terms were included and if we can take them out. There may be some justification that I'm just not aware of. We have zero interest in selling user data or running ads - those are crappy, backwards ways of making money and the whole point of Coil is that those monetization workarounds are no longer necessary. We are paid directly by our users, so we don't need any other revenue stream. Expect a more full-fledged reply once I've had a chance to meet with the lawyers.
  4. > I think there is still lot of work to do in this area, because the actual condition is a big drawback in comparison with BTC and other "standard" blockchains. I don't agree with that at all. XRP Ledger provides provable safety with > 41% overlap under the Byzantine accountability condition. (See page 13 in the RCA paper.) Bitcoin does not provide safety at all even under Byzantine accountability. Safety means that different nodes don't see different versions of the blockchain. This is just not something that Bitcoin offers. In fact, safety is violated on Bitcoin in practice all the time. That's why people wait for multiple confirmations on Bitcoin, but don't on XRP Ledger. Further, if you assume the stricter attack model without Byzantine accountability, the one where RCA requires 90% overlap, then Bitcoin's situation becomes even bleaker. An attacker that has that much control over the network can make you see any blockchain she wants, regardless of how much hashing power she controls. In other words, Bitcoin still provides no safety under that model whereas XRP Ledger/RCA provides safety for nodes with 90% UNL overlap and Cobalt provides safety for nodes with 60% overlap. I'm not saying Bitcoin isn't viable just because it doesn't provide this theoretical notion of "safety". Real life is a lot more forgiving than the world of theoretical safety proofs. But if you want to make comparisons, they should be using the same definitions and assumptions. If you're going to cite this paper and say that RCA "safety requires 90% UNL overlap", then you need to be clear that Bitcoin "does not provide safety" using the same definitions and assumptions. So if anyone has catching up to do, it's "standard" blockchains.
  5. When it's ready. We want to make sure that it's in a state where there is enough documentation and tooling that people can usefully experiment with it.
  6. So happy that this idea is finally out there. It's been a hell of a project to work on for over a year and not be able to talk about it. ILP did indeed grow out of Codius - we wanted a way to transfer money that was both network-independent as well as incredibly fast and scalable. I'm reading a lot of people asking about the future of XRP or RCL. We're not abandoning either; in fact this new architecture let's us really focus on XRP's primary use case as a bridge asset. Transactions through XRP will be available to a greater number of people if RCL can interface with other systems. We believe that ILP as a true protocol is much more likely to be widely accepted and adopted than RCL as a single network. As far as RCL is concerned - the most immediate impact from ILP is the addition of suspended payments. This feature (effectively ledger-based escrow; currently enabled on our testnet) allows RCL to participate in ILP payments. In the future you can expect us to work on improvements that extend RCL's lead as the fastest, most scalable and most secure distributed ledger in an ILP world. Thanks for all your support! We are very excited about the future of Ripple and ILP and can't wait to hear your thoughts from reading the white paper. - Stefan
  • Create New...