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’d like to announce an important update on another goal that I have for this year, which is to clean up and reorganize this site. I have not discussed this goal much since it was really low on my priority list. Actually, it still is.
What I have done is circumvent that task by creating a new blog, edgarsioson.com. My first post there explains my motivation for creating yet another blog. I have updated the About page here to emphasize an easily missed purpose for this blog. When I created tyaga.org, I was really hoping to exemplify how an entity might cultivate an independent currency brand. This involved being as transparent as practical by declaring short-term goals and plainly stating or demonstrating what was actually accomplished or not. I have identified early inspirations such as the Dervaes Institute and PSPad. I even stated a particularly ambitious goal in a post from almost three years ago – “to hire people who are willing to be paid in the tyaga.org currency brand”!
It really has been a mixed bag, with many unfulfilled goals but lots of lessons learned and a few prototypes that I am proud of having developed. I could console myself in thinking that, yes, these experiences are likely to be common to what a ‘currency brand’ start-up would go through. I definitely wish that tyaga.org could have been more successful in convincing others to start a currency brand, but the admittedly rustic information systems and protocols that I have prototyped earlier did not lead to even limited adoption. More capable and polished implementations, like Twollars, was fortunate in eliciting more excitement and at least I got to observe what Prowl – which had a very similar technical premise to Twollars – might have been if I had better skills and resources. Unfortunately, even Twollars seem to be languishing at this point.
On a more optimistic note, the more recent prototypes (NPX and IPP) are just a bit more polished and thought-out, and the code is definitely more maintainable. I am also in the middle of conducting simple studies, which I’m hoping could lead to more effective implementations and collaborations. If you are curious, just email me and I’d be happy to share preliminary results.
That’s pretty much it for now. I’ll post here two to four times a year, but I’ll post more frequently in my personal blog. My next post should include the year-end review, as usual.
The three main goals for this year are:
1) By spring: Finish coding and doc’ing the updated demonstration of a budget-centric accounting system to serve entities that issue independent currency brands. The transactional back-end is pretty much done, with inclusion of xtype accounts for double-entry of inter-entity transactions and IPP support to facilitate payments across independently administered ledgers and accounting systems. The administrative and user interface should be updated soon.
2) By summer: Conduct smaller studies prior to an actual exploratory study. I’m still working out the details of these intermediate studies, but I’m confident that these low-risk steps will yield useful information for conducting effective studies in the future.
3) By year’s end: As some of the implementation concepts and strategy take concrete shapes, a more user-friendly website is being planned to offer accessible materials to general audience types. I’m sure most readers are not interested in following the always-changing technical implementation details, and perhaps there are even less who are interested in the philosophies and principles discussed at satconomy.org. At the same time, I am not really looking forward to creating yet another website, so this is lower on my priority list.
For the rest of the year, I will investigate a substantially different approach to PaCT. I have learned important lessons while working on Prowl and PaCT this year, which has prompted a series of changes since early this summer.
The main lesson has to do with the importance of non-repudiation in a payment protocol such as PaCT. I have been trying to avoid designing PaCT around asymmetric encryption, with the idea that anything involving public key distribution, verification and revocation would lead to too much system complexity. Unfortunately, the ‘independent-witness-on-demand’ idea produces its own set of complexities while not giving as strong a sense of non-repudiation as a digital signature from each entity. In addition, it is more appropriate to move the concern of transparency to the separate stage of periodic report publication and audits.
I plan to revise code and documentation to reflect a refined strategy to be built around a core manifest or declaration document. Each entity with its own currency brand publishes a url to its manifest. The manifest will contain three main elements: certificate, accountant and report.
- Certificate element: describes an entity’s public key and a list of certificate urls (x.509, pgp or some other format) for verification purposes. As with any pki or web of trust schemes, a seller must trust the issuer or endorser of the certificate and support the representation format used.
- Accountant element: describes an entity assigned url for submitting transaction records. A designated accountant will be able to produce or verify digital signatures on an entity’s behalf. There may be a list of urls when different accountants are used for different currency units and transaction processing protocols.
- Report element: describes the corresponding urls to a list of audited and pending reports. Child elements will include transaction period, currency unit, auditor, content-type, etc.
More details to follow in upcoming posts.
After debating whether to move forward by coding a market implementation package or documenting the IS Plan more throughly, I have decided to allocate more time on the latter. I intend to finish drafting additional pending documents for Q2 2009, and to move to market implementation packaging for the second half of this year.
While I feel that practical demonstrations are always more convincing and more easily grasped than written plans, there is a clear need to explain the ‘tyaga’ approach to currency design that lists information system functional requirements and shows the strategy for the separation of concerns. This need became more apparent after I drafted the prowl_layers diagram. Even though there are now more systems that use the publication-oriented approach, tyaga’s IS Plan seems to be unique in positioning the accounting system as a layer that feeds the publisher platform, rather than the other way around as illustrated in the prowl_vs_twollars diagram. I hope to explain the rationale behind this design consideration in the planned document drafts for this quarter.
For now, I will simply note that responsible market entities typically maintain independent accounting systems and ledgers. It would be easier to ask each entity to build on top of what it already uses, to independently declare its own budgets and to self-regulate against those budgets — the only additional effort will be to publish market objectives, periodic tallies and flow records in conventional formats in order to promote accountability and auditability. In contrast, I am skeptical of the perceived benefits/costs in putting the accounting system and transaction control as a layer above the publisher platform.