Service to announce aggregate bonded transactions

[dgarcia360]

Over time, I have noticed that newcomers have issues to work with AggregateBondedTransaction. Announcing them require to acknowledge well some concepts first, and when working with them always requires writing a considerable number lines of code.

Currently, announcing an AggregateBondedTransaction consists of:

1. Define the AggregateBondedTransaction
2. Sign the AggregateBondedTransaction
3. Define a HashLockTransaction
4. Sign the HashLock
5. Open a listener.
6. Announce (4).
7. When (4) is confirmed, announce (2).

To make the announcement more developer-friendly, we could define a service to summarize steps 5 to 6, which are the most challenging.

You can find here a possible first implementation without methods nor classes.

[fboucquez]

When listening to a transaction, the observable should be filtered out by transaction hash.

https://github.com/nemtech/nem2-docs/blob/master/source/resources/examples/typescript/aggregate/CreatingAnEscrowContractWithAggregateBondedTransaction.ts#L111

In a concurrent environment, one resued listener (one web socket) may be desired and another transaction for the same account may have been intercepted. Something similar could happen with errors, another transaction may fail and the error could be propagated to the wrong transaction listener. We may need to add the transaction hash to the error status message coming in the web socket.

Update: I have just realized you have added the hash check. Nice.

https://github.com/nemtech/nem2-docs/blob/master/source/resources/examples/typescript/aggregate/CreatingAnEscrowContractWithAggregateBondedTransaction.ts#L101

What about the status error message in case the transaction is incorrect? If we listen to the error the transaction will fail before timing out when invalid.

[dgarcia360]

What about the status error message in case the transaction is incorrect?

I see, we could check as well in the same Service if the HashLockTransaction announcement presented an error and throw an error if so. However, I wouldn't care much in the service if the aggregate transaction reached the partial channel or not. This could be done at a later point by polling or with listeners.

[evias]

I would even go with a service that permits 1 to 6 making HashLock something automatic that the user does not really need to do himself (but can change the fee for example).

class AggregateTransactionService {
    /**
     * Create an aggregate bonded transaction object that
     * needs signatures from given `cosigs` cosignatories.
     *
     * @return {AggregateTransaction}
     **/
    public createBonded(transactions, cosigs, networkType): AggregateTransaction {}

    /**
     * Sign an aggregate bonded transaction object with
     * given `cosigs` cosignatories.
     *
     * @return {AggregateTransaction}
     **/
    public signBonded(aggregate, cosigs): AggregateTransaction {}

    /**
     * Announce an aggregate bonded transaction object
     * with a hash lock of `spamFee` amount.
     *
     * :warning: The aggregate bonded transaction is only
     *                  when the hash lock transaction is confirmed.
     *
     * @return {Observable<Result>}
     **/
    public announceBonded(aggregate, lockFee?): Observable<Result> {}

    /**
     * Create a hash lock transaction with `lockFee` amount
     * and `aggregateHash` aggregate transaction hash.
     *
     * @return {HashLockTransaction} 
     **/
    public createLock(lockFee, aggregateHash): HashLockTransaction {}
}

Not sure about the Observable<Result> or what should be returned by announceBonded, I guess you may want BlockInfo for the hash lock to be returned there in combination with aggregate transaction hash/hash lock transaction hash?

@dgarcia360 @fboucquez @rg911 from experience with usage of aggregate bonded, announcing is definitely the hurdle. Cosignatures handling is easy when the partial tx was announced (just need to fetch "unsigned tx" from partial endpoint). Thankful for feedback on the service approach

[dgarcia360]

I would be more than happy to have a simplified service that does the following:

   /**
     * Announce an aggregate bonded transaction object
     * with a hash lock of `spamFee` amount.
     *
     * :warning: The aggregate bonded transaction is only
     *                  when the hash lock transaction is confirmed.
     *
     * @return {Observable<Result>}
     **/
    public announceBonded(signedAggregate:SignedTransaction, signedHashLock:SignedTransaction): Observable<TransactionAnnounceResponse> {}

• By defining the HashLockTransaction outside the service, devs will be able to configure them completely (duration, deadline, mosaic, amount).

• Treating transaction signatures outside, we avoid passing the Account object to the service, which contains the private key of the account.

[fboucquez]

Hey @rg911 @dgarcia360 @evias ,

This is my POC branch for the Java SDK. The idea and implementation can be easily ported to TS if you like it. It's not a PR yet as I need to validate it with you first.

My plan is having a TransasctionService that knows how to announce a transaction, "wait" to be completed/added or fail if there is a status error (All is async by piping/merging observables). This can work for normal transactions, aggregate bonded and the hash lock "mix and match". The implementation uses low-level repositories and listeners (one implementation for both vertx and okhttp). It just a layer on top of them that makes clients' life easier.

https://github.com/NEMStudios/nem2-sdk-java/tree/JAVA-81-TransactionService

Use case (David's example using the TransactionService)

https://github.com/NEMStudios/nem2-sdk-java/blob/JAVA-81-TransactionService/integration-tests/src/test/java/io/nem/sdk/infrastructure/CreatingAnEscrowContractWithAggregateBondedTransactionIntegrationTest.java#L98

The proposed transaction service
https://github.com/NEMStudios/nem2-sdk-java/blob/JAVA-81-TransactionService/sdk-core/src/main/java/io/nem/sdk/api/TransactionService.java

The implementation:
https://github.com/NEMStudios/nem2-sdk-java/blob/JAVA-81-TransactionService/sdk-core/src/main/java/io/nem/sdk/infrastructure/TransactionServiceImpl.java

What do you think? By using this service, users won't need to know how to put the announce, completed listening and error handling pieces together. Once the method finishes, the transaction is fully completed.

[dgarcia360]

@fboucquez The solution looks really elegant and definitely will help to have a better development experience. Willing to see the service merged :)

[evias]

+1 great implementation

[fboucquez]

Thanks! I'll formalize the Java PR and then I can jump over TS to implement this one. @rg911 ?

[dgarcia360]

@fboucquez Just one comment, I agree in moving listener related functions (confirmed, aggregateBondedAdded) to the Listener.