Returns volume weighted average BSQ price in BTC and USD over N days.
The need for this arose while creating a Java BSQ Swap bot example
(PR pending). API bots can use this to determine whether or not to
take swap offers based on their price distance above or below the 30
(or 90) day trade price average.
Returns name of the BTC network API daemon is connected to.
I am working on some Java bot examples in another repo, and want to stop
worrying about accidentally simulating trade payments on mainnet, despite
all the warnings I add in comments. The 'getnetwork' method allows bots
to know what network the API daemon is connected to, and gives API bot
devs and users a way to avoid one potential source of costly mistakes.
API CLI manpage and apitest case are included in this commit.
Each distribution contains a runnable jar with a MANIFEST.MF
defining the classpath (all jar files in lib/).
To run daemon.jar: $ java -jar daemon.jar --apiPassword=xyz
To run cli.jar: $ java -jar cli.jar --password=xyz <cmd>
TODO Sign jar files, generate checksums.
I think this bug was introduced when deprecating GrpcOffersService
.getMyOffer(id), in favor of using only getOffer(id) for 'my'
and 'available' offers. This change explicitly sets the proto's
isActivated flag in the OfferInfo factory methods, and adds checks
to api offer test cases.
Based on branch `2-improve-grpc-exception-status-code-mapping`,
PR https://github.com/bisq-network/bisq/pull/6088
Exceptions thrown by the core.api services for the daemon Grpc*Services
have to be converted into gRPC StatusRuntimeExceptions before being sent to
gRPC clients. Most of these gRPC StatusRuntimeExceptions had a gRPC
Status.Code.UNKNOWN, which not helpful to client error handlers.
This change partially resolves the issue by sending more meaningful
io.grpc.Status.Codes to clients, where possible. But it is not as
comprehensive as it an be for a webapp because HTTP has so many more
possible response status codes than the gRPC library (sixteen). See:
https://github.com/grpc/grpc-java/blob/master/api/src/main/java/io/grpc/Status.java
There are three types of changes:
- Create custom exceptions in bisq.core.api.exception.
- Map any custom bisq.core.api.exception to a meaningful
io.grpc.Status.Code within daemon Grpc*Service classes.
- Adjust apitest cases to new grpc status codes.
Based on branch `move-cli-crypto-offer-filter-to-server`, PR https://github.com/bisq-network/bisq/pull/6086
This protobuf definition and service stub has been in place since
the start of work on the API, but was never fully implmented, nor
intended to be included in the API beta & v1 releases.
Its presence added a useless section to the gRPC API Reference doc.
https://ghubstan.github.io/slate
Based on branch `7-more-grpcproto-comments`,
PR https://github.com/bisq-network/bisq/pull/6068.
Prerequisite for next PR: Add API method 'gettrades'
The `gettrades` method will show 'open', 'closed', and 'failed' trades.
Users already needed to be able to fail and unfail trades for the
same reasons they do in the UI. API test cases will need to be able to
fail and unfail trades to check correct behavior of 'gettrades' method.
Based on branch `rename-keepfunds2closetrade`.
Trade proceeds and deposits have already been transfered to Bisq wallets
before the `keepfunds` command is (was) executed; `keepfunds` merely moves
open trades to closed trades lists and persistence files. Renaming `keepfunds`
as `closetrade` makes its purpose clear to API users.
The commit modifies only method names and comments in api server+cli classes,
apitest cases, and api trade simulation scripts.
Based on `master`
The method 'getoffer' should support looking up a user's open-offers, and other users' available offers.
- Adjust api-beta-test-guide.md to use only 'getoffer'.
- Adjust trade simulation scripts to use only 'getoffer'.
- Adjust api testcases to use 'getoffer' in place of 'getmyoffer'.
- Mark appropriate methods and protobuf msgs as deprecated.
There are some use cases where the CLI needs to know what kind of offer
is being acted on before the request is made, For example:
There are differences between a BsqSwap 'takeoffer'request, and a v1
'takeoffer' request.
A BsqSwap offer cannot be edited by an 'editoffer' request, and an
attempt should be blocked by the CLI.
- Append isMyOffer GetOfferCategoryRequest rpc msg def.
- Adjust daemon.grpc services for new boolean GetOfferCategoryRequest param.
- Adjust core.api for new boolean GetOfferCategoryRequest param.
- Add validation check in core.api EditOfferValidator to block attempt to
edit a BsqSwap offer.
- Refactor CoreOffersService get*offer(id) methods to optionally throw
excpetions.
The rpc GetBsqSwapTrade and TakeBsqSwapOffer services were a quick hack
to help test BSQ swap feature development more quickly, using apitest
cases. Their gRPC service method implementations are removed here and
the GetTrade & TakeOffer service methods are refactored to support BSQ
swaps.
PaymentMethod use an instance of TradeLimits and expect that it
has been injected, which is the case for desktop but not for
headless apps, so we enforce injection in the app base classes
used for headless apps.
The validation of trade statistics use a method in PaymentMethod
where that dependency is required.
Tha hack how the PaymentMethod use TradeLimits is not nice, but
would require more effort for refactoring.
- Made several adjustments to CLI's 'gettrade' output related code
so it can show single trade details for either Bisq v1 trades, or
BSQ swap trades.
- Did minor refactoring of API's core to retrieve # tx confirmations
for an addresses and transactions.
- Show # of tx confirmations in bsq swap trade detail.
This commit refactors the first cut of the BsqSwapTradeInfo and
TradeInfo gRPC proto defs and wrappers. The change avoids duplication
of fields between BsqSwapTradeInfo and TradeInfo, and adds a
bsqSwapTradeInfo field to the old TradeInfo proto & wrapper.
The immediate goal is moving towards getting the API's 'gettrade'
method to work for both Bisq v1 trades and BSQ swap trades: the TradeInfo
proto sent to the CLI should represent either a Bisq v1 trade or a BSQ
swap trade. A mid-term term goal is to also make a new 'gettrades' method
return a List<TradeInfo> to the CLI, where items in the List<TradeInfo>
can be either v1 trades or bsq-swap trades.
- Add GetOfferCategory service so CLI can determine what kind of takeoffer service is to be used.
- Adjust to removal of BsqSwapOfferInfo proto.
- Call new coreApi.getRole(BsqSwapTrade) before building BsqSwapTradeInfo proto.
A newly created offer has no OpenOffer+State (AVAILABLE || DEACTIVATED)
when displayed in the CLI's console. This change adds a 'bool isMyPendingOffer'
to the OfferInfo proto + wrapper, and the CLI's console offer output formatter
uses it to determine if it should display a new offer's Enabled column value
as PENDING, instead of an ambiguous NO value.
- Add editOffer to GrpcOffersService, CoreApi, CoreOffersService.
- Set editOffer call rate meter to 1 / minute.
- Use new EditOfferValidator to verify editOffer params OK.
- Adust getMyOffer(s) rpc impl and OfferInfo model to use OpenOffer
for accessing activation state and trigger price.
- Added bool tradeInstant field to proto message def.
- Adjusted core createcryptopaymentacct impl to new tradeInstant request param.
- Adjusted cli side createcryptopaymentacct impl to new tradeInstant request param.
- Fixed CliMain's takeoffer help text (was missing the --payment-account opt).
This change supports creation of BSQ BLOCKCHAIN payment method accounts.
- Added proto message defs to grpc.proto.
- Added grpc server boilerplate to GrpcPaymentAccountsService.
- Added server impl to CoreApi, CorePaymentAccountsService.
- Added createcryptopaymentacct-help.txt.
- Added CLI side support for new api method.
- Added opt parsing unit tests to OptionParsersTest.
This is the 1st PR in a series, with the goal of supporting the BTC/BSQ trading
pair. Support for other crypto currency payment accounts will be added later.
- Add description msg TakeOfferReply proto, and fromProto method
to core.offer.enum AvailabilityResult. The description field
maps a client usable error message to the enum.
- Adjust GrpcErrorMessageHandler to add AvailabilityResult.description()
to takeoffer reply.
- Refactor (split up) GrpcClient's takeOffer. Add getTakeOfferReply()
to give clients a chance to make choices based on the reply's
AvailabilityResult when the takeoffer command did not result in a
trade. (Some errors are fatal, some not.)
