Jump to content

Search the Community

Showing results for tags 'documentation'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • XRP
    • Please Read Before Posting
    • Press
    • General Discussion
    • Technical Discussion
    • Codius and Smart Contracts
    • Marketplace
    • Problem Solving
  • Interledger Protocol
    • Interledger Protocol Discussion
  • Other Technology
    • Alt-Coins and General Fintech
  • More
    • Fan Submissions
    • Off-Topic
    • Meta
    • Languages
  • Canadian Zerpers's Topics
  • Vegemite Ripplers's Topics
  • 2 the Moon! For Real. The Club's Topics
  • NY Zerpers - aka bitlicense island's Topics
  • Brackish Waters Club's Topics
  • Trading Places's Topics
  • Anti-Club Club's Topics
  • The Irish Brigade's Topics
  • Saloon's Request
  • XRP Trading And Price Speculation's Topics
  • The Crypto Buffett's Topics
  • Alt-Coin Trading And Price Speculation's Topics
  • Super serious Ripple club's Topics
  • Making Millions!'s Topics
  • Ripple - India's Topics
  • SWELL's Topics
  • Gospel Hour's Topics
  • Korean XRP Holders's Topics
  • Strayans lovin your work XRP!!!'s Topics
  • Technical Analysis (TA) Area's Topics
  • BTC diving deep club's Topics
  • Ripple Enamel Pin Club's Topics
  • XRP Wave Surfers's Topics
  • FUDster's retreat's Topics
  • Cooking with Snoopy's Topics
  • How it's all going to happen..'s Topics
  • Chocolate Fish's Topics
  • The Round Table's Topics
  • UK Hodlers's Topics
  • ˜”*°• Zerpmania •°*”˜'s Topics
  • XRP YouTube Videos's Topics
  • CRY ROOM's Topics
  • Night's Watch's Topics
  • CasinoCoin's Topics
  • XRP Think Tank's Topics
  • Allvor's Topics
  • NightClub's Topics
  • TeXRP's Topics
  • COIL Think Tank's Topics
  • Bob's Book Club's Topics
  • XRP FAQS's XRP Q an A’s

Calendars

  • Ripple Events
  • Vegemite Ripplers's Events
  • NY Zerpers - aka bitlicense island's Events
  • Brackish Waters Club's Events
  • Trading Places's Events
  • Anti-Club Club's Events
  • The Irish Brigade's Events
  • Saloon's Calendar
  • XRP Trading And Price Speculation's Events
  • The Crypto Buffett's Calendar
  • Alt-Coin Trading And Price Speculation's Events
  • Super serious Ripple club's Events
  • Making Millions!'s Events
  • Ripple - India's Events
  • SWELL's Events
  • Gospel Hour's Events
  • Korean XRP Holders's Events
  • Strayans lovin your work XRP!!!'s Events
  • Technical Analysis (TA) Area's Events
  • BTC diving deep club's Events
  • Ripple Enamel Pin Club's Events
  • XRP Wave Surfers's Events
  • FUDster's retreat's Events
  • Cooking with Snoopy's Events
  • Chocolate Fish's Events
  • The Round Table's Events
  • UK Hodlers's Events
  • XRP YouTube Videos's Events
  • CRY ROOM's Events
  • XRP Think Tank's Events
  • Allvor's Events
  • NightClub's Events
  • TeXRP's Events
  • COIL Think Tank's Events
  • Bob's Book Club's Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Interests


Location


Occupation


Country


Ripple Address


Biography


Location


Interests


Occupation

