concordium / concordium-java-sdk Goto Github PK

Implement the PeerConnect and PeerDisconnect endpoints.

Implement the GetBlockItemStatus query.

The java sdk does not provide many exciting examples.

The repository should also contain self-contained examples of using the sdk like e.g. https://github.com/Concordium/concordium-rust-sdk/tree/main/examples

The examples must be well documented as they serve as an introduction to use the java sdk.

Examples that must be covered

• Send a simple transfer from one account to another
• Send a memo transfer from one account to another
• Alias checker. Check whether an account address is an alias of another.
• Querying for block statistics (block info), e.g. from a starting time/block height to an end time/height.
• Find an account. I.e. given an account address find out when it was created on chain.
• Get the baker statuss of all bakers on chain.
• (When support for SC exists) Deploy, Initialize and Update a smart contract. The concrete smart contract should be https://github.com/Concordium/concordium-rust-smart-contracts/tree/main/examples/cis2-nft
• Setup baking and configure stake
• Setup delegation and configure stake
• ....

Today releasing and building distributions is a manual process.

This should be integrated into the existing CI for lowering the maintenance burden.

The java sdk makes use of a native rust dependency.

A release should build a distributable jar file including the native dependencies for each platform.
I suggest we focus building for macos, windows and probably only one linux distribution (e.g. ubuntu).

Task description

Add ability to check whether addresses are aliases, and to generate aliases to the SDK.

Implement the GetBlockItems query.

Implement the Shutdown endpoint.

Task description

The current README is a bit bloated and we should tighten it up.

In particular all the examples should no longer reside in the README, but instead it should refer to the examples that will be introduced as part of #152.

Currently the java sdk exposes ed25519 functionality via jni and a rust dependency.

Replacing this with a native java dependency would make it easier to build and distribute the sdk.

Example solutions each with their pros and cons.

• Upgrade the java version from 8 to 15 (java supports ed25519 as of version 15)
• Backport the jdk 15 ed25519 implementation
  https://github.com/openjdk/jdk15/tree/master/src/jdk.crypto.ec/share/classes/sun/security/ec/ed
• Other alternatives?

A new issue should be created for the actual work and implementation.

Task description

In the first round the java sdk will simply support smart contract parameters as raw bytes.
This is workable but it is not really the best user experience as the user is forced to build their parameters via the rust sdk and pass these over to the java sdk when calling update on a contract.

It will be very time consuming and also a significant maintenance burden to implement all of the types and their according serializations in the java sdk.

One other way could be to let the update contract take in a schema and then the user could as a start provide a json value, which then would be parsed into a proper byte array via a call to (a currently unspecified) rust library.

Implement SendBlockItem for a normal transfer with memo.

Implement the BanPeer, UnbanPeer and GetBannedPeers endpoints.

The SDK must support GetCryptographicParameters

Task description

The SDK must be able to handle the upcoming changes wrt. the new delegation feature.

New events that must be handled:

BakerSetOpenStatus
BakerSetMetadataURL
BakerSetTransactionFeeCommission
BakerSetBakingRewardCommission
BakerSetFinalizationRewardCommission
DelegationStakeIncreased
DelegationStakeDecreased
DelegationSetRestakeEarnings
DelegationSetDelegationTarget
DelegationAdded
DelegationRemoved

Implement the DumpStart and DumpStop endpoints.

The following types needs to be exposed in the API.

TransactionResultEvent
AbstractAccount

Task description

The SDK must expose smart contract functionality, in particular
deploying a module, initializing a contract and updating an instance.

Implement the GetNextUpdateSequenceNumbers endpoint.

The java sdk should support sending raw transactions i.e. the actual bytes.

Task description

The Java SDK should support the newest GRPCv2 interface that the Concordium node exposes.

The new service and type definitions can be found here.

The queries of the new GRPCv2 API in particular offers stronger types, and as such they are not required to be wrapped by custom Java types.

The SDK must remain backwards compatible, hence there should be introduced a new Client which makes use of the new API which users can opt into using.

Implement the GetNodeInfo query.

• Extend the ClientV2 class with a getNodeInfo function that returns the existing NodeInfo type.
• Unit test
• Extend the examples with a new one for acquiring the node info.

The java SDK should support P5.

• New Protocol
• New events emitted

Implement the GetPeersInfo query.

Implement SendBlockItem for a normal transfer.

The SDK should support importing mobile & browser extension wallet exports.

The user should be able to construct a TransactionSigner from an exported json file which in exchange can be used for signing transactions.

The import mechanism should support wallets exported by the browser wallet but also the genesis format.

• Overview of the current state.
• Planning.
• Investigate ways of implementing a 'better' caching layer.
• Determine tests and benchmark scenarios.
• Feature proposal description.

Task description

The V1 smart contract feature adds a few things to the API of the node that need to be handled.

Sub-tasks

• There are two new transaction events "Resumed" and "Interrupted". The Updated and Initialized events have an additional field "contractVersion" that indicates which version of the contract was updated.
• There is a new endpoint "InvokeContract"
• The format of "GetContractInfo" has changed. It now has a version field, and V1 contracts do not return the state.

The latter two tasks should be part of #20

The most urgent thing to address is the new events since the SDK currently does not handle smart contracts anyhow. If only one of the tasks will be addressed then the others should be split into independent tasks.

Implement the GetBlockChainParameters query.

Implement the GetBlockFinalizationSummary query.