{"type":"rich","version":"1.0","author_name":"npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55c","author_url":"https://nostr.ae/npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55c","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-11-28\n📝 Original message:\u003e RE: the ifex-project and other electronic invoicing standards:  Thanks\n\u003e for the pointers, Walter! I'm all for adopting the best ideas that\n\u003e have come before, as long as we end up with something useful and small\n\u003e enough to convince ourselves it is as secure as we can make it.\n\nFair enough, although I would posit:\n 0. You can't get more secure than not doing it at all.\n 1. Small is sometimes beautiful, but sometimes just the 999th\ncrippled and half-featured attempt at a nontrivial problem space\n(...linked heavily to implementation-time assumptions and/or specific\npeer systems, and by its very nature destined for the dustbin of time?\nWell, maybe. Eventually, we all are.)\n 2. X.509 is not small (or beautiful, unless one is some weird new\nkind of centralized cryptographic trust fetishist, of some sort you\nmight see with furrowed brows, boozing at midday sporting key \u0026 anchor\ntattoos in old convention polo-shirts, mumbling to themselves about\nthe employee-motivation benefits of single sign-on...)\n\n\u003e looked at the ifex spec, and quickly got lost. It would help me if you\n\u003e could write up what our motivating use cases would look like if\n\u003e implemented on top of ifex.\n\nYes. Understandable. Thoughts around an IFEX protocol proposal, unlike\nthe other proposals, are still drafty (err...as a coastal verandah?)\nand not the clearest. However, we have much research and progress has\nbeen achieved in the odd year-or-so since beginning.  The fundamental\nconcerns of such a protocol (regarding the establishment of neutral,\nopen and technically-viable proposals for internet-wide\ncurrency/commodity, market and financial endpoint identification) have\nalready been reasonably met.\n\nThis has opened the door to the potential for faster progress on the\nIFEX protocol itself (\"a mechanism for the identification,\nnegotiation, description, execution and management of financial\ntransactions over their lifetime\"), like, right about now. Which is\nkind of the same zone of potential functionality (at least in a naive,\nlinguistic comparison sense) that people are talking about here.\nBecause of the hope to garner more interest from the Bitcoin community\nwith this post (do read on!), I spent a bunch of hours today cleaning\nup and converting the IFEX Protocol's current breezy-draft form back\nfrom the wiki formatting it had been lazing and grazing (and growing,\nalbeit slowly) in for the greater part of the year and moving to\nGithub (forks and issues very much encouraged) over here:\nhttps://github.com/globalcitizen/ifex-protocol\n  (Discussion list at http://group.ifex-project.org/ actually has\nquite a few members at present, despite appearances to the contrary)\n\n\u003e implemented on top of ifex.\n\nRe: \"implemented on top of ifex\", this is kind of opposite to how IFEX works.\n\nIFEX's idea is to provide a flexible yet stable protocol that lets\nindividual (potential, ongoing, or completed) transactions on\narbitrary (legacy, conventional, emerging, or future) settlement\nsystems (in arbitrary currencies/commodities) to be described and\nfacilitated (executed, routed, monitored, etc.) in real time, by\ndescribing accurately the objective properties of each of those\nsystems and components.\n\nSo, for example, an end user, requiring a transfer of \u003cx\u003e of \u003cy\u003e\ncurrency/commodity from 'point a' to 'point b' would find routes to\nachieve that, evaluate them in terms of monetary and temporal\noverheads against their own trust and risk models plus any legal,\nprivacy or other requirements in order to select and effect the most\nappropriate manner of settlement.\n\nIn short, IFEX sees Bitcoin as having such-and-such properties,\nmatches that to a need to transfer some funds, and effects the\ntransfer, monitoring and/or reporting on its state in a normalized\nfashion throughout its lifetime.\n\nI'll try again to describe the motivating use case:\n==============\nRecognising that Bitcoin is not the only emerging financial community\nor settlement system facing real world business integration\nchallenges, and recognising the significant complexity of these in\ncommon situations (multi-hop transactions, arbitrary currency\ntransactions, foreign exchange automation, liquidity guarantee\nchallenges, settlement latency negotiation, invoicing periods,\ncommercial payment or shipping terms, sovereign (exchange rate\nfluctuation) and other forms of risk management, potentially\nsimultaneous multi-level fee, tax and discount requirements,\nproduct/service coding, line items, complex tax calculations\n(particularly in the US, and which may be based on both buyer and\nseller geolocation), legal requirements to include various metadata,\netc.), instead of investing valuable developer time on internal\nimplementation (and subsequent maintenance) of a tightly-scoped\n(==crippled?) business-level protocol extension to Bitcoin that can be\nperhaps fairly characterised as unlikely to quickly evolve to meet\nmany of these real world requirements, and with as yet unclear real\nworld demand for such from the Bitcoin community, who must already\novercome significant complexity hurdles to use Bitcoin at all, Bitcoin\ndevelopers can instead simply declare this \"out of scope\" (win!) and\nfocus on Bitcoin's current roles as a digital commodity and settlement\nsystem.\n\nThis approach to scope limitation has excellent historical support\nfrom the unix community - \"do one thing and do it well\". Bitcoin\nalready does a few things, notably in its triple roles as\nnetwork-community, currency-like-commodity, and settlement system.\n\nThe alternative is that instead of creating load for the Bitcoin\ndevelopers, who may be ill-equipped and ill-resourced to properly\ntackle these peripheral requirements, interested parties instead\ncontribute to projects like IFEX that view systems such as Bitcoin as\ncore use cases but are not limited by Bitcoin developer time or\nproject trajectory, and promise re-usability for other conventional,\nemerging and future currencies/commodities/settlement systems, thus\nretaining the capacity to attract interest and resources from those\ncommunities (and broader, internet-centric interest groups and\ninfrastructure) toward a common goal, while creating a valuable shared\nplatform for interoperability between Bitcoin and those other systems\n(including legacy financial systems) that allows Bitcoin to\nobjectively showcase its strengths.\n\nNet result: Bitcoin developers can focus on Bitcoin. Meanwhile,\nbusiness level integration things completely tangential to the core\nbitcoin codebase get done with a far broader scope and applicability,\nproviding a broader community and potential resource base for moving\nthings forward, and presenting a less \"shifting-sands\" approach to\npotential implementers (who are safe in the knowledge that their now\nstandardized infrastructure can support a wide range of\ncurrencies/commodities, settlement systems, financial network\ntopologies settlement paradigms, and will not critically rely upon any\ngiven component system as a single point of failure). Bitcoin, through\nthe platform IFEX develops, gets to compete at the business level on a\nfair and even basis with legacy and other emerging systems based upon\nits highly desirable objective properties (speed, reach, low\noverheads, rapid connection, lack of wacky X.509 certificate\npurchasing requirements... yet, etc.), such that a business case *not*\nto use it in various commercial settings becomes difficult to field.\nEveryone wins.\n==============\n\nNote that the above basically echoes much of the (less verbose? more\ndigestible?) information available at http://ifex-project.org/ where -\nalong with http://tools.ietf.org/ - the full text of existing\nproposals are also available, but attempts to do so in a more specific\nfashion for Bitcoin developer community.\n\nConsidering the above, and that a single system is never going to meet\nevery person's needs all of the time (yes, even Bitcoin!), I really\nhope that the Bitcoin developer community will see the benefits of\nsupporting an external rather than internal solution to business level\n(or at least non directly settlement-facilitating) financial\ntransaction requirements, both for the Bitcoin project itself, its\nusers, and for that broader and longer-term goal (in very much the\nsame spirit) of effecting some sorely-needed, socially positive and\nlasting change in global financial systems.  Nothing can be all things\nto all people (especially X.509, which can be completely different\nkinds of pain to all who come in to contact with it) - but at least\nwith an open, platform neutral financial transaction oriented protocol\noutside of individual settlement system, currency and commodity\nprojects, each new system can stand on its own merit and support the\nothers, deriving shared fruits of increased user base, usability and\nliquidity through heterogeneous interoperability.\n\nSincerely, hoping to work together with interested parties to move\nforward in this area (come issue/fork the github repo!), and with the\nutmost respect for all of the valuable work of the Bitcoin community\n(though scratching my head a bit on the lack of an April 1 date or\npunchline for this X.509 stuff!!), and, and, out of breath,\nWalter Stanish"}