Use of dogecoin: URI conflicts with envelope outputs

[dbrain]

dogecoin:<address>?amount=<amount>&otherstuff=hi URIs only support a single address, dogeconnect URIs build on top of this adding dc and what not to allow the wallet to get an envelope describing what this payment is for.

The envelope has an outputs array, so I could say "this envelope wants, and the relay will not accept anything other than" 1 output to addressA for 500 doge and 1 output to addressB for 100 doge.

We are reusing the dogecoin: URI for fallback - so wallets that do not support dogeconnect can still pay, but if we have multiple outputs what do we put here?

Maybe just a misunderstanding/documentation task:

• What do we expect to happen here? Is the vendor/relay supposed to understand this and have a specific "all outputs go here as fallback" address? Is this a requirement on the relay?
• Is this a gap and suggests we should move to a specific URI/at least add a new URI to the spec that forces dogeconnect?

All of the "using dogeconnect" applications are a little damaged/need to handle a bunch of edge cases when you need to consider that we also need to support the URI being used by a wallet that does not support dogeconnect.

[raffecat]

I remember we discussed this and came to conclusions like:

• We want multiple outputs so we can collect a fee without taking custody of the payment to a vendor (e.g. POS provider)
• We need to support the original dogecoin: URI as a fallback, but it only pays to a single address
• In that case we could pass the entire payment through to the vendor and invoice them for fees later (to avoid custody)
• Or we could use a temporary holding address, split vendor/fees from there (subject to legal custody framework)

It was never resolved, because it depends on the business legal framework in place.

[raffecat]

See also #2

[dbrain]

@raffecat Should I document this in #1 ? Bullet points above as a basis suitable?
It's a bit "If you support this URI and dogeconnect you also need to be aware that you may get the fallback payment and need to handle that" which isn't super "in your face obvious" or at least it comes up a lot implementing it here.

"Yeah using the /pay relay it works like that but the user could be on an old wallet and its just a pay doge to address scenario at that point so we need to handle the variants there"