rich1.0npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55chttps://nostr.ae/npub1w7tezshngplj3fd8r9twxv6zujrwaxq7v98q6t4rdhd0y7u2tfnsmwj55cnjumphttps://nostr.ae📅 Original date posted:2012-11-28 📝 Original message:> RE: the ifex-project and other electronic invoicing standards: Thanks > for the pointers, Walter! I'm all for adopting the best ideas that > have come before, as long as we end up with something useful and small > enough to convince ourselves it is as secure as we can make it. Fair enough, although I would posit: 0. You can't get more secure than not doing it at all. 1. Small is sometimes beautiful, but sometimes just the 999th crippled and half-featured attempt at a nontrivial problem space (...linked heavily to implementation-time assumptions and/or specific peer systems, and by its very nature destined for the dustbin of time? Well, maybe. Eventually, we all are.) 2. X.509 is not small (or beautiful, unless one is some weird new kind of centralized cryptographic trust fetishist, of some sort you might see with furrowed brows, boozing at midday sporting key & anchor tattoos in old convention polo-shirts, mumbling to themselves about the employee-motivation benefits of single sign-on...) > looked at the ifex spec, and quickly got lost. It would help me if you > could write up what our motivating use cases would look like if > implemented on top of ifex. Yes. Understandable. Thoughts around an IFEX protocol proposal, unlike the other proposals, are still drafty (err...as a coastal verandah?) and not the clearest. However, we have much research and progress has been achieved in the odd year-or-so since beginning. The fundamental concerns of such a protocol (regarding the establishment of neutral, open and technically-viable proposals for internet-wide currency/commodity, market and financial endpoint identification) have already been reasonably met. This has opened the door to the potential for faster progress on the IFEX protocol itself ("a mechanism for the identification, negotiation, description, execution and management of financial transactions over their lifetime"), like, right about now. Which is kind of the same zone of potential functionality (at least in a naive, linguistic comparison sense) that people are talking about here. Because of the hope to garner more interest from the Bitcoin community with this post (do read on!), I spent a bunch of hours today cleaning up and converting the IFEX Protocol's current breezy-draft form back from the wiki formatting it had been lazing and grazing (and growing, albeit slowly) in for the greater part of the year and moving to Github (forks and issues very much encouraged) over here: https://github.com/globalcitizen/ifex-protocol (Discussion list at http://group.ifex-project.org/ actually has quite a few members at present, despite appearances to the contrary) > implemented on top of ifex. Re: "implemented on top of ifex", this is kind of opposite to how IFEX works. IFEX's idea is to provide a flexible yet stable protocol that lets individual (potential, ongoing, or completed) transactions on arbitrary (legacy, conventional, emerging, or future) settlement systems (in arbitrary currencies/commodities) to be described and facilitated (executed, routed, monitored, etc.) in real time, by describing accurately the objective properties of each of those systems and components. So, for example, an end user, requiring a transfer of <x> of <y> currency/commodity from 'point a' to 'point b' would find routes to achieve that, evaluate them in terms of monetary and temporal overheads against their own trust and risk models plus any legal, privacy or other requirements in order to select and effect the most appropriate manner of settlement. In short, IFEX sees Bitcoin as having such-and-such properties, matches that to a need to transfer some funds, and effects the transfer, monitoring and/or reporting on its state in a normalized fashion throughout its lifetime. I'll try again to describe the motivating use case: ============== Recognising that Bitcoin is not the only emerging financial community or settlement system facing real world business integration challenges, and recognising the significant complexity of these in common situations (multi-hop transactions, arbitrary currency transactions, foreign exchange automation, liquidity guarantee challenges, settlement latency negotiation, invoicing periods, commercial payment or shipping terms, sovereign (exchange rate fluctuation) and other forms of risk management, potentially simultaneous multi-level fee, tax and discount requirements, product/service coding, line items, complex tax calculations (particularly in the US, and which may be based on both buyer and seller geolocation), legal requirements to include various metadata, etc.), instead of investing valuable developer time on internal implementation (and subsequent maintenance) of a tightly-scoped (==crippled?) business-level protocol extension to Bitcoin that can be perhaps fairly characterised as unlikely to quickly evolve to meet many of these real world requirements, and with as yet unclear real world demand for such from the Bitcoin community, who must already overcome significant complexity hurdles to use Bitcoin at all, Bitcoin developers can instead simply declare this "out of scope" (win!) and focus on Bitcoin's current roles as a digital commodity and settlement system. This approach to scope limitation has excellent historical support from the unix community - "do one thing and do it well". Bitcoin already does a few things, notably in its triple roles as network-community, currency-like-commodity, and settlement system. The alternative is that instead of creating load for the Bitcoin developers, who may be ill-equipped and ill-resourced to properly tackle these peripheral requirements, interested parties instead contribute to projects like IFEX that view systems such as Bitcoin as core use cases but are not limited by Bitcoin developer time or project trajectory, and promise re-usability for other conventional, emerging and future currencies/commodities/settlement systems, thus retaining the capacity to attract interest and resources from those communities (and broader, internet-centric interest groups and infrastructure) toward a common goal, while creating a valuable shared platform for interoperability between Bitcoin and those other systems (including legacy financial systems) that allows Bitcoin to objectively showcase its strengths. Net result: Bitcoin developers can focus on Bitcoin. Meanwhile, business level integration things completely tangential to the core bitcoin codebase get done with a far broader scope and applicability, providing a broader community and potential resource base for moving things forward, and presenting a less "shifting-sands" approach to potential implementers (who are safe in the knowledge that their now standardized infrastructure can support a wide range of currencies/commodities, settlement systems, financial network topologies settlement paradigms, and will not critically rely upon any given component system as a single point of failure). Bitcoin, through the platform IFEX develops, gets to compete at the business level on a fair and even basis with legacy and other emerging systems based upon its highly desirable objective properties (speed, reach, low overheads, rapid connection, lack of wacky X.509 certificate purchasing requirements... yet, etc.), such that a business case *not* to use it in various commercial settings becomes difficult to field. Everyone wins. ============== Note that the above basically echoes much of the (less verbose? more digestible?) information available at http://ifex-project.org/ where - along with http://tools.ietf.org/ - the full text of existing proposals are also available, but attempts to do so in a more specific fashion for Bitcoin developer community. Considering the above, and that a single system is never going to meet every person's needs all of the time (yes, even Bitcoin!), I really hope that the Bitcoin developer community will see the benefits of supporting an external rather than internal solution to business level (or at least non directly settlement-facilitating) financial transaction requirements, both for the Bitcoin project itself, its users, and for that broader and longer-term goal (in very much the same spirit) of effecting some sorely-needed, socially positive and lasting change in global financial systems. Nothing can be all things to all people (especially X.509, which can be completely different kinds of pain to all who come in to contact with it) - but at least with an open, platform neutral financial transaction oriented protocol outside of individual settlement system, currency and commodity projects, each new system can stand on its own merit and support the others, deriving shared fruits of increased user base, usability and liquidity through heterogeneous interoperability. Sincerely, hoping to work together with interested parties to move forward in this area (come issue/fork the github repo!), and with the utmost respect for all of the valuable work of the Bitcoin community (though scratching my head a bit on the lack of an April 1 date or punchline for this X.509 stuff!!), and, and, out of breath, Walter Stanish