I have noticed that, lately, my posts regarding implementation plans are becoming more vague. The main reason for vagueness is to minimize the need for explaining changes in strategy, which — readers of this blog should know — happen quite often. I prefer to spend my time coding conceptual plans, rather than talking about them. Nothing communicates the current approach or preferred path better than demonstration of working code.
Still, there is value in sharing general plans, concrete experiences and practical lessons learned. Here are related updates:
As I mentioned in a previous post, I am really proud of how the NPX system and mobile-inspired UI came together. I have decided to not announce this development in other forums because I predict eventual loss of interest similar to what happened when I announced Prowl early last year. If I do not provide working prototypes of two other major infrastructure components, the enthusiasm would simply wither if there are no sustained means of visualizing ‘what-could-be’.
Two technical features highlight my growing reluctance to give more detailed plans. One of the features involved the use of asymmetric encryption to strengthen non-repudiation. Although blog posts from last year emphasized PKI-type verification, the plan changed early this year based upon farther reflection on OpenTransact’s approach, which is to leave payment verification details to OAuth specs. That approach allows OpenTransact development to proceed faster as an orthogonal concern.
I decided to use a similar approach to speed-up my own development effort for an InterEntity Payment Protocol (IPP). However, instead of tying IPP implementation to a particular verification scheme such as OAuth, it seemed that IPP should be able to accommodate different verification schemes depending on the capabilities and preferences of accounting systems. The end result is that PKI-type verification is just one of two schemes that I have prototyped to work in NP, the other a simpler scheme of querying the accounting system directly through HTTP. Different types of verification schemes could be added and modified later, the important thing is that there is a working payment protocol between independent ledger systems.
The other technical feature example is seller-credential-caching at the user-interface level, like bookmarked information for sending payment at-will to a favorite merchant or charity. Although I was initially excited about this feature, I did not announce it since it might prove to be a not-so important feature eventually. And that was what happened. After spending much time developing code and related icons, I ended up discarding that feature based on usability concerns such as expired credentials, mobile display, etc.
I am still taking my time with other commitments before going back to coding projects. Although I have been eager to prototype another infrastructure component since the end of last year, I really held back so that I could concentrate my spare time completing the NPX prototype. I realize that I am being vague again regarding the next steps, but I will provide more details based on actual experience and whether or not my conceptualized approach turns out to be feasible. Right now, I am still trying to determine how much time I could realistically devote to the project next year and how to organize my time in order to successfully prototype the other major infrastructure components.