Add referrer Id for external Bisq market makers

[ManfredKarrer]

We could add a referrer Id to the offer (we can use the extraMap hashMap which would not cause backward compatibility issues)to track offers created by the API and reward those who provide the API. That would deliver a metric as base for compensation requests.

This is a very rough first draft idea and I wanted to request feedback before specifying it more in detail.

@mrosseel, @blabno: What do you think?

[sqrrm]

In a way this is reasonable but it also finger prints the users of the API. Not sure that would make a difference but perhaps it would discourage some usage of the API if users don't want to be identified as using it. It could go the other way too I suppose, that it's a sign of a more solid counter party if they use the API. In the end it couldn't be guaranteed either way and if only used for metrics and no other trade function I think it might be a reasonable idea.

[blabno]

Sounds ok for me. I don't see any issues with that.

[mrosseel]

several thoughts on this:

• have to take care of privacy as sqrrm says
• adding a referrer id is a good idea to maybe in the feature reward market makers (localbitcoins etc). So while it might initially be used to reward the API makers, it should be usable in a later stage to e.g. award BSQ to market makers so they get a discount on their fees.
• using the api trade volume as a proxy for API worth and compensation for the creators is OK, but it's very gameable + wouldn't want to take this model too far e.g. instrumenting every UI button to see if ripcurl gets paid etc. (I think the whole 'time of payment' thing needs some more discussion/refinement, certainly for people working full time on the project.)

[ripcurlx]

Having a referrer id would make it possible to have something like an affiliate marketing system to compensate parties that bring trade volume (completed trades) to the network. This kind of system scales very well in other fields. Having it visible in the markets API would also make it transparent for everyone how much completed trades where sourced by one affiliate. Of course we might need later an by contributors approved list of affiliates that get compensated to prevent compensating parties that trick users into trades.
I don't think this is something that should be extended in every field to have a measurement of compensation, just for bringing volume to the platform.

[ManfredKarrer]

Yes I also would not take that too serious as @mrosseel pointed out its easy to game and also would just delegate the problem to estimate the value of API (to how much value has one trade from the API?). Quantifying things is nice but has its clear limitations as well, so I would just see it as an extra metric/information input.

[ManfredKarrer]

It seems we have some market maker in Indonesia and Vietnam. To incentivize those the referrer might be useful as well but I assume they use the standard Bisq app. So we should add a method that their users can add a referrer ID and then their offers get marked with the referrer and we can see in the statistics how much volume was created by them. That can be then used for compensation requests.

[ManfredKarrer]

To be clear the refererId will not be per-user but per marketmaker/api provider so it should not decrease privacy, beside that it would partition the Bisq trades to those groups coming from different sources.
We could add a list of hard coded refererIds and marketmakers need to apply for getting an id assigned. Then they can tell their users to add that in the settings view to a refererId input text field. When they make offers that refererId gets added to the offer and the trade statistics in case someone takes the offer.
I am not sure yet if the taker will be reflected in the trade statistics as well, need to check that code first.
RefererIds can be random numbers with a prefix like: REF_ID_324, REF_ID_288,...

In a late phase we can use the DAO to request for a refererId and if voted ok then the ID is accessible for users. Also the amount of compensation per trade can be defined by voting... But for now we keep it simple ;-).

@blabno @sqrrm @mrosseel @ripcurlx : What do you think about that? Technically it is easy to implement and we could add it to the upcoming release, if the idea gets sufficient support.

[sqrrm]

I'm giving a thumbs up to try this out in a simple way like this. If it doesn't work out we can remove the feature as long it's optional to add it or modify it. The privacy risks are probably low for now since it's an optional feature.

[ripcurlx]

A thumbs up also from my side, as I think this could be a very powerful tool in the future to grow volume by being able to compensate external partners (wallet providers,...) based on segmented volume data that is viewable by everyone.

[ManfredKarrer]

I implemented the feature.

If one trader has a referral ID set and the other not then both trade statistic objects get stored and we can detect it. If both traders have the same referral ID set we only store one trade statistic object. If both have different referral IDs both trade statistic objects get stored and displayed as well.

Referral ID can be set in preferences:

The entered referral ID must match one of the hard codes items.
Market makers get one assigned by the core developers.

At any of the market views to show the trades with a referral ID set click cmd+t to see a popup. As the text can be long it is truncated but can be copied with the copy button:

Item example:
Trade ID: yStswV-181f471b-de9f-4493-897f-44610818856e-070
Date: Jun 26, 2018 8:22:32 PM
Market: BTC/USD
Price: 6715.4376
Amount: 0.0001
Volume: 0.67
Payment method: Perfect Money
ReferralID: REF_ID_342

At any of the market views to show the offers with a referral ID set click cmd+o to see a popup. As the text can be long it is truncated but can be copied with the copy button:

Item example:
Offer ID: FZTZRAB-60c5c526-fb6c-4ecf-9c55-3f83a65d6f51-070
Type: BUY
Market: BTC/USD
Price: 6691.4250
Amount: 0.0001 BTC
Payment method: Perfect Money
ReferralID: REF_ID_342

Of course an export to csv would be nice but I leave that as low hanging fruit to any dev who wants to work on that.

[sqrrm]

I have acked the PR but I realize there might not be enough support yet for this proposal with basically three thumbs up only. Would be good if @mrosseel and @blabno also added your thumbs up if that's your opinion.

[ghost]

@ManfredKarrer ,
you wrote:

If both traders have the same referral ID

you mean that this can happen randomly, by chance ?

[ManfredKarrer]

@HarryMacfinned
The referral ID is that from the market maker who tells their traders to use that referral ID. E.g. if the API devs get a few traders who use their referral ID and those trade between each other then they will have the same referral ID.
It is NOT a referral ID per user! That would have privacy issues...

[ghost]

Thanks for the clarification @ManfredKarrer .

I'm however a bit worried with this field being displayed and filled in the everybody (personal) account preference menu.
If I understand well, this referrer ID should be mainly (exclusively ?) for market makers using the API.
As I understand, everybody (meaning a majority of little traders) will have this referrer ID field displayed in their account/preference menu ... although in fact this referrer ID concerns only a very tight minority.

If it is NOT a referral ID per user ... the (personal) account/preference menu is perhaps not the best place for it ?
Or the field should be prefilled with a very explicit message like : reserved for pro traders using the API.

If it is a referral ID only used by some few (market maker + API), wouldn't it be more adequate to have a API function to achieve this assignation ? Which may also avoid possible collisions if the field is filled at hand.

I'm probably a bit heavy. Apologies.

[ManfredKarrer]

No it is not exclusively for API users. But good you mention that, I forgot to support a command line option key to set it.

Do you have a suggestion for another place to put the field?

[ghost]

For my part, I would make the filling only available thru the API.
Or as you say, thru a command line option.
So only concerned people would do that.
And then, yes, it may well be displayable in their account/preference settings. But this would only concern those (happy) few people. (And not 99% of unconcerned people who may be a bit dumbfound about this field).

But I recognize that I have no clear idea if this is easily doable with the API. Certainly not yet. But could a function doing that be added easily ?

[ManfredKarrer]

We have a group of market makers in Asia and those are using Bisq directly so we don't want to limit it to API users.

[ghost]

ok, but for those cases where the API is not involved, wouldn't the .onion adress (and its numerous occurence in trades) be enough to designate market makers ?

[ManfredKarrer]

No it is about the users he brings in, not himself.

So for instance if one western union shopowner decides to offer Bisq to their clients for cheaper remittance, he could explain them how to use it and tell them if they add the ID we assigned to him he will get 50% of the trade fee (or whatever).

It is NOT that single users get an ID assigned from Bisq (nor can they take a random ID themselves). One need to request an ID from Bisq and we only give out IDs to people where we expect considerable volume and users. It can be a single entity as well but I assume its more that they hand it over to their users.

Another case are API providers:
Lets assume @blabno and @mrosseel run the API as their service. They can pre-configure the referralID they ot assigned so all the users of their service will use that ID (here probably via program argument) and we can see how much volume their API service has generated. Based on that they can file compensation requests.

Its just a rough idea yet and we will see how it develops, but I wanted to open that feature so that such liquidity providers can build a business model on top of it.

[ghost]

So if I understand, there may be many services which may have a use of such an ID.
So, on the user side, a user may use more than just one service, ie more than one ID. So it cannot be filled in the account/preference settings. It's more a specific trade setting, than an overall general setting.
Sorry if I misunderstood.

[cbeams]

Closing as approved (and indeed already implemented). This should have been closed long ago; my bad that it wasn't.