Found 13 results
Minimum search term is 4 characters long. Can't find what you want? Click here for the custom google search instead.

  1. The XRP Ledger dev portal is not just moving to new digs, it's got a new philosophy. It's not Ripple's site, it's the XRP Ledger's site. (We're just helping.) Check out the new site and get BUIDLing! https://xrpl.org/
  2. We recently launched a new interactive tutorial on the XRP Ledger Dev Portal, showing how to Monitor Incoming Payments with WebSocket. It has JavaScript examples that don't use ripple-lib, so you can hopefully adapt them to other programming languages. (In fact, if you do go through the exercise to re-create any of the sample code in other programming languages, please contribute your code samples back using the "Edit on GitHub" button on the page!) It has interactive sections that let you connect to a public XRP Test Net server using WebSocket, and subscribe to transactions affecting a particular account, and summarize how much XRP they delivered. (You may need to use the Transaction Sender to actually send some payments while you're monitoring.) I hope this guide is useful and easy to understand. We welcome your feedback, so I'd love to hear from you if you find the docs useful, confusing, or if you have ideas for how to improve them!
  3. We've launched some new items on the dev site hopefully providing great value to those who want to receive transactions in the XRP Ledger. (More on that still in the queue.) Transaction Sender - A new interactive tool that automatically provisions some test net addresses and lets you send transactions of various types to the test net address of your choice. You can use this to, among other things, test how your systems handle incoming partial payments, TrustSet transactions, etc. Look Up Transaction Results - Vastly expanded from the previous docs, this page now talks about how to know when a transaction's outcome is final and how to read transaction metadata to see what a transaction actually did. Transaction Metadata - Now finally describes all the stuff that can appear in the "AffectedNodes" array, including some of the weird edge cases that can trip you up when you write processing logic.
  4. The Ripple Dev Blog has moved. The new blog location has been inaugurated with a feature article about Interledger, and we plan to continue posting new blog articles at a higher rate than we previously have. *crosses fingers* Check out that Interledger article here: https://developers.ripple.com/blog/2019/interledger-checkin.html If you have any technical topics you'd like us to cover or other things you'd like to see from the Ripple Dev Blog, feel free to reply here and we'll do what we can to address them. (As usual, we cannot provide financial advice, forecast moon when the price of XRP, reveal confidential info about partners, comment on litigation, etc.) We can and are happy to talk about open source technology, the XRP Ledger's many features and potential uses, and provide insight into where Ripple's devs see fintech going in general over the next few years.
  5. With just a few clicks, you can experience the process of sending (test net) XRP, alongside code samples and details of how to use RippleAPI for JavaScript to do the same: https://developers.ripple.com/send-xrp.html As always, we welcome your feedback and questions.
  6. I've created a proposal for a file that would replace the old "ripple.txt" way of reporting information about how you use the XRP Ledger. (For reasons including the fact that "XRP" isn't "Ripple"!) If adopted, I expect this could be a key piece in how validator operators verify their identity, and may also be useful for client applications for various other purposes. (For example, if the owner of an XRP Ledger address is verified, client apps could show provided contact info or description alongside that address.) For people who run validators or actively develop tools and applications on top of the XRP Ledger, your feedback is very important because this spec doesn't serve a purpose unless you find it useful! If you fit that description, please take a look and provide your input on the draft specification here: https://github.com/ripple/ripple-dev-portal/pull/507
  7. ... and that means the Known Amendments page has been updated. rippled 1.2.0 will introduce (at least) 3 new amendments, which (if enabled following 2 weeks of support from 80+% of validators) introduce transaction processing changes. In this case, the changes are pretty small: fixTakerDryOfferRemoval fixes a bug where dry offers sometimes weren't properly removed when autobridging. Thanks to GitHub user demonstefan for contributing the code that eventually became this amendment! fix1578 makes fill-or-kill offers return a new tecKILLED code (as requested on this very forum) when they're killed. It also makes TrustSet transactions fail when they can't set the NoRipple flag, instead of "succeeding" without changing the flag. Both of these changes are meant to make the transaction engine just a little less tricksy. MultiSignReserve reduces the reserve requirement for signer lists so they occupy less XRP for just sitting there. Stay tuned for more information about the upcoming release and the features in it!
  8. Salutations! We've published new documentation to the XRP Ledger Dev Portal! These changes include: List Your Exchange on XRP Charts - New guide for exchanges that want to see their volume show up on XRP Charts. https://developers.ripple.com/list-your-exchange-on-xrp-charts.html Ledger History - Explainer for the history that servers store and the options that exist around this. https://developers.ripple.com/ledger-history.html Online Deletion - Info on why and how the online deletion feature of `rippled` works. https://developers.ripple.com/online-deletion.html Plus, no less than three new tutorials around ledger history and deletion: Configure Online Deletion: https://developers.ripple.com/configure-online-deletion.html Configure Advisory Deletion: https://developers.ripple.com/configure-advisory-deletion.html Configure Full History: https://developers.ripple.com/configure-full-history.html As always, we welcome feedback and contributions. If these docs helped you, or if you need help figuring them out, we'd love to hear from you!
  9. We've recently published two new articles to the XRP Ledger Dev Portal, both discussing the subject of Consensus: Introduction to Consensus is just that—a beginner level summary of Consensus in the XRP Ledger. Hopefully this can help new people pick up enough to get up and running with the XRP Ledger without getting as deep into the weeds as the older, more detailed consensus article. Consensus Protections Against Attacks and Failure Modes is a new FAQ-like article that discusses some of the various threats to the XRP Ledger and how it's set up to handle them. There's also a new blog post @JoelKatz shared on the Ripple Insights Blog: The Inherently Decentralized Nature of XRP Ledger. This one talks about the future of XRP decentralization and why the lack of mining is good for the network. (Forewarning: I think this article can be a little confusing when it switches between talking about the total number of validators and the trusted validators that most of the network pays attention to.) If you find these articles helpful or interesting, we'd be happy to hear it! And if you're befuddled or want to know more, please ask away. More importantly, I hope that building a better understanding of the XRP Ledger and its greater ecosystem can help you make more informed choices in the future, especially if you choose to contribute to the Internet of Value!
  10. Last night we added several new pieces of documentation to the XRP Ledger in preparation for the upcoming release of rippled 0.90.0: Deposit Authorization is a new feature for compliance with regulations such as the New York Bitlicense. In addition to the concept page, the flag has been added in appropriate places such as the AccountSet transaction reference. Checks documentation has been added to the transaction reference and ledger reference. Checks are a feature originally conceived back in, like, 2012 or something, which got new life recently when we realized they'd solve one of the challenges with Deposit Authorization. We also added specific instructions for how to build and run rippled 0.90.0 and higher on Ubuntu Linux. That's important, because rippled 0.90.0 must be compiled against the latest version of Boost, which now includes Vinnie Falco's Beast library (originally developed to use in rippled). There'll be more coming out in the coming days, including an article on another key 0.90.0 feature, history sharding. I can't give a specific release date for 0.90.0, but the feature set is final, as we're just now polishing up the details and ironing out the bugs. As per usual, it'll be out soon—when it's ready—and no sooner. P.S. if you want to try out Checks and Deposit Auth leading up to the release, they're already available for use on the Test Net.
  11. Just today I published the documentation for a bunch of new feature stuff that's coming in rippled 0.31.0. (Right now we're still tracking down the last few bugs in the release candidates, but the feature set is finished and the release will be out probably any day now.) It's been a long road for multi-signing in particular, with the first preview promising that it was "coming soon" as of March 24, 2014. Yeesh! But this time, we really mean it: multi-signing is getting real. We're not... quite... there yet, though, and part of the reason is that 0.31.0 is the first time we're going to truly use the Amendments system for rolling out new network features in a decentralized fashion. This is a big step in our roadmap towards encouraging a decentralized web of trust in the validation network, because it means that the network will be able to smoothly roll out new features without interruptions or a central authority managing them. You can read more about Amendments on the Ripple Dev Center. But! There's one other thing before Multi-Sign happens, and that's an amendment called "Fee Escalation." We haven't talked it up as much, but this change has also been in a long time coming. A while back, you may recall that the cost to send a transaction increased from a typical price of of 10 drops to 10,000 drops of XRP. That's because we realized that, with the network as it was, it had become possible to intermittently DDoS the network without spending a fortune in XRP -- the transaction cost reacted slowly enough to changes in conditions that the network was already in trouble by the time the costs became unbearable. For many months, we've been running our validators with a band-aid fix, with the "load" multiplier artificially cranked up to 1000× in order to maintain network stability. That's why the first Amendment we support will be Fee Escalation -- a change that makes it actually possible to pay a higher transaction cost to make sure your transaction gets processed sooner. Now, when there are a lot of transactions in the current ledger, the server will start queuing up additional transactions for the next ledger instead of trying to squeeze them all in at once -- and the order will be determined by how much XRP those transactions destroy. Not only that, but you can still squeeze into the current open ledger if you pay even more XRP -- but the requirement scales exponentially, so it won't be worth it for long! The long and short of it is that the network should be more resilient against DDoS attacks, while affording more flexibility in the amount of XRP you spend sending transactions (based, presumably, on how urgent your transactions are). With any luck -- and this is not a guarantee, but I'm pretty sure it'll happen -- we'll be able to turn off the artificial "1000×" load knobs and return the minimum transaction cost back down to a truly miniscule amount. See the "Open Ledger Cost" section in the documentation for the details. That finally brings us back to Multi-Signing. It's going to be a few weeks out even after the release gets finalized, so you'll have plenty of time to figure out how it works in order to start multi-signing the instant the feature goes live. In fact, if you're really excited to try it out, you can practice how to multi-sign a transaction using rippled in stand-alone mode. You can also test out other stuff in stand-alone mode, without having to interact with the real network, whether you want to replay old ledgers or test out new features. (Stand-alone mode is not a new feature, but the new documentation should make it much easier to use.) This has been a big project (over 40 commits just to documentation!) and there are a few more changes not even mentioned here. (There might even be some minor improvements to rippled 0.31.0 that haven't made their way into the docs yet.) So, let's not quite declare victory before the release is live -- but get your funny hats and party poppers ready, because version 0.31.0 is going to be a big deal. As always, feedback is deeply appreciated, and I'm glad to offer clarifications for anything that doesn't make sense to you. And, just like rippled itself, our documentation is open-source, so you don't have to be a Ripple employee to contribute!
  12. It's probably no surprise to the people here, since RippleAPI has been available for a little while, but here's the official announcement about the release of RippleAPI: https://ripple.com/dev-blog/introducing-rippleapi/ tl;dr RippleAPI is the merger of Ripple-REST and ripple-lib, it's way better than those two were, we're not supporting the old stuff anymore, and you should check out the brand-new Beginners Guide in case you're not sure how to get started with RippleAPI.
  13. Just published last night: https://ripple.com/build/freeze/ This new documentation is more accurate (no more typos of who's freezing whom, which is something that persisted in the wiki article for like a year), more thorough, reviewed by technical experts, and even includes functional code samples for the new RippleAPI. Of course, the Freeze feature itself is over a year old, with no significant changes since then, so this is hardly news. But I still think it's worthwhile to share our ongoing efforts to clarify and improve understanding of the Ripple Consensus Ledger rules and rippled software as it exists. If there are any points in the documentation that are confusing or seem inaccurate, let me know and I'd be glad to clarify!
×
×
  • Create New...