4 ms·

The IBAN scheme is probably a bit too simplistic, but I'd say it's a good start. You can't figure out how to pay someone with just an account number. If my brow

by elric 5y ago

The IBAN scheme is probably a bit too simplistic, but I'd say it's a good start. You can't figure out how to pay someone with just an account number. If my browser were to implement this scheme, it wouldn't know what to do. Redirect me to my bank so I can launch a SEPA instant payment? How does it know where my bank is? What if I have multiple banks? What if I want to pay by card?

hnlmorg 5y ago
mailto has the same problems; which is probably why so many sites have a contact form instead of a mailto link.
- derefr 5y ago
  I don't see what's hard about mailto:. Your browser sees a mailto: link, and passes it off to OS default-open-action logic. Some program on your OS has registered itself as wanting the mailto: scheme-association, so it gets opened. That program receives the mailto: URI as its ARGV[1], and can then parse it. In theory, different mail programs might do different things with a mailto: URI, or expect different things to be in a mailto: URI — but by registering an association with the mailto: scheme, they're claiming to do something useful with a mailto: URI if passed one.
  - hnlmorg 5y ago
    It's not hard, it's just a lot of different stakeholders that need to be coordinated for it to work. And it took a long time for said products to get organised, meanwhile companies still needed convenient ways of allowing customers to contact them....hence the contact forms. It will be the same problem here. It's safer not to use a payto scheme if it is the difference between a future customer being unable to buy your services because they haven't yet got the latest associations installed.
    - oauea 5y ago
      Even worse: The stakeholders in the companies that decide to have contact forms are generally not very technical. They probably never successfully installed a mail client in their life, so it's not very surprising they don't opt into using mailto links.
  - EE84M3i 5y ago
    In addition to the OS handling, browsers will happily let Gmail or other websites handle mailto links. I believe they are normally registered with registerProtocolHandler[1] which is how, for example, Fastmail has a "Open mailto links from other sites in Fastmail" button in the advanced settings. Notably, payto does not seem to be on the allowlist for registerProtocolHandler. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
- bbarnett 5y ago
  Spam is why many don't use mailto...
  - hnlmorg 5y ago
    That's certainly one strong reason for not using it in the 90s. But it's less true these days now that any and all email addresses get hit by spam hard and spam countermeasures have gotten better.
    - bbarnett 5y ago
      I'm willing to bet you don't admin MTAs on a daily basis...
      - ImPostingOnHN 5y ago
        Thank you for your service as one of those countermeasures
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
derefr 5y ago
Taking the sibling commentor's analogy to mailto: links further: Imagine "digital wallet" apps, that would register themselves for the payto: scheme at the OS level — just like web browser apps are registered openers for the http: scheme, or like email client apps are registered openers for the mailto: scheme. (I mean, you don't actually have to imagine them, they already exist. Apple Wallet is a "digital wallet app" on iOS. Native-app crypto wallets are "digital wallet apps." Paypal's mobile app is a "digital wallet app." None of them register for payto:, but they all could.) Now imagine that, like web browsers or email clients, every OS default-installed its own minimal first-party wallet app, so that it had something to fire up in response to a click on a payto: link, if you didn't have any other piece of software installed. Think "Outlook Express." Like with web browsers or email clients, you could install your own wallet apps, and then choose which one to make the default for the payto: scheme. There could be single-service wallet apps (created by your bank; by Visa/Mastercard/etc.; by Paypal/Venmo/etc.), and multi-service wallet apps (created by bigcorps and ISVs); just like there are single-service email apps (the "native Gmail client" kind of apps), and multi-service email apps. If you had multiple equal-priority scheme associations for payto:, your OS would pop a menu to ask you which app you want to use to open the link, just like it pops a menu when you go to open a file and there isn't a clear default association. The apps themselves would be free to ask more questions (or not) upon being intent-opened. If you click a mailto: link, then some email apps, when configured with multiple accounts, ask you which account you want to send the email as; others don't, but instead just let you switch the "From" field between your accounts, and do all the book-keeping to move the draft email between services, etc., in response. Same idea here.
- elric 5y ago
  Thanks for pointing that out. That seems so obvious in retrospect.

by elric 5y ago

hnlmorg 5y ago

mailto has the same problems; which is probably why so many sites have a contact form instead of a mailto link.

derefr 5y ago
I don't see what's hard about mailto:. Your browser sees a mailto: link, and passes it off to OS default-open-action logic. Some program on your OS has registered itself as wanting the mailto: scheme-association, so it gets opened. That program receives the mailto: URI as its ARGV[1], and can then parse it. In theory, different mail programs might do different things with a mailto: URI, or expect different things to be in a mailto: URI — but by registering an association with the mailto: scheme, they're claiming to do something useful with a mailto: URI if passed one.
- hnlmorg 5y ago
  It's not hard, it's just a lot of different stakeholders that need to be coordinated for it to work. And it took a long time for said products to get organised, meanwhile companies still needed convenient ways of allowing customers to contact them....hence the contact forms. It will be the same problem here. It's safer not to use a payto scheme if it is the difference between a future customer being unable to buy your services because they haven't yet got the latest associations installed.
  - oauea 5y ago
    Even worse: The stakeholders in the companies that decide to have contact forms are generally not very technical. They probably never successfully installed a mail client in their life, so it's not very surprising they don't opt into using mailto links.
- EE84M3i 5y ago
  In addition to the OS handling, browsers will happily let Gmail or other websites handle mailto links. I believe they are normally registered with registerProtocolHandler[1] which is how, for example, Fastmail has a "Open mailto links from other sites in Fastmail" button in the advanced settings. Notably, payto does not seem to be on the allowlist for registerProtocolHandler. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
bbarnett 5y ago
Spam is why many don't use mailto...
- hnlmorg 5y ago
  That's certainly one strong reason for not using it in the 90s. But it's less true these days now that any and all email addresses get hit by spam hard and spam countermeasures have gotten better.
  - bbarnett 5y ago
    I'm willing to bet you don't admin MTAs on a daily basis...
    - ImPostingOnHN 5y ago
      Thank you for your service as one of those countermeasures

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

derefr 5y ago

Taking the sibling commentor's analogy to mailto: links further: Imagine "digital wallet" apps, that would register themselves for the payto: scheme at the OS level — just like web browser apps are registered openers for the http: scheme, or like email client apps are registered openers for the mailto: scheme. (I mean, you don't actually have to imagine them, they already exist. Apple Wallet is a "digital wallet app" on iOS. Native-app crypto wallets are "digital wallet apps." Paypal's mobile app is a "digital wallet app." None of them register for payto:, but they all could.) Now imagine that, like web browsers or email clients, every OS default-installed its own minimal first-party wallet app, so that it had something to fire up in response to a click on a payto: link, if you didn't have any other piece of software installed. Think "Outlook Express." Like with web browsers or email clients, you could install your own wallet apps, and then choose which one to make the default for the payto: scheme. There could be single-service wallet apps (created by your bank; by Visa/Mastercard/etc.; by Paypal/Venmo/etc.), and multi-service wallet apps (created by bigcorps and ISVs); just like there are single-service email apps (the "native Gmail client" kind of apps), and multi-service email apps. If you had multiple equal-priority scheme associations for payto:, your OS would pop a menu to ask you which app you want to use to open the link, just like it pops a menu when you go to open a file and there isn't a clear default association. The apps themselves would be free to ask more questions (or not) upon being intent-opened. If you click a mailto: link, then some email apps, when configured with multiple accounts, ask you which account you want to send the email as; others don't, but instead just let you switch the "From" field between your accounts, and do all the book-keeping to move the draft email between services, etc., in response. Same idea here.

elric 5y ago
Thanks for pointing that out. That seems so obvious in retrospect.