{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-20\n📝 Original message:BIP 0070 has been a a moderate success, however, IMO:\n\n- protocol buffers are inappropriate since ease of use and extensibility is\ndesired over the minor gains of efficiency in this protocol.  Not too late\nto support JSON messages as the standard going forward\n\n- problematic reliance on merchant-supplied https (X509) as the sole form\nof mechant identification.   alternate schemes (dnssec/netki), pgp and\npossibly keybase seem like good ideas.   personally, i like keybase, since\nthere is no reliance on the existing domain-name system (you can sell with\na github id, for example)\n\n- missing an optional client supplied identification\n\n- lack of basic subscription support\n\n*Proposed for subscriptions:*\n\n- BIP0047 payment codes are recommended instead of wallet addresses when\nestablishing subscriptions.  Or, merchants can specify replacement\naddresses in ACK/NACK responses.   UI confirms are *required *when there\nare no replacement addresses or payment codes used.\n\n- Wallets must confirm and store subscriptions, and are responsible for\ninitiating them at the specified interval.\n\n- Intervals can *only *be from a preset list: weekly, biweekly, or 1,\n2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause\nsuspension until the user re-verifies.\n\n- Wallets *may *optionally ask the user whether they want to be notified\nand confirm every interval - or not.   Wallets that do not ask *must *notify\nbefore initiating each payment.   Interval confirmations should begin at *least\n*1 day in advance of the next payment.\n\n\n*Proposed in general:*\n- JSON should be used instead of protocol buffers going forward.  Easier to\nuse, explain extend.\n\n- \"Extendible\" URI-like scheme to support multi-mode identity mechanisms on\nboth payment and subscription requests.   Support for keybase://, netki://\nand others as alternates to https://.\n\n- Support for client as well as merchant multi-mode verification\n\n- Ideally, the identity verification URI scheme is somewhat\northogonal/independent of the payment request itself\n\nQuestion:\n\nShould this be a new BIP?  I know netki's BIP75 is out there - but I think\nit's too specific and too reliant on the domain name system.\n\nMaybe an identity-protocol-agnostic BIP + solid implementation of a couple\nmajor protocols without any mention of payment URI's ... just a way of\nsending and receiving identity verified messages in general?\n\nI would be happy to implement plugins for identity protocols, if anyone\nthinks this is a good idea.\n\nDoes anyone think https:// or keybase, or PGP or netki all by themselves,\nis enough - or is it always better to have an extensible protocol?\n\n- Erik Aronesty\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160620/947bebda/attachment.html\u003e"}