xrpl-dev-portal
xrpl-dev-portal copied to clipboard
Add client library guidelines
There are many libraries for use with the XRPL at various levels of maturity and completion. We should define a set of guidelines for getting a library listed on xrpl.org so that it's clear why some are accepted and aren't.
Related: #2100 and #2234.
Some incomplete thoughts on the matter:
- Scope: It should probably implement serialization, signing, at least basic transaction submission, and some kind of API request interface. It should be possible to submit any transaction that's valid on Mainnet and call any public API method.
- Native interfaces & models are a nice-to-have, as are conversion functions, i.e. XRP-drops, timestamps, flags, and hex to ASCII, and utilities for stuff like reading metadata, create crypto-conditions, tx submission, etc.
- There are a lot of gotchas in managing XRPL keys / signing to look out for.
- We can point to xrpl.js as the gold standard in functionality
- Responsibility: It should not have obvious/major security holes, it should receive regular maintenance (updates at least every, like, 6 months or more?).
- Naming and stuff should not be misleading, unprofessional, etc
- Preferably the repo should have a widely known open source license like ISC, MIT, GPL, or Apache, and a code of conduct.