in bridge server they are called "hooks" in compliance server they are called "callbacks" it doesnt matter which we use but they should be consistent between both.

Seems like this should at least be called for payments received with assets you don't accept. Not sure what else should trigger it.

Should we add an endpoint that builds txs for them maybe from some json object or something?
This would allow people to do arbitrary txs without having a lib to build the XDR.

Something like:

{
   ops: [
      { 
       type: allow_trust,
       issuer: GBEZOC5U4TVH7ZY5N3FLYHTCZSI6VFGTULG7PBITLF5ZEBPJXFT46YZM,
       asset_code: "BTC"
      },
      {
         type: set_options,
         inflation_dest: GBEZOC5U4TVH7ZY5N3FLYHTCZSI6VFGTULG7PBITLF5ZEBPJXFT46YZM
      }       
    ]

An alternative would be an endpoint that will do the change trust operation since other than payment this is probably the most common.

@nullstyle I bet you have thoughts here.

When there's a problem connecting to Horizon try to reconnect instead of exiting.

looks like it has the bridge server example config

It’s possible I’m misunderstanding the flow here, but when posting to the compliance server’s internal /send endpoint, it seems like the sanctions callback should be called with the info obtained from the foreign compliance server before returning a 200 OK response. Step 6 in the compliance protocol doc would seem to indicate the same.

As it stands, setting needs_auth merely tells the other compliance server to send back info on the receiver (which it does), but then does nothing with that info other than pass it back in the result to /send. If the entity that called /send was the bridge server, we also know the bridge server does nothing with this info.

I know this used to work, but I haven't tried earlier versions of bridge. I'm trying this on v0.0.18.

curl -X POST -d \                                                                                                                                                                                        
  "source=SBT54H3GKVLDDT2WN4E5YWCWEULU2UICOJ6WEQV436UZMMPBTQTMLQG2&\
  amount=1&\
  destination=GDMDBRU7C3AESSHRN3W7CQL7QV6SAZKSEJU5W7O2BOVERQODKHW2RQFP&\
  memo_type=id&\
  memo=125" \
  https://bridgeserver/payment

returns:

{
  "code": "missing_parameter",
  "message": "Required parameter is missing.",
  "data": {
    "name": "destination"
  }
}

We should probably stuff it in the compliance config, and add it to to the Stellar.org/developers docs.

The docs suggest that the base_seed configuration parameter will be used to determine the transaction source for payments, but the source param is still required anyway (https://github.com/stellar/bridge-server/blob/0.0.12/src/github.com/stellar/gateway/protocols/bridge/payment.go#L63) and there certainly doesn't appear to be any code for the fallback anyway (https://github.com/stellar/bridge-server/blob/0.0.12/src/github.com/stellar/gateway/protocols/bridge/payment.go#L128)

As a side note: what is the point of that config param if this doesn't work?

This will involve changing the /send and /payment endpoints to accept a destination currency. If it is different than the sending currency then you must do the path find before you create the tx.

Instead, show error if there was an error reconnecting.

https://github.com/stellar/gateway-server/blob/master/src/github.com/stellar/gateway/listener/payment_listener.go#L134

In writing the new anchor guide, I was at first a little confused to find that I had to specify extra_memo in the payment parameters to the bridge server in order to trigger usage of the compliance server (in my first several attempts, I had left it empty and couldn’t figure out why I wasn’t seeing any compliance activity).

After looking through the source, I definitely understand that using extra_memo as a shorthand prevents hitting the receiver’s stellar.toml (especially since the compliance server will do it again), but from a user perspective, this still seems a little awkward. Maybe the compliance server could respond with a special status code to indicate that no compliance was necessary or maybe the bridge server could pass along the foreign stellar.toml data?

Currently it appears that the compliance server can return several responses on the sanctions check.

• 200 - ok
• 202 - delayed
• 403 - denied

We need the ability to pass back validation errors. For example if the country code is not iso2, or birthdate is not iso format. This could be 400 + text or maybe 422 as per this discussion. https://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate

It strikes me that the common case for bridge server is for the ReceivingAccountID to be the account ID that corresponds to BaseSeed (please correct me if this seems way off base). Would it be a useful convenience to generate it from BaseSeed if none is provided?

https://github.com/stellar/bridge-server/blob/master/readme_compliance.md#callbacks this section doesn't exist.

This will fix the case where they call /payment but never hear back. They don't know if they should re-post or if the tx was sent.

uniqueID should just be an opaque string.

This is one of two issues that had me pretty much stumped for more than a day. In the 0.0.12 release of bridge server (haven't checked compliance server for this issue yet), the bindata.go file that holds the migrations for mysql is not up-to-date with the actual migration .sql files. So if you call:

./bridge --migrate-db

…as recommended in the readme, you get a DB that doesn't actually work. (Specifically, the SentTransaction table is missing the transaction_id column.)

It seems pretty obvious that this was a result of the .sql getting updated, but someone forgetting to manually run go-bindata -o bindata.go migrations_* from each db/drivers/* directory. I imagine it would be a very good idea to simply script that as part of the build process somehow (I'm not familiar enough with gb to know if there's a way to do that without wrapping it).

Further, maybe it would be a good idea to do a 0.0.13 hotfix-ish release that fixes the SentTransaction table? And it should at least be done in whatever the next normal release is.

(It is worth mentioning: the bindata.go for mysql appears to be up-to-date in master.)

When a transaction has more than one payment operation, it only saves the first payment operation and then logs Payment already exists. it does not save the other operations.

The readme for compliance currently states that if the ask_user callback is not specified, “then the customer information won't be given to the other FI.” This isn’t actually true—it falls back to users and domains that have been whitelisted using the allow_access endpoint.

Additionally, the description of the allow_access endpoint and its effects is incredibly unclear. I definitely didn’t understand it until I spent some time browsing the source, which a user definitely should not need to do.

This will possibly be moved to a different project later but in the meantime lets just have it here.

input:

• source seed
• destination (account ID or address)
• asset_code (XLM for native)
• amount
• memo type
• memo

handling the request:

• resolve the destination address if necessary
• load source account to get the correct seq#
• if XLM payment
  • load dest account to determine if it exists yet
  • if not create account rather than payment
• create tx
• submit tx to horizon

return: horizon response or an error

The documentation for bridge server notes that if the server is configured with an api_key option, a corresponding parameter named api_key must be included with all requests (https://github.com/stellar/bridge-server/blob/master/readme_bridge.md#config).

However, the actual parameter in the request is apiKey (https://github.com/stellar/bridge-server/blob/master/src/github.com/stellar/gateway/server/middlewares.go#L42).

Not sure whether the documentation just needs to change to reflect reality or the parameter name should change. In an ideal world, it seems like the latter would be better (so it is in keeping with the naming convention for all other params), but if anyone is using it, that could easily break them. Maybe accept both?

The stellar.toml will tell you if it does.

in the config docs

Right now it returns any error as 400 and its opaque to the caller what is going on. at least with /payment

Having --conf in both bridge and compliance for that would be great!

Ex. does not return any relevant information when invalid JSON is passed in AuthRequest.Data.

Using the v0.0.17 Linux binary, I getting the error on shown in the title when I provide -c or --config.

Here's the full error:

INFO[0000] Applied migrations: 0
INFO[0000] Creating and initializing TransactionSubmitter
INFO[0000] Initializing Authorizing account
INFO[0000] Loading account                               accountID=GAT6VDPXX26XXFAKACUJTIZAL3GSFJ4NECG7B3C3P63IP4233XFP2PCS service=Horizon
INFO[0001] Account loaded                                accountID=GAT6VDPXX26XXFAKACUJTIZAL3GSFJ4NECG7B3C3P63IP4233XFP2PCS service=Horizon
INFO[0001] Initializing Base account
INFO[0001] TransactionSubmitter created
INFO[0001] Creating and starting PaymentListener
WARN[0001] No callbacks.receive param. Skipping...
flag provided but not defined: -c
Usage of bridge:
  -bind string
    	Address to bind on. If this value has a colon, as in ":8000" or
		"127.0.0.1:9001", it will be treated as a TCP address. If it
		begins with a "/" or a ".", it will be treated as a path to a
		UNIX socket. If it begins with the string "fd@", as in "fd@3",
		it will be treated as a file descriptor (useful for use with
		systemd, for instance). If it begins with the string "einhorn@",
		as in "einhorn@0", the corresponding einhorn socket will be
		used. If an option is not explicitly passed, the implementation
		will automatically select among "einhorn@0" (Einhorn), "fd@3"
		(systemd), and ":8000" (fallback) based on its environment. (default ":8001")
  -httptest.serve string
    	if non-empty, httptest.NewServer serves on this address and blocks

This is the result of bridge --help:

stellar bridge server

Usage:
  bridge [flags]

Flags:
  -c, --config string   path to config file (default "bridge.cfg")
      --migrate-db      migrate DB to the newest schema version

If connected to a compliance server it should hit the /receive_payment endpoint and reject the payment if the compliance server hasn't approved.

In many cases the sender needs to get additional info from the receiver after the payment is sent. To either tell their customer or for their own records.

After a tx is approved by the compliance protocol and submitted to Stellar, the sender can call /tx_status to learn what happened to the tx.

/tx_status?sender=bob*domain.com&id=tx_id&sig=<sig>
return
{
	status: {unknown,pending,ok,failed,refunded},
	recv_code: <arbitrary string>,
	refund_tx: <tx_hash>,
        msg: <arbitrary string>
}

sig is the tx_id signed by the sending domain using the same signature mechanism used in the compliance protocol.

refund_tx only appears if the status is "refunded". It will be the txID of the tx sending the money back. The address to send the refund to needs to be sent as part of the original payment attachment otherwise the receiver won't know how to refund.

It would be nice if bridge and compliance server printed their version if you run

./bridge -V

right now code is duplicated between both

I'm looking to build an app that will watch multiple addresses, without knowing them ahead of time. It looks like my option today is to subscribe to the stream straight from my app. Since bridge already does this but for one address at a time, perhaps the addresses being watched can be database-driven so multiple ones can be created.

• This table can be called "address_observers" or something like that.
• An address observer has, at least, an address field
• if a receiving address is specified in the cfg file, an entry is created in the db (for backward compatibility)

Does this sound like a feature that fits the scope of the bridge server?

The compliance readme currently lists the encryption_key config property as “not working yet,” but it is still required in the configuration validation routine: https://github.com/stellar/bridge-server/blob/master/src/github.com/stellar/gateway/compliance/config/config.go#L59-L62

Should it be optional until support for it is implemented? If not, we should probably at least update the readme to clarify that you still have to specify it (and it has to be valid).

https://github.com/stellar/bridge-server/blob/d3f973b1cee2a0040c4036483f26d4610146f16b/src/github.com/stellar/gateway/horizon/main.go#L155

needs triaging. see src/github.com/stellar/gateway/horizon/internal.go for parseEvent function that throws this error

config_bridge.toml -> bridge.cfg
config_compliance.toml -> compliance.cfg