Dialyzer is a static analysis tool that identifies software discrepancies, such as definite type errors, code that has become dead or unreachable because of a programming error, and unnecessary tests, in single Erlang modules or entire (sets of) applications.
Objective
To integrate Dialyzer into the development toolset.
Some XDR constructions are not properly located, since there is a standard to organize these XDR files a good enhancement is to group files in the same way Stellar does.
Objective
To re-organize files and use the grouping mechanism used in stellar-core
XDR, also known as External Data Representation, is used throughout the Stellar network and protocol. The ledger, transactions, results, history, and even the messages passed between computers running stellar-core are encoded using XDR.
Objective
To build the XDR types and implement their encode/decode functions.
Implement the account ledger entry extension V2 type, which records sponsorship related information.
The sponsorship mechanism deals with a security flaw with the payment of account reserves. Details on this feature can be found at https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md.
Checklist
AccountIDList A list of account IDs required to hold a reference to an account's sponsors
Stellar uses signatures as authorization. Transactions always need authorization from at least one public key in order to be considered valid.
Transaction signatures are created by cryptographically signing the transaction object content with a secret key. Stellar uses the ed25519 signature scheme.
Objective
To implement an Ed25519 algorithm that allows encoding/decoding/deriving key pairs and signing transactions.
Checklist
#17 KeyPair behaviour + Default Ed25519 functions. (This will allow people to use their own crypto module)
Looking for a specific XDR type nested in a parent file (Integers, Unsigned Integers, Opaques) is hard. As part of keeping an organization code across the project, it is a better approach to hold every XDR type into its own file.
Making an OSS project public at an early stage is a really important step, no matter the outcome, working in public is a gift for the community. With every commit, comment, and pull request, we are creating opportunities for others to learn, grow and contribute.
Objective
To release the initial library version and make the repository public.
Since other libraries may be written on top of the stellar_base, the Stellar namespace may cause conflicts and compilation warnings when used by multiple libraries. Using a non-blocking namespace like StellarBase may help with this inconvenience.
Domain-specific functions are required when implementing Stellar signatures, this is not a responsibility of the StellarBase library but the StellarSDK.
Objectives
To remove the Ed25519 keypair implementation.
To add encode/decode functions for Signatures used in the Stellar network.