rich1.0npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925uhttps://nostr.ae/npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925unjumphttps://nostr.ae📅 Original date posted:2012-11-26 📝 Original message:On Mon, Nov 26, 2012 at 4:26 PM, Mike Hearn <mike at plan99.net> wrote: >> Perhaps we should agree to talk about everything _except_ that first? > > Yeah, alternatives to X.509 chains don't interest me right now except > in the sense that they should be cleanly implementable with future > extensions. > > So if you care about DANE or DNSSEC or custom PKI infrastructures or > whatever, rather than proposing them as replacements here (DOA), just > figure out how you would extend the protocol in Gavins mail in a > future extension. If you can't see a clean way to do it then let's > discuss that. If you can think of a way to do it then let's table it. > Better replacements can come in later BIPs. The only part that has an x509 cert associated is in the invoice message. message Invoice { // repeated bytes x509chain = 1; optional string domainName =1; repeated Output outputs = 2; required uint64 time = 3; optional uint64 expires = 4; optional bool single_use = 5 [default = true]; optional string memo = 6; optional string receiptURI = 7; optional bytes merchant_data = 8; } Removing that and adding a opaque string called domain name, or identityName would be sufficient to move the conversation forward without the x.509 baggage. -rick