Transition Phase

Perhaps it was inevitable, but here I am starting another blog. I have alluded to making this move in another blog, in order to clean up and reorganize my accumulating accounts of ideas, demos, and white/gray papers. I had to overcome a lot of hesitation extending over a year to convince myself this move is really necessary.

But the time has come and I’m ready for it.

This personal blog will relay experiences and opinions beyond my project-oriented blogs. It was getting harder to filter out indirectly related observations from my posts in, and that’s why that blog has laid dormant for over a year now. I still think that inspirational quotes and observations have their place in a blog such as, but I felt like the blog was losing focus. I felt the same with, sometimes wondering which blog to post recent observations in, since the main purpose for each blog was getting blurry.

The main problem is that I did not have a personal blog as a default ‘outlet’. When in doubt, I will post here rather than my other blogs. I plan to make this my most active blog, which to me might mean a post once a month. The project blogs will have maybe two to four posts a year. I will discontinue a project blog once I feel that it has served its purpose. In that connection, I will update and clarify the About pages in my other blogs.

I hope you’ll follow this blog and enjoy reading it.

Q3 Quick Update

I’m glad to report that I have very preliminary results from my planned studies. Unfortunately, the tests do not involve the NPX/IPP prototype system yet, so I’m holding off giving more details until the end of Q4. Besides, I’ve had to correct serious code error every day this last week — no need to announce unvalidated observations so far.

Still, getting to this point is really encouraging. After holding off for more than a year to get started on this next phase of the project, and after many doubts on when I’ll be able to return to this project in light of my other commitments, I’m relieved to see that the wait has been worth it.

There are also other self-imposed drivers to get results by the end of the year, so I’m highly motivated right now to just get things done. Expect more detailed updates before Thanksgiving (hopefully).

2011 Q2 Update

In the last month, I have been able to slowly ramp up the coding effort to about 8-15 hours a week. The rudimentary code is still exploratory, but I’m optimistic that it’s headed towards the right direction. I’m also relieved to finally be able to rebalance my work/life/personal projects after a very hectic Q1.

So, after some uncertainties in the first half of 2011, I’m looking forward to having a more productive second half. The goal for Q3 is to get actual results to blog about, not just talk about vague, tentative plans like I’ve done for the last nine months or so. The more I read about published research on various computing topics, the more encouraged I get that the approach that I contemplate taking is bound to be a worthwhile adventure.

Cleaned-Up Links in Sidebar

It feels good to clean older references from the sidebar and, more importantly, to highlight the newer demo and docs that went live last year. I really need to work on revamping the whole site as planned for this year, but for now, these minor tweaks should do.

Please visit the slightly modified mobile UI demo — the touchscreen swipe simulation gets easy fast even using a touch pad. And do read up on the help pages and IPP documentation.

Striking a Balance

There really is not a lot to update for the first quarter of 2011, at least not in the form of code and documentation. However, I could easily account for 15 hours a week in March spent on related research activities, which include reading, conceptualizing, and setting strategies. I have read, for example, a few of the latest IJCCR articles. Another web site that I have been reading lately is matslat’s blog. A consistently excellent resource is the Communications of the ACM, which even has an article on virtual goods and currencies in the April issue.

Why bother with ‘conceptualizing’? Mainly to avoid making contradictory or confusing statements. An example would be in this cc typology article, which is an otherwise well-written paper. Blanc’s description of first generation of CC schemes contains the oft-repeated “money is created (at) the very time of exchange.” I have written a while back that this description is misleading when there are debit limits involved in mutual-credit system. As soon as some kind of issuance or trading limit is imposed by a system administrator, the money (as limits) is only exchanged, and NOT created, at the time of transactions. Misleading notions should be carefully filtered out to clarify one what is doing and see where the pitfalls lay.

What about strategies? To use an analogy, strategies are not as crucial in a 100m dash as they are in long distance races. Working on nontraditional currency designs is like a marathon, a long term endeavor where the goals are not clearly in sight and various paths, some untried, are open for exploration. I have long ago shed any misconception that I could code an idea quickly and hope for spontaneous transmission (‘viral’ is another oft-repeated but misleading description thrown around by enthusiasts.) The work requires commitment and endurance, luck and inspiration. It certainly helps to be in a community of similarly-minded advocates, but shared interest is actually less important to me than having a shared notion of what constitutes quality effort.

2010 Review and 2011 Tentative Plans

The year 2010 went by fast. Looking at the three goals for this year, I was only able to accomplish goal #1 which was to code and document a budget-centric system. I was not able to implement even one smaller study (goal #2), although I was able to refine my conceptual approach throughout all of last year. So even though I was not able to work on actual studies, the framework for conducting studies should lead to better implementation and more convincing results. This goal is now 2011:goal #1.

As far as the third goal of recreating a more-user friendly website, I did not make any progress on that at all. It was just really at the bottom of my priority list. This goal will become 2011:goal #2.

After much thought regarding my limitations and abilities, I plan to commit 15 hours a week on currency-related projects this year, starting possibly in March. I am still settling into a new routine, so it is hard to be more definite about this year’s plan. Despite having a good view of long-term goals, I have to be able to fit personal projects around newfound opportunities in order to have a realistic chance of success. I’ll post more informative updates once I get a clearer picture of various responsibilities, schedules, and paths forward.

2010 Q3/Q4 Updates

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.

NPX and UI Release

The much revised accounting system is now available at the “NPX” homepage, or you could go directly to the mobile-user interaction prototype. The corresponding code repositories are accessible at github.

Although I am quite satisfied with the results so far this year, the project is still behind in terms of exploring other areas of study as alluded to in earlier posts. I have been putting off those studies until I get a working prototype of a ledger system that could transact with other ledgers through open payment semantics/protocol.

My plan for the remainder of the year is to establish a more stable work-flow to sustain project development and studies. Basically, I’ll take a step back from actual coding (which I’m not that proficient to begin with)  and take care of somethings now in order to be more efficient next year.

What, How and Why

During the last few months, I have channeled my spare time towards the implementation effort (updates at, which has obviously affected my ability to post regularly on this blog. I would like to catch up by discussing the ‘what’, ‘how’ and ‘why’ of currency traceability as promoted on this site. Hopefully, potential collaborators would see immediately whether or not satconomy fits well with their own vision.

Traceable to ‘WHAT’?

While many non-traditional currency design promotes currency that is traceable to a community or individual, satconomy’s emphasis is traceability to a market entity or organization. This emphasis leads to design issues that are not considered important in currency projects that promote self-sufficient collectives or personal currencies as issued by autonomous individuals. One very important issue is that each entity-issued currency brand is tracked in its own ledger (a collection of  entity-owned accounts and NOT just one account.) The one-to-one correspondence between an owner and an account in a mutual-credit system may be practical for an individual, but not for an entity with many ongoing budget and organizational concerns.

HOW will it be Traceable?

An entity’s budget effectively becomes its currency. As is common practice today, each entity will be expected to administer its own ledger/budget without a requirement to open an account in a centralized database. In the OCAUP accounting model, a flow transaction results in the corresponding cancellation of the payer’s expense budget and the recipient’s revenue budget. Credits are not reusable and do not circulate among entities. Each entity independently manages the life cycle of its currency brand, including account organization, budget creation (i.e., currency issuance), assignment, use and reporting.

WHY should it be Traceable?

Currency traceability, in the context of a dynamic currency index, enhances the ability of an entity to determine the currency brand reputation of other entities. The focus is on being able to reject payments from disreputable currency brands and thus exert pressure on the entity that issued the rejected currency brand. This focus is different from systems that track reputation to guide participants to decide which currency system to join (membership in a community currency) or which network node to extend credits to (lending to a creditworthy participant). In satconomy, participants can support and pressure each other even if they do not belong to the same community or are not networked in some way.

2010 Q2 Updates

I have finished documenting most of the user how-to and UI code. While writing the server code/API overview, I decided to change the transaction API to make it simpler to follow. I am currently revising my implementation of IPP to use status/error codes and to more clearly highlight important patterns. One more month of tinkering, another month of looking things over, and then the updated accounting system package will (likely) be released by the end of Q3.

Just to be clear: Although there is a lot of ledger admin tools for managing and evaluating a particular currency brand in the current package, it will not include a demonstration of a working currency brand index. That’s the next step after the budget-centric ledger/payment/currency system is prototyped.