Remove requirement for PR for listing an asset

[ManfredKarrer]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

As it turned out the goal for requiring a PR with address validation and adding the asset to act as a "spam filter" did not really work out. From the assets added 3 months ago 95% have never been traded and all efforts for review, communication, merge was for nothing.

To educate developers to make a correct PR turned out to be a difficult and time consuming effort and at the end it would be much less effort if a Bisq developer adds the coin and the address validation (if needed). Most assets use a very simple default regex validation.

But I would even suggest to remove the address validation requirement as well as that effort (specially if a Bisq dev need to do it) is not worth the effort if the asset is not traded frequently on Bisq and that is the default case for the big majority. Arbitration cases with mistakes for adding an incorrect address are very rare and easy to solve (cancel trade).

Later a address validation can be added anyway. In fact many of the early assets we added still do not have address validation.

If you support that please up-vote, otherwise down-vote.

EDIT:
It seems the original proposal was not clear enough so I add here some more:
I propose to remove the policy whcih requires asset issues to make a PR with the validation and adding the asset. I would prefer they just make a normal request in GH with the basic information and a Bisq dev will add the asset to the assets list (and create the classes). That is a task done in 3 minutes. Address validation can be left to default. Optional if the asset issuer can deliver the validation rules (e.g. by regex) and samples of valid and invalid addresses the validation and tests can be made as well by the Bisq dev, but I would not wast time on that as long we don't see that this asset really gets liquidity.

@blabno @cbeams @ripcurlx Please add your comments as well!

[sqrrm]

I think it would be good to expand on the possible ways to handle assets in Bisq in a more distributed way before voting on this proposal.

For this particular proposal, what is the suggestion we're voting on? To just remove address validation for now and later figure out how to distribute asset filtering and validation?

[ripcurlx]

@ManfredKarrer If this proposal is just for removing the requirement of an address validation and going into the direction discussed in #68, I'm for this proposal.

[ManfredKarrer]

@sqrrm @ripcurlx I added something to the proposal to make it more clear.
I would treat that separate from the other one (which would require more time probably). For that we only need to update the docs page.

[blabno]

For me ideal option would be if I had permission to edit those PRs prepared by external devs. That would make the process fastest.
On the other hand, I think that we cannot trust that those validators delivered by 3rd parties are correct and can potentially reject addresses that are correct.
I think that safest way is to check if address is not empty string and that's all.

So I'm for dropping requirement of providing address validator in asset listing PR.

[ManfredKarrer]

@blabno
Unfortunately Github has no fine grain permission rights. So you would have write acces to the whole Bisq repo. We are very conservative to give that.

Good point with incorrect validation. Can create more damage as benefits.

Can u add your vote above?

[ghost]

As such I'm afraid such free registration will bring in even more shitcoins.
Even if it is a rapid task for an experimented Bisq dev, I'm not sure it's very interesting for Bisq continuing to have such a widespread shitcoins offer.
From the recent time, we see some interesting emerging altcoins traded on Bisq, I wonder if it is not more interesting to value those altcoins, than diluting them as 5% in a box of 95% shitcoins ?
I think the above proposal goes in the right direction, but the listing should not be free. There is no free lunch, there is no free work, I don't see good reason to offer listing for free.

[blabno]

There was an idea to introduce listing fee and remove assets that are not traded. The main benefit I see from that approach is that it forces those projects to help provide liquidity.

[ManfredKarrer]

@HarryMacfinned
Yes sure, that is not excluding listing fee idea. But so far we dont have a good solution for listing fee (before DAO is out). One option could be that the devs are accepting BTC payment for doing the PR. The asset issuer can offer whatever they want to the dev and the dev can pick best offers first and leave those who dont want to pay or pay low for later. As they can still do the PR themself (if quality PR) they are not forced to pay. In reality most pay anyway for a freelance dev doing that job for them.

[cbeams]

I don't have a strong opinion here. It's certainly the case that going back and forth on these PRs is more trouble than we'd hoped, even with very clear instructions, so I'm sympathetic to dropping the requirement for PRs and "just doing it ourselves", but those who want their assets listed still need to follow explicit instructions to specify the name of the asset, ticker symbol, block explorer, etc. I guess they can just do this in an issue (instead of a PR), and then somebody can implement that issue if they so choose. Indeed the party requesting to be listed could still submit a PR if they're capable, but otherwise it would be up to some Bisq dev to do it (or not).

So from my side, I'll give a +1 to this proposal, so long as it includes updating the "how to list an asset doc" to instruct users about the correct way to submit an issue, include all the right information, etc. The doc should also set expectations appropriately, i.e. that there are no guarantees that a coin listing will be implemented just because somebody added an issue requesting it. Some dev has to choose to implement the request, and if no one feels incentivized to do so, then it's not going to get done.

We should also add a specific issue template for asset listing requests. GitHub now supports multiple issue templates that you can choose from a list, so this particular issue template would be used only in these cases. See https://help.github.com/articles/creating-issue-templates-for-your-repository/ for details.

[ManfredKarrer]

@cbeams

Yes the basic informational requirements stay the same.
I would like even to create a onw repo, just to keep the main repo clean from too many altcoin requests. Over time we want to get our GH issue list also cleaned up and then to have 100s of tangling requests would be another pain. If they live in their custom repo they hurt less.

And yes they still can do it themselfes.

And fully agree to the docs part!

Any concerns if we create a own repo for that? I would call it asset-listing.

[ManfredKarrer]

I think as nobody was against that proposal and the main devs who have been in touch with that topic support it I consider it as accepted. We will update docs soon and create a repo for lisitng request issues.

[ManfredKarrer]

@m52go Could you make a PR for an updated docs page? Lets take asset-listing as repo name where they have make an issue for the request.

[cbeams]

I’d err on the side of keeping the issues in the main repo. After our experience splitting things up earlier, I would generally prefer to keep them together. If the issues don’t get implemented after a given time, they could be closed in order to keep things tidy. The dedicated issue template for asset listings can auto apply the correct label(s) so that the uninterested can filter out these issues. Another advantage to keeping them together is that those devs that do choose to work on these issues can “get seen” by others as they work, ie get recognition and credit in the eyes of other devs for doing this perhaps less-than-sexy work. Having the issues in the same repository also increases the chances that new contributors are them in the first place and perhaps start picking them up. We could always factor off the separate repo later if keeping them together proved too much trouble in practice; this is easier than ever, btw, now that GitHub supports moving issues across repositories. Your call in the end, of course, as I won’t be directly dealing with this anytime soon.

[ManfredKarrer]

Ok. Did not had a strong opinion on that either. So let's keep it in the main repo and work with a template.