search

Podcastindex-org / podcast-namespace

A wholistic rss namespace for podcasting
Creative Commons Zero v1.0 Universal
388 stars 116 forks source link

on podcast:value with type="bitcoin" #225

Open vv01f opened 3 years ago

vv01f commented 3 years ago

I wonder how to properly address different address formats. there is the old v1 addresses with least affordable fees but highes compatibility (v1 can be regarded as obselete as of now, just I guess some might still stick to e.g. vanity addresses), segwit enables v2 formats and native segwit bech32 format … soon then new bech32 encoding for taproot etc.

Now how to add a list of those properly in a value-tag so, that the client might be enabled to choose the compatible format?

Would we assume the client to test the encoding, which might fail e.g. in case of v2 formatted multisig-addresses used before segwit? Or is that matter for the method attribute?

vv01f commented 3 years ago

also, how to handle … e. g.

and address attribute according to bolt/bip (optionally) with protocol prefix or explicitly without? looks like the latter for now, dropping the available uri scheme completely.

probably a bad one, but an example: Pentaradio by c3d2

daveajones commented 3 years ago

also, how to handle … e. g.

and address attribute according to bolt/bip (optionally) with protocol prefix or explicitly without? looks like the latter for now, dropping the available uri scheme completely.

probably a bad one, but an example: Pentaradio by c3d2

The address type would be recognizable from its prefix/structure, correct? If there are cases where it wouldn’t be then we could always put in a delimiter with the address type on the end. Something like “<address>;<type>“.

Or, maybe I’m misunderstanding you. If so let me know.

vv01f commented 3 years ago

The address type would be recognizable from its prefix/structure, correct? If there are cases where it wouldn’t be then we could always put in a delimiter with the address type on the end. Something like “<address>;<type>“.

that's not sth I would expect, rather in future the idea could be that addresses are indistinguishable for what they might imply.

the proposed expression would be completely non standard, I'd think it's better not to stirr up things and stick to RFC/BIP/BOLT etc.

another (on the example) example is bank transfers, there is a rather not helpful SEPA QR Code and the "Bezahlcode" (payment code) URI available in billing implementations … so I took the latter until I stumble over a better alternative