teambtcmap / btcmap.org

Free and open source bitcoin map web application
https://btcmap.org
GNU Affero General Public License v3.0
43 stars 11 forks source link

Show 3rd party btc payment methods #110

Closed pepakriz closed 7 months ago

pepakriz commented 11 months ago

Hi all,

I'm a developer from Qerko, an app that enables you to pay at restaurants without interacting with a waiter. Three months ago, we introduced Bitcoin Lightning support, and over this period, we've stabilized it. It is now highly usable and issue-free.

During this time, I've been collaborating with @hynek-jina, who is working on finding a good solution to tag Qerko restaurants in OSM. You can follow the discussion here: https://github.com/teambtcmap/btcmap-data/issues/4283

Now, it's time for the next step: improving the visualization on btcmap. Currently, it's challenging to identify restaurants that natively support Bitcoin and those that require a third-party app. In this merge request, I've introduced a new section called "3th Payment Methods." You can see it as part of the popup marker on the map and on the merchant page details.

The solution is designed for future expansion. If someone wishes to add another third-party app, they simply need to update the configuration in the thirdPartyPaymentMethods config. That's all.

This was my first experience with the Svelte library, so I'm not sure if the code adheres to best practices. Please let me know if there's something I can improve.

image image image

Maybe this can be an answer to this issue https://github.com/teambtcmap/btcmap.org/issues/104

netlify[bot] commented 11 months ago

Deploy request for btcmap rejected.

Name Link
Latest commit e256e7c0c5d4ebea7a6d94847330507348c74393
dadofsambonzuki commented 11 months ago

Thanks for the PR!

I think this needs a little bit more design thought as we may need to support multiple 3rd party apps going forward.

I think we should have a single generic icon next to the existing set, with a hover showing the 3rd party app required. e.g. Qerko, cryptoconvert (used at Pick n Pay in SA).

@cogentgene @3j2009

3j2009 commented 11 months ago

I'd like to take this opportunity to redesign the card entirely as there's a number of design issues with the existing cards that I think can be improved. I'll incorporate the 3rd party payments into the new design.

3j2009 commented 11 months ago

>>>>>>>> Please see the comments in the Figma file for import change details to the card

Merchant card

https://www.figma.com/file/vUjpoiSe7cap1PeITcbgwl/BTCMap-(Copy)?type=design&node-id=2401%3A1468&mode=design&t=hmMklOo3NiUzI2UQ-1

pepakriz commented 11 months ago

@3j2009 I attempted to modify the code based on your graphical suggestions. Take a look. To check the interactivity, it would be best to deploy the current version to a test environment.

image image

3j2009 commented 11 months ago

@pepakriz can you please add the merchant's website there in with navigate and share. The website's link is the value from the website tag in OSM if one is found. If no website tag is found for the merchant than the website button's display should be hidden.

Also please can you populate the 'type' descriptor under the merchant's name, which is "hairdresser" in the prototype example I posted. We should be able to grab that info from OSM using the text value from any/all of it's respective OSM tags that match: ("shop=" || "amenity=" || "business=")

pepakriz commented 11 months ago

@3j2009 Take a look:

image image

3j2009 commented 11 months ago

@pepakriz everything looks good, thanks!

👀 @dadofsambonzuki

dadofsambonzuki commented 11 months ago

Looks good to me.

Needs @secondl1ght to review and deploy to a test environment.

pepakriz commented 11 months ago

Hi @secondl1ght , just in case you missed the notification. Could you please check this out? Thank you.

secondl1ght commented 11 months ago

Hey @pepakriz thanks for the PR, sorry I have been very busy and haven't had time to look at this yet. But I will make some time next weekend to review this!

secondl1ght commented 10 months ago

Thanks for the PR!

I think this needs a little bit more design thought as we may need to support multiple 3rd party apps going forward.

I think we should have a single generic icon next to the existing set, with a hover showing the 3rd party app required. e.g. Qerko, cryptoconvert (used at Pick n Pay in SA).

@cogentgene @3j2009

As mentioned above and in some of the other Querko threads we want to keep this generic, that way any third party provider that doesn't natively support bitcoin can add the required tags to OSM and a warning to notify the users will appear on BTC Map. So this won't include any specific company logos. I like the idea of having it at the end of the Payment Methods row. I have an icon set I can have a look at to see some that might make sense for this generic purpose. And a tooltip that displays the name of the third party app required would work nicely and work the same as the current icons. Please let me know if you don't want to spend any more time refactoring this and I could add this feature for you. Sorry again for the delay in responding.

3j2009 commented 10 months ago

@secondl1ght what are the proposed benefits to support your suggested UI against the current design?

hynek-jina commented 10 months ago

@3j2009 I assume that motivation for that is lower maintenance in the future. But still there might be some fall-back (default) icon for third parties and if you add specific one it looks better than. Isn't it?

But it's not my call, so I'm sorry for the interruption.

dadofsambonzuki commented 8 months ago

Hi all - just wanted to bump this to a conclusion.

I think we have a good solution with a generic icon and a specific tooltip based on an OSM tag.

@secondl1ght - are you comfortable?

secondl1ght commented 8 months ago

Yes I can bring this across the finish line with the changes we talked about - I have been focusing on other higher priority items but it's on the TODO list to complete this and close it.

pepakriz commented 8 months ago

@secondl1ght So what is the next step? Is my code still relevant? I can rebase it to the main branch, but I'm unsure about your final vision. (yes, I realize it needs to use TypeScript, no problem)

secondl1ght commented 8 months ago

I will close this PR since it is outdated and we refined the scope of this task and I will finish making the changes on the master branch that we talked about. I may have time to get this finished this weekend but if not then I can do it next weekend for sure. Thanks again for helping with this!

hynek-jina commented 7 months ago

Is this the outcome? Screenshot 2024-02-07 at 11 51 58

There are businesses that support for example lightning and 3rd party app at the same time...

dadofsambonzuki commented 7 months ago

Yep, that is the outcome for 3rd party apps.

Merchants that also accept payments directly should logically have the other icons shown in addition for sure. Perhaps they were tagged because their legacy provider was on-boarded without their knowledge for example.

dadofsambonzuki commented 7 months ago

Ooops, didn't mean to re-open the PR!

hynek-jina commented 7 months ago

For example this business accepts Qerko (3rd party) and lightning at the same time.. But there is visible only mobile icon (3rd party) https://btcmap.org/merchant/node:2035703150

Screenshot 2024-02-07 at 14 39 15
secondl1ght commented 7 months ago

Is this the outcome? Screenshot 2024-02-07 at 11 51 58

There are businesses that support for example lightning and 3rd party app at the same time...

Hi @hynek-jina, that is not what the tag name suggests payment:lightning:requires_companion_app. It says that a companion app is required, not optional. Also if the merchant accepts regular lightning payments then there is no need to advertise a third party app because the interoperable option is preferred. This tag was meant to flag businesses that ONLY accept via third party as it could cause friction when a customer visits the store and they discover they need to download an additional app. If a merchant accepts native lightning then there is no need to notify the user of any extra requirements and they can proceed as usual. We actually want to promote native options over walled gardens. So basically if payment:lightning exists then payment:lightning:requires_companion_app should be removed as they are conflicting tags.

hynek-jina commented 7 months ago

This seems a bit messy to me. payment:lightning should mean that you can pay there directly with lightning. You shouldn't be able to overwrite it by some additional third party. These 3rd parties might not know about businesses ability to accept native lightning..

pepakriz commented 7 months ago

In case the merchant accepts btc over Qerko, we add these tags:

'currency:XBT': 'yes',
'check_date:currency:XBT': ...,
'payment:lightning:requires_companion_app': 'yes',
'payment:lightning:companion_app_url': 'https://www.qerko.com',

and then we can recognize the difference between native LN, LN over Qerko, or both simultaneously.

edit: BTW my original PR works in this way.

dadofsambonzuki commented 7 months ago

Agree with @hynek-jina and @pepakriz.

We shouldn't be making decisions on behalf of merchants nor users. We should be presenting merchants faithfully 'as tagged'.

secondl1ght commented 7 months ago

If you want it to work this way then you'll have to update the tags because it currently clearly states that a companion app is required. payment:lightning:requires_companion_app - so it works as expected.

If you look back on the discussion on this you'll see we were always talking about how to tag locations that require a third party app https://github.com/teambtcmap/btcmap-data/issues/4283#issue-1754389589. See the very first post states in bold: 'Customers need to use Querko app (download it or use instant app) to get the LN invoice'. That's why the tag was named this way.

We even added a filter so that users can remove locations based on this tag because many users do not want to download a proprietary app to use bitcoin https://github.com/teambtcmap/btcmap.org/issues/124.

It will have to be changed to payment:lightning:companion_app or payment:lightning:optional_companion_app. If the idea has changed that this will be used alongside interoperable options.

hynek-jina commented 7 months ago

I still think that this logic is not correct. These tags should be independent..

bubelov commented 7 months ago

Payment tags were a mistake and they don't stand a single chance of being officially accepted by OSM. I agree that payment:lightning should always mean native LN. We're basically discussing the parsing priority when we have conflicting data due to a poor tag system design. In my view, payment:lightning should have a higher prio, so we can stop the parsing routine and ignore the rest of the tags if we can find this tag and if it's set to yes.

We can also simply delete the rest of the tags once the place is converted to native LN.

hynek-jina commented 7 months ago

I would prefer to keep both information.

secondl1ght commented 7 months ago

I agree with @bubelov. But @hynek-jina what you are talking about can be achieved however there is currently an issue with the tag naming convention that needs to be resolved as I mentioned. I think Querko is the only one using this tag so it should be safe to proceed with a bulk update if you want to.

hynek-jina commented 7 months ago

Where is this discussion about naming convention?

dadofsambonzuki commented 1 month ago

Pick'n Pay is South Africa falls under this category too, but currently doesn't use the 3rd party app convention.

I am in contact with them about bulk re-verification and so it would be a good time to add the 3rd party tags once agreed.