tyaga.org

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.

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:

Q3:

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.

Q4

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.

The link to older document versions was inadvertently left unchanged with the latest Prowl announcement. The correct link to the latest Prowl document versions is http://tyaga.org/prowl/documents.php.

I have just uploaded a browser-compatible presentation - The NASDAQ of Independent Currency Brands -using Eric Meyer’s S5 system. I also tried Slidy and DOMslides, but eventually found S5 to be simpler to use. The new presentation has only 18 slides and gives what I think is the best overview so far of the satconomy framework and implementation. Even though there is no audio on the slides, a lot of the bullet points are self-explanatory. So please take a look and enjoy the presentation.

The itemized inflow/outflow and online donation links have now been corrected on this site’s ledger page. I must have introduced the form action error after the script had passed multiple tests.

What does it mean to accept tyaga.org currency as payment?

1) As Wages: If you are a member of the tyaga.org entity, accepting it’s currency means that you would be using tyaga.org credits to buy something from the market. You would be relying on the strength of the tyaga.org brand as a means of redeeming products from other currency-issuing entities. At the same time, you would share in tyaga.org’s mission to fulfill its self-determined obligation to the market.

It’s similar to the concept of accepting employee stock grants, in that the granted units are not guaranteed to be redeemable for products in the market (such as cash or equivalent). The difference is that unlike shareholder stocks, the entity member’s credit units are immediately ‘consumed’ in a market transaction and are not transferrable, as explained next through what the seller does with the buyer’s credits.

2.) As Revenue: If you are a seller who belongs to another entity that issues its own currency brand, accepting a buyer’s tyaga.org credits means that you will be cancelling a corresponding amount of your entity’s self-declared debt to the market. A seller cannot re-use the buyer’s tyaga.org credits for subsequent transactions. Equivalent quantities of buyer credits and seller debits are cancelled in a market transaction.

Our product offering is currently limited to a php-based package which demonstrates how a currency-issuing entity might structure its accounts. This product is intended primarily to inform potential collaborators and interested developers of accounting and transaction requirements between entity accounts in a satconomy framework.

For those interested in colloborating with the development of this product, the demonstration package is available for download here or here.

The web security expert must be familiar with php/MySQL development. Must have applicable experience in session management, encryption and transaction processing.

Must be willing to accept payment in tyaga.org currency.

If interested, contact edgar@tyaga.org.

The person in this position will advise on account set-up standardization for a web-based system. Must have previous experience in web-based accounting systems.

Must be willing to accept payment in tyaga.org currency.

If interested, contact edgar@tyaga.org.

Web designer wanted, must be familiar with Wordpress/php/MySQL development. Will spruce up this site, as well as guide the look and feel of the forms in the entity module under development.

Must be willing to accept payment in tyaga.org currency. 

If interested, contact edgar@tyaga.org.