Last year was really busy, and the first quarter of this year was no different. I accomplished about three of the four goals that I had for 2012. I had finished analyzing and published my study results, demonstrated my prototypes, and presented my ideas at various settings.
However, I was not able to improve the Flora test bed as planned, primarily because I had to adjust to my data visualization role at work. I had also wanted to attend more conferences at the beginning of this year to network, listen, and collaborate but had not much time to do so. There are lots to ponder with regards to how to move forward.
I feel fortunate to be working at a vibrant research institute. It’s instructive to see how much work goes into researching and communicating ideas. In some ways, my unwritten hopes were too ambitious for a project with so little dedicated resources. While I’ve learned through the years to temper my plans, my expectations were still somewhat unrealistic.
This is not to say I have regrets — I don’t. I’ve really enjoyed the process of learning from my successes and mistakes, and the process of cultivating patience, skills, and determination to keep moving forward the best I can. I will also keep making plans to get me moving, otherwise it’s very easy to get into a rut.
So, for 2013, I have these goals:
- Make at least one improvement to Flora. I’m thinking along the lines of user interface.
- Attend at least one conference. The options are CCS conference at the Hague, ICTD/ACM Dev in South Africa, IEEE Vis at Atlanta.
- Long shot goal: publish another paper
Hope to see some of you in one of the conferences in my list.
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).
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.
A series of flowcharts is now available to guide the development and coding of PaCT applications. The flowcharts illustrate the steps that a reporter application takes to cross-verify and witness a published transaction record.
Automated auditing applications could then query reporter applications to ascertain that published reports contain cross-verified transactions. In this way, greater confidence could be built into information summaries as provided by currency brand indexes.
I have just uploaded a heavily revised OCAUP document. The latest revision includes simple tables and attached illustrations. The main difficulty has been, and continues to be, finding appropriate terminology that adheres to common accounting language while purposely avoiding terms that might cause confusion with conventional interpretations.
At the moment, the most suitable terminology relates to “budgets”. Ledger-based currency may be viewed as unused entity budgets that are periodically planned and dynamically reported as inter-entity transactions occur. OCAUP may be used to model and track how well an entity regulates against its self-determined limits. Entities that demonstrate effective self-regulation develop reputable currency brands, which should translate to better market access.
The illustrated OCAUP currency activity and journal entry examples should help explain the “scoring rules/system” that tyaga is trying to establish. Speaking of scoring rules, I also drafted a game-design representation of tyaga’s information systems goals. The OCAUP document also has an attached table that compares mutual-credit accounting systems with OCAUP-based designs.
The following documents are now available to help explain the Tyaga IS Plan:
- An Open Infrastructure for Adaptive Currency Information Systems: This browser-enabled slide presentation explains Tyaga’s approach to separation of concerns, with links to related demonstrations.
- Published and Cross-Verified Transaction (PaCT) Sequences: These transaction sequence examples illustrate the type of system interoperability that would be essential to the widespread use of ledger-based currencies.
In addition, there is now a packaged version of software code, tentatively named Kit, available for download. Kit is a revised version of an earlier Prowl reporter implementation for the Apache/MySQL/PHP platform. The packaged files are also browser-viewable – please browse the filenames for methods and code snippets that might interest you (such as parser.php and the svg-graphing functions.) The Kit 0.2 package is not refined by any means, but it offers basic reporter functionalities.
I will begin writing use cases to illustrate independent currency brand support through the OCAUP accounting model. I’m also hoping to package an acounting system that I developed from last year in order to demonstrate not only OCAUP, but also built-in support for a protocol such as Prowl.
As was planned for this quarter, I have finished updates of key reference documents. The most satisfying updates were the ones for the Trusteeship-Oriented Currency Design slide presentation — adding links to the project’s Demo pipeline items just shows that persistence pays off, even if the some of the demo are still clunky. Luckily, more experienced coders are starting to arrive at the general design strategies that were employed in the demo and explained in posts and documents (see Prowl-Users forum).
I was not as productive towards other goals, but I really needed some time off from the project. I am also starting to reexamine my role in this endeavor. I taught myself to program so that I could prototype and demonstrate my currency design ideas, but recent events may require me to develop and focus on other skills elsewhere.
In light of recent developments in currency design, such as the tentative announcement today at the NCF blog, I have decided to publish an early draft of a paper that I have been working on. I am glad to see an increase in activity that shares more or less a similar design philosophy behind the Prowl demonstration.
Please post or send in your comments, questions suggestions and/or objections that could help improve the paper.
Not a lot of development updates this time, just some thoughts after taking a break from this project. The recurring question, as always, is how to move forward. The project might be described as attacking a specific problem and a more general problem.
Looking at the specific problem of information system design – the product view – the strategy has been narrowed down adequately. There will be orthogonal components or modules for:
- Entity or Publisher: currency issuance and accounting controls
- Reporter: currency brand evaluation and monitoring
- Device: user interface for conducting transactions, most likely to be mobile applications
The Prowl protocol is an attempt to provide the necessary interface between the
orthogonal Publisher and Reporter components. The demonstration is admittedly rudimentary, but the overall design principles should be apparent in the demo: Loose coupling, separation of concerns, late binding as to where additional information might be found through the use of the search-assist string.
The general problem of widescale implementation – the market view – gives the context that will guide the production scale design of Prowl-compliant applications. So far, the general problem has been treated lightly while the product design strategy was being worked out. Although effective system design is not trivial, it is obviously more straighforward than the market implementation aspect.
Right now, a multi-stage market study seem to be the best approach for breaking the general problem into more manageable pieces. More updates will follow once I am done drafting the details of the proposed study.
I am about halfway through coding a common parser for the witness, audit and evaluator functions. This should make it easier to accomodate future changes to the record syntax and report structure. For example, it might be simpler to change the Accounting Model field into a Account Type field, which might imply breaking reports into separate accounts in cases where separate unused budgets are tracked. The only downside is that an evaluator feature would have to do more work in pulling different types of accounts when calculating metrics such as inflow/outflow ratios.