Vinnie

Ripple Employee
  • Content count

    55
  • Joined

  • Last visited

  • Days Won

    4

Vinnie last won the day on January 5

Vinnie had the most liked content!

About Vinnie

  • Rank
    Member

Profile Information

  • Gender
    Female
  • Country
  1. Is that from http://www.grpc.io/ ? Never heard of it before. Keep in mind, my area of expertise lies in the C++ side. Server more than client. So I don't have a lot of experience in these client side technologies. That said, I took a look at the C++ code in the repository (http://www.grpc.io/). Its not clear what interface it uses for networking. Seems not to use Boost.Asio. Of course, I am biased - I think anything worth using would be built on Boost.Asio since it tracks the Networking Technical Specification which will be part of the C++ standard at some point. And where' the HTTP parser? WebSocket code? RPC 2.0 at least is transport-independent. I guess I'm biased, the ideal RPC library for me will be one that is built on Beast
  2. Just to continue to refactor, streamline, and add features. More documentation. Ultimately I would like ripple-libpp to be its own library and not require the rippled subtree. Lean it out a little bit too. Just polish it up in general. We might want to add features for maintaining connection to RCL at some point in the future.
  3. This is awesome, do we know who wrote it? I have plans for building up ripple-libpp.
  4. Looks remarkably similar to Jed!
  5. Does Jed speak Japanese? Hmm...
  6. I don't understand why anyone thinks this shouldn't be discussed. RCL is a public ledger. I am glad that there is interest and energy going into studying the network's accounts, and the transactions taking place on it.
  7. I don't know the details of this, been busy integrating a newer version of secp256k1 and getting Beast ready for a Boost review. I read the Reuters article. It mentions "blockchain" but not any Ripple techs (ILP, RCL, XRP, etc...). Every asshole has "blockchain" (just look at the 100+ shit coins on coinmarketcap). I'd like to see more promotion of our unique techs.
  8. no, No, NO! I would be so pissed if someone did this, and I would imagine there are plenty of other people would would not want this either. As much as I dislike Jed's actions, blocking people in this fashion is completely immoral and violates the spirit of the network. It undermines trust in the ledger and constitutes abuse. Practically speaking it would destroy most if not all of the value of the currency. People would flee in droves, knowing that their balances could become worthless on a whim.
  9. oops, forgot to add that: * A hand-picked all star development team with over two centuries of collective experience.
  10. Talking only about XRP and not even mentioning the other cool features on RCL: * XRP transaction settles on the ledger in a matter of seconds * The fees for sending XRP are incredibly low * There's no artificial limit on the "block size" * RCL doesn't waste energy on mining * XRP is not involved in shady dark web markets or criminal activity * Its in Ripple's best interest financially to be a wise steward of the crypto-currency This is an important point, because of the large XRP position held by the company. There's been a lot of speculation about motives but if you think about it logically, XRP is a valuable asset and it would be foolish to sell it recklessly while holding large quantities. Its in the company's best interests to act in a manner that is ethical and productive - harming the community of XRP holders is not a viable long term plan. * Although RCL is still moving towards decentralization, its in Ripple's best interests to operate validators ethically Its in Ripple's best interests to make sure that RCL operates ethically and fairly. Taking action that runs contrary to the spirit of a decentralized system is again not a viable long term plan. Look at Ethereum, they forked the network because they didn't like one of the contracts. And this, from a system which is supposed to enforce "code is law?" * A hand-picked all star development team with over two centuries of collective experience. * RCL is backed by a company that can afford to pay developer salaries This last one is huge. Right now Bitcoin is going through a governance crisis. You've got the Core team which has been co-opted by Blockstream, they are paid by Blockstream, there's a massive conflict of interest. They won't increase the block size, and instead they are peddling this massively overcomplicated Segwit, for what appears to be ulterior motives. The opposing consensus is that they are intentionally limiting the performance of the Bitcoin system to make their commercial alternative (Lightning network) more appealing. And then you have bad actors which own all the social media for Bitcoin. The bitcointalk forum, the bitcoin subreddit, the bitcoin website, and the official bitcoin GitHub repository. Censorship rules the day on these sites. * Anyone can develop software that runs on RCL There's plenty of documentation on the wiki, and RCL is open-access. Want a better wallet? You can write it. Shopping cart? Nothing is stopping anyone from building applications that work with XRP. They can build exchanges, e-commerce applications, the sky is the limit. Has been from day one. I think that if you compare XRP to BTC at this moment in time, in many ways it is superior. As a pure cryptocurrency XRP has many appealing features. All this and we have not even said a word about the non-XRP features. I have also not mentioned any of the company's publicly stated plans such as ILP or the MM program (and these plans are great). If you look at XRP all by itself just with what's already there, its a great cryptocurrency and competes quite favorably with the others. XRP can fill all the use-cases that Bitcoin can, and do a better job of it for the reasons stated above. If people are excited about Bitcoin they should also be excited about XRP.
  11. No not at all, its the end of year so there are holidays, next year's planning, and management responsibilities. In other words some non-development work. Usually what you will see from me are alternating periods of intense rapid development followed by shorter periods with less activity. There's one last tough design issue in Beast before I can submit it to a Boost formal view (it's here: https://github.com/vinniefalco/Beast/issues/154). rippled is going to gain support for the WebSocket permessage-deflate extension (i.e. compression). All this library work will pave the way for some great improvements to rippled's server component (the part that serves JSON-RPC over HTTP and WebSocket). Lots to do, and I'm not going anywhere!