YeNom - Turning Money Around
Table of Contents
Introduction:
It would be hard to overstate the vital increases of production gained via the division of labor (specialization) and cooperative effort (economy of scale); and both are fundamentally fueled by money (mankind's second greatest invention). Control over monetary systems consequently represent the single biggest political power game known; and any deceptions conceivable are employed to maintain monopolistic rule of this commodity. In modern times the art of money magic has advanced to a state where all major currencies are now fiat, and none can be redeemed for anything (much less something resembling a long term store of value). Be all that as it may, there is no need to be subjugated by any proprietary monetary system especially given the technology available to us today.
My proposed plan wholly steps outside the status quo to directly advance alternatives that play in parallel with the current system. Moreover, our objective is NOT so much to advocate new means of addressing daily transactions. The focus instead is to actually introduce a new means of owning wealth than can be directly monetized to the firsthand benefit of said owners.
This system and the underpinning principle is termed "SUYO" (simple undeniable yank-proof ownership - Spanish for "yours"). The new ownership entities called YeNoms enjoy the (expected) characteristic of being indisputable, unforgeable, and thief proof. YeNoms could be anything from highly visible recognition rewarded to competent individuals to ownership in a company.
Essentially a YeNom is simply a text file archived in the Germ World Record database (GWR) and represents a publicly recorded comment that is (PGP) digitally signed by first its originator and then its recipient. The following cites some characteristics:
1) While the originator and recipient of a YeNom may or may not be anonymous, they are both unambiguously identified via their (PGP) keyIDs.
2) A YeNom is very much an owned thing. The initial owner is the recipient as designated by the originator. In fact, a YeNom doesn't even exist until it is owned (i.e. digitally signed by recipient and entered into the GWR).
3) The recipient (owner) of a YeNom has unlimited rights and power to transfer their YeNom to another willing owner.
4) All YeNoms are archived in the GWR database which is freely read accessible by anyone via the Internet.
5) While a {YeNom} comment might typically grant recognition or ownership title to the recipients, said comment could literally be anything (digitally speaking).
6) Although there are no limits on a comment and thus its significance, the only YeNom items/fields assured to be indexed by the core GWR database are:
a) originator's (PGP) keyID
b) inception-date of the {YeNom} gesture
c) recipient's (PGP) keyID
d) redemption status
e) rejection status
f) date of genesis or most recent transfer-date
g) current owner (if different than recipient)
7) There may easily be hundreds of differently oriented YeNoms as alluded to above, and their categorization is an excellent project for 3rd parties. However, every YeNom authored will carry a Redemption status of "No", "?", or "Yes". The default is "No" and indicates that the originator has no plans to extend any further reward to recipient (other than the embedded {YeNom} comment itself). "?" signifies that originator would like to redeem the YeNom at a latter date if possible. And "Yes" means that the YeNom currently contains a redemption privilege. In other words the YeNom is also basically a coupon the recipient (or any subsequent owner) can present to the originator for fulfillment. Originators are encouraged to be conservative on this issue. A Redemption status of "No" in no way prevents anyone (including originator) from tendering an offer to acquire/redeem any given YeNom.
Details:
1) The process starts with an originator writing a {YeNom} gesture containing a comment for the recipient. Said gesture is (PGP) digitally signed by originator, and then sent to recipient via email or an angel.
2) An actualized YeNom always needs to specify the recipient's 8 digit hexadecimal (PGP) keyID. A gesture without a keyID (either because the recipient's public key is not available or non-existent) is called a casual.
3) The recipient who receives a {YeNom} gesture can ignore or accept/reject it. "Ignore" is just that, while accept/reject requires action on the recipient's part and is a necessary step to bring a YeNom into existence.
4) A casual {gesture} must first be fixed by the recipient inserting his (PGP) keyID. The whole thing is then digitally sign using recipient's private key (which may have been newly created just for {YeNom} gestures).
5) To reject a YeNom requires recipient to write in a "reject:=yes" field before digitally signing the originator's gesture. Recipient should also illuminate with some commentary of their own.
6) After being signed by recipient, the package is now known as a {YeNom} iCandidate and is ready for submission it to a registry-node.
7) The registry-node verifies that the originator and recipient digital signatures in the iCandidate are valid and checks for any preexisting YeNom with an identical UID.
8) After the above test are passed, the iCandidate is then included into the GWR database, and we have finally actualized a YeNom with our recipient as its first owner.
9) Recipients could both emit and receive offers concerning their YeNom(s). Should the transfer of YeNom ownership be mutually desirable, transaction details are first appended to the YeNom (by whom ever). The whole package is then digitally signed by the current owner and sent to the prospective transferee for their authorizing signature.
10) After being signed by transferee, the package is now known as a {YeNom} tCandidate and is ready for submission it to a registry-node. This technique assures that the YeNom's full history always remains intact.
11) The registry-node verifies that a) all the digital signatures (and being a transfer there could be several) are valid and b) that the tCandidate is identical to the existing YeNom on file with the exception of the additions noted in 9 & 10 above.
12) After the above verification and validation test are passed, the tCandidate now becomes the new current YeNom in the database (replacing its predecessor and thus effecting the transfer).
13) There are two main means of expiring a YeNom.
a) The originator offers to redeem or buy back the YeNom and the current owner signs off to make a tCandidate. Once this is submitted and validated by a registry-node its UID is retired and never used again.
b) The (PGP) key pair of current owner is revoked.
Observations:
1) The notion of a market in something like 'compliments' may understandably seem curious, but here are some ways this could come about.
a) Anyone (with Internet access) who wants a copy of any highly renowned YeNom can get as good a copy as the owner herself has. Nevertheless the legitimate owner is still readily recognized by all thanks to their digital signature appearing at the bottom of said YeNom. It's like a virtual collectors item with 100% assured authenticity and who's ownership is undeniable. Now should an owner (for whatever good reason and in return for whatever consideration) transfer ownership of their YeNom to another; then the new owner along with the originator stand to be well gratified.
b) The GWR database represents an ideal vehicle to search for talent due to its rich array of well considered comments filed on hundreds to thousands of individuals from knowledgeable and esteemed colleagues. Given a huge database with good search abilities; it's reasonable that a Deja-News phenomenon could be enjoyed where some unexpectedly exciting advantages emerge. Anyone searching for a new angle on the direction of technology will want to analyze our data. And entities wanting to award funds to deserving efforts (or causes) could find both i) excellent candidates in the GWR database plus ii) a novel - visibly on record - means for effecting their distributions by buying-up YeNoms.
c) Some envision a system for making small payments to musicians an option that's embedded within their digital works. Well, while a few YeNoms may only be equivalent to a public 'pat-on-the-back', many thousands of them could take on significant meaning. YeNoms represent an excellent means for anyone from concert promoters to end consumers to find the real scoop on hot upcoming performers.
d) Heroic causes could likewise gain from YeNom support since a mountain of YeNoms could well play an important part in elevating their visibility with follow on advantages. Consider a conscientious celebrity with more influence than funds (of which the free software movement perhaps has its share). Such individuals could bestow YeNoms to their favorite causes. These YeNoms could in-turn contain a welcome by the originator to their fans/backers to help redeem the YeNoms (with a clever bonus possibly employed). Alternately, the YeNom could contain a coupon for say one free speech on the evils of software patents which the recipient could then sell/transfer to their benefit.
e) YeNom participants may even strongly encourage would be supporters of whatever form to proffer their proposals through the YeNom system.
2) One might note with reason that this kind of turns private-public key technology on its head. Instead of focusing on the privacy of comments, the main objective is to maximize wide public exposure with minimal possibilities for forgery. Nevertheless, private/encrypted files will still play a vital role in the objective(s) of some YeNom strategies.
3) While there is no limit to the number of times a YeNom can be transfered, the originator and recipient never change. In other words, after the first transfer the current owner is no longer the recipient (as that term is reserved strictly for the original owner as designated by the equally unchanging originator). In fact, the consistent identity (UID) of any YeNom is basically the keyIDs of both the originator and recipient plus a time-stamp.
4) A basic principle behind this scheme is zero coercion or punitive sanctions (at least from core system developers). Everything is voluntary from originating gestures to owning YeNoms to even standing by commitments. Core developers are only providing the YeNom submission mechanism and a well kept public GWR database for tracking and trading. Consequently, if someone defaults on a commitment then their hopefully effective punishment is simply - public exposure. Note: prospective users who find this disconcerting are welcomed and encouraged to deploy strategies such as contracts and deposits among themselves to insure good conduct. Additionally 3rd party developers could create protective governing structures that individuals could elect to join. Success of said "governing structures" will solely depend on how effectively they address needs, and thus attract & retain voluntary participation. In other words, core system developers, are NOT in the policing business (in fact this should be formally prohibited in some form of bylaw). Nevertheless, competitive solutions to crime control are definitely encouraged. Moreover, the core system should NOT indulge in any filtering, bias or discrimination of 3rd party providers, as this must always be the exclusive domain of the users/participants. Individuals involved in core development are however, more than free to a) communicate their opinions via whatever forum they deem most appropriate and b) participate in 3rd party projects for enhanced user services.
5) Obviously this means of comment giving and transfers is hardly restricted to the exclusive purview of the original developer(s). The distinguishing factor that makes a YeNom a YeNom is merely its inclusion and maintenance within the GWR database.
6) While the originator may seem to be the the primary actor, the recipient's (PGP) signature is required before this bundle of bits can exists as a {YeNom} iCandidate. Moreover, the recipient determines if a YeNom is classified as accepted or rejected.
7) A YeNom with "reject:=yes" set is technically and functionally equal in every respect to one 'accepted' (in terms of ownership, transfer abilities and it's maintenance within the GWR). Being 'rejected' merely reflects a (presumably negative) disposition by recipient. It is expected to serve as a spam alert, fraud suspicion, etc. Elaboration within the body of the iCandidate by the recipient is desirable (before signing and submission to a registry-node).
8) Originators and recipients can maintain any level of anonymity desired. Moreover, YeNom participants are welcomed to use both a well established and highly verifiable identity along with anonymous pseudonyms (depending on which best serves users current needs).
9) Bear in mind that the YeNom world, like the natural world itself, is amoral. Morality is left to be determined by the inhabitants.
10) All dates and times will be recorded in Greenwich Mean Time (G.M.T.)
11) File modifications are limited to:
a) originators writing a {YeNom} gesture.
b) Commentary and signing by recipient which promotes a gesture to an iCandidate.
c) Owners with the exclusive power to modify their YeNom property (normally to initiate a transfer).
12) The GWR only holds clean unmodified copies of all current YeNoms and never changes/modifies any of them. Thus entries such as the date of genesis and transfer-date are recorded as separate GWR database fields and do not change the YeNom itself in anyway.
13) The GWR database is truly a crucial component to the appeal of this system. I remember being fascinated with NNTP and the USENET NewsGroups, but found them too frustrating to be very useful. Then Deja News came along and fully transformed this messy hodge-podge into a marvelous unified database and personally favorite resource. At the very least YeNoms would create a dynamic "Who's Who" of unprecedented scope.
Anticipated Questions:
1) WHO R-U Mr. 85E756C6?
The name on the Missouri birth certificate assigned to me is Robert Louis Stockhausen (a.k.a. Zack Clark). Technical services are offered as Logic Elegance. I take photos and want to develop programs promoting talented Central Americans along with established & emerging artists. You can see some of my travel photos starting here. My comrade is Dominic and my gallery of him may hold further insights. And while my photography is now totally digital, I do have experience with film cameras.
The high point of public exposure for me was probably as the 1992 Libertarian candidate running against Richard Gebhardt. This resulted in my being attacked by numerous police (as nationally televised) at Washington University while crowds gathered for the first Bill Clinton - George Bush - Ross Perot debate there. (The story in its entirety is pretty interesting.)
You can see what the newspaper said here (see articles 2-5, 6, 7, 8-10, 11-14 of 31)
2) How do you pronounce "YeNom"
'Ye' with a hard long English "a" so it rhymes with "hay", and 'Nom' as "Gnome" with a long "o". This is a easy enough word to say plus it's pronounced the same in Spanish.
3) What authorizations do you need to implement this plan? -- None.
4) How about legal tender laws?
A Legal tender 'law' is designed to force you into accepting said legal tender (currency) for the payment of public and private debts (denominated in the same currency). So under threat of violence, their official legal tender cannot be refused. Plus taxes often must be paid using a currency denominated the same as the state's legal tender. Nevertheless, individuals are still wholly free to make contracts and exchanges based on any medium of exchange they please. Cheques, credit cards, and debit cards for instance are unequivocally permitted & popular methods of payment but are not generally defined as legal tender.
5) How do you assure that ownership offers via YeNoms are legitimate?
The core system or SUYO providers never assure any such thing in any way what so ever. A recipient simply becomes the undesputed unique owner of the YeNom per se - i.e. a mere file whose significance lies wholly outside the concerns of the SUYO system. The relavance of any YeNom is entirely determined by the perticipants involved. Any third parties that the originators and recipients wish to involve to insure desirable conduct are welcomed and encouraged to offer virtual jurisdictions for police services, contract enforcement, etc. Again, a YeNom that reads, "this grants title to the moon" holds no more or less signicance than, "f-0irQm3i9f8". So while no two YeNoms are ever created equal, they are all treated equal in the SUYO system and the GWR database.
6) Can you briefly run through the main steps to realize a YeNom?
An originator writes-up a gesture for a specific recipient. The body or gist of the gesture is called a comment. The whole thing is (PGP) digitally signed by the originator. This file (named after its UID) is then sent to its intended recipient. If recipient wants to take ownership of the gesture, they should first verify its signature using the originator's public key. And then they simply digitally sign the whole thing using their private key. This makes the gesture an iCandidate ready for submission to a registry-node. For the moment only one registry-node exists and submissions can be made via email to YeMon@world1tours.com. After the submitted iCandidate is received, the original gesture part (written by the originator) will be re-checked for integrity and then the entire iCandidate package is tested against the recipient's public key. If both the signatures verify then the iCandidate is stored in the GWR database and verification of the new YeNom with the recipient as owner is sent via email. For now the GWR is available to the world at http://yenom.biz/GWR.
7) Are all the terms you tediously define really necessary?
Maybe not, as I certainly do not want to complicate things with unnecessary verbiage. The goal is to add precision and clarity to dialogs. The terms are hopefully intuitive and if conscientiously employed should make communications more explicit and brief. Notable terms are gesture, iCandidate, and YeNom to reference the comment package at different stages of advancement. The reason behind my perhaps belabored distinctions parallel the need to succinctly distinguish between a "bill" and a "law" in legislative processes.
8) Is it fair to say that you are making a rather big deal over an idea that is really pretty simple?
Yes. I'm actually a bit stunned that no one as already picked up on something this obvious. And making a big deal over it is just what I feel is merited. One reason is that it holds the promise of fulfilling a real need. And another is that considered care is required to best structure a flexible robust system capable of handling unanticipated demands and growth.
9) What kind of software do you see as being necessary?
a) One intriguing feature is that users (originators & recipients/owners) can employ the system with zero specialized application software. All one needs is GPG/PGP, a text editor, an email client, and a Internet browser. So while a nice application could streamline the process and make it more appealing for users, none is required.
b) Database specifications are not fancy, but should be designed to handle potentially billions of YeNoms. Initially there may be only one registry-node and subsequent nodes may simply be mirrors with each maintaining the entire monolithic database. Eventually the database may be distributed with some nodes maintain only portions of the entirety. Hopefully the gnutella network could lend itself well to supporting the GWR database and global distribution of YeNoms to all on demand.
10) If you're talking about trading YeNoms, then doesn't that beg some means of quoting values? Yet nothing has been said along these lines at all.
Exactly. I do not believe this is the sort of thing that developers should involve themselves with, as it would likely become a pretty nasty tar-baby from several angles. I am confident that it is much better for users to evolve their own means of handling this. Service boroughs are welcomed to emerge that function on top of the SUYO system to help facilitate evaluations and trading. Our mission is merely to provide a sound platform with the flexible underpinnings necessary to support and encourage the growth of various 3rd party extended capabilities.
11) What's with the notion of a recipient signing a gesture yet still rejecting it at the same time?
A recipient may be presented with a gesture she does not appreciate, but may still deem it desirable to put the whole matter on record. Consequently she signs it while setting "reject:=yes". This is likely an unhealthy condition to impose on a YeNom in terms of how other humans perceive said YeNom. Nevertheless rejections are technically neutral and have no effect on how YeNoms are handled within the system.
12) Sounds like you might be inviting flaming, etc.
Flaming should not be a significant issue (despite the rejection option). The formality of the YeNom process should cause people to be careful and considered in their usage (as a YeNom truly represents a sword that cuts both ways). Consequently a level of maturity and sobriety is anticipated that better serves all involved. It will also help immensely for high profile users to set good examples by creating gestures that are well thought out and clean of distracting emotional content.
13) Why are you totally refusing to recognize any moral standards much less defend them?
YES, to be blunt - SUYO knows only one sacred morality that all participants are required to recognize, and that is exclusive OWNERSHIP with right to transfer. More exactly ownership of a YeNom as mutually created by a giver (originator) and a taker (recipient) with the owner being the last private key to have signed a valid YeNom. SUYO interest and responsibility starts and ends with this ownership. The worth, meaning, or value of any given YeNom is wholly a matter for participants to determine with or without the help of third party services they may elect to employ. The reason for this is absolutely crucial, as our system - this game - is envisioned to be an experiment in pure anarchy. Consequently, core system responsibility must end at providing a simple, sound, safe & knowable, yet no-holes-bared playing field, with game rules selected to maximize player freedom and options. A simple clean kernel - a genuine meta-germ loosed of artificial authorities to grow free, is all that can properly be provided by the SUYO component. Finally note that a "safe playing field" could be utilized for some very vicious games, so player beware and please feel free to embrace any safeguards or jurisdictions that best protect & promote your needs & interests.
14) Doesn't all this smack of 'IP' sorts of things and the type of evil ownership that many in the free software movement are fighting??
Excellent question - if I do say so myself! Actually, I'm confident that most will readily see through the above question, but I want to answer it anyway.
a) Introduction: I personally would be very much adverse to using any form of copyright or licensing what-so-ever that is enforced by non-competitive government (as use of such 'services' only advances intervention by the regime). However, while enforcement of the copyleft strategy does rely on governmental coercion; it is an consummate example of the exact type of creative mechanism than I morally support (since the precious precedence it establishes far out weighs any collateral problems - plus it cuts them with their own knife!). In a like manner, the YeNom has characteristics reminiscent of the digital works many wish to place under propriety 'protection' of various sorts. However, there are some vital twists to this animal that makes for a whole new class of digital ownership; and who's popularity will categorically undermine traditional propriety propensities.
b) Ownership of a YeNom is clearly the opposite of placing digital content out of reach of others. In fact the entire system is intended to maximize dissemination and accessibility. In the YeNom domain, individual OWNERSHIP is validated, assured and enhanced by increased public possession! Isn't that the reverse of the strategy perpetuated by the propriety camp? Admittedly, YeNom ownership does not enjoy the rights of ownership based on the same (scarcity) principles of the plate of spaghetti one makes. Instead it is based on the rights of gift giving - for those who subscribe to that mode of thinking (i.e. rights).
15) OK, lets say we've got a simple quaint means of effecting trades of these curious YeNoms. But if a YeNom could represent most anything then why in the world did you ever focus on something so abstruse as 'compliments'? Do you intentionally want to make the system difficult to accept?
If presented correctly the formal registration of dignified recognition via this means will fulfill a gaping need - namely raising the visibility of significant contributors to important projects (of science, art, or politics). After a solid base is developed in a safe and friendly environment the (technical) stage will then be set for expansion into other arenas. Just as important, critical modes of right thinking will have time to solidify. The moral defense of paradigms necessary for the ethical alternatives demanded by a rational society will then be better assured.
16) Just how much work do you think this whole thing represents?
Many thousands of times more than could possibly be accomplished by any work force we might pull together. However, we are only going to do the 'kernel', while the rest of the enormous 'OS' is going to be contributed by a multitude of madly imaginative 3rd parties. And on top of all this, the greatest value will come from the distributed mass efforts of millions of users creating wealth through YeNoms.
17) Given your stance against coercion, is it fair to say you're soft on crime?
This issue is simply way too complex and important to be unilaterally decided by any means other than open ongoing competition (where fairness has never been more unmerciful). In principle (and I would not say this in public) punishments imposed by electively embraced covenants could run the gambit from suicide pacts to masochistic pleasures. Consensual contracts are not (IMHO) within our right, power, nor best interest to judge. My personal bias is to favor schemes of governance that focus on the denial of (their) services to varying degrees. This holds the attraction of: a) being innately easy & clean to implement, and b) the punishment is ever more effective only to the corresponding extent that the governing body is successfully supplying a desirable service.
18) OK, but now I'm seeing words like "ongoing competition" and "unmerciful" which don't sound copacetic with the spirit of "sharing with your neighbor" etc.
The GNU group, Gentoo, and even individually speared efforts like Zero Install (among hundreds of others) are already practicing (what I believe is) the unstoppable wave of the future. Here the primary objective is NOT to subdue your competition via proprietary practices and vicious licensing tactics as propelled to a crescendo by dear Mr. Gates (a true genius at boundless audacity). Instead, the basic overall objective of competition is now simply the attainment of superior solutions. The above three entities are notable for actively directing perspective users/clients to the competition in the (gnu) spirit of advising the consumer of all the free options available for evaluation.
19) What prevents someone from creating millions of key pairs and then playing the role of both originator & recipient to create untold numbers of YeNoms and eventually break the system with garbage?
The cost-reward ratio should minimize this type of attack. Anyone with the ability to cause a serious problem would much more likely be spending their time deceptively gaining high search engine ratings, etc. Nevertheless, such attacks could, in theory, become a problem. There are many avenues for dealing with this kind of thing from monitoring incoming IP addresses to imposing conditions on YeNoms where both originators & recipients are anonymous (by limiting their lifetime in the GWR or requiring one of the public keys to be signed by a knowable agent - etc.). The issues to stress at this point are: a) the GWR database software has to be free, plus b) plans need to be in place that address such contingencies should they arise. Optimal simplicity, however, is always the goal, and the less filtering or conditions needed the better. The intrinsic nature of a system should be its best defense as opposed to patches applied after the fact.
20) How will you regulate 3rd party service providers??
3rd parties will thrive and die according to the degree of long term quality service they can afford to other participants so no coercive regulation is necessary. A key point to remember is that everything is elective. So regulatory bodies (services) could exist that attract a huge followings. Consequently if service providers of various types fail to meet the standards of some particularly esteemed regulator then they may likely fail to gain many clients. Moreover, said regulators need not necessarily be pillars of freedom to offer their services. If, for example, the SEC wanted to offer evaluation or registration services then they'd be perfectly free to compete in this arena.
21) How does a massive open GWR database relate to the right to privacy?
It relates to this in the exact same way it relates to a right to work, a right to education, a right to vote, a right to ramble, etc.
22) OK, so the technical sorts can start participating in this system today, but won't it be a huge problem to make the process easy enough for the general public to use?
I don't think that would be a big issue (thanks to 3rd party solutions). The really immense stumbling blocks are NOT technological, but emotional and mental such as fear of freedom, religious reverence for the dollar, etc. The moral plane is where the only true battles lie.
Definitions:
accept/reject: This is an attribute of the YeNom which merely reflects the basic propensity of the recipient toward said YeNom. If not eexplicitly found within the {YeNom} iCandidate then the default rejection status is "reject:=no" (i.e. accepted).
candidate: This represents either an iCandidate and/or a tCandidate - see following.
iCandidate ( initial Candidate): A gesture that has been signed by recipient and is thus ready for submission to a registry-node.
tCandidate ( transfer Candidate): A transfer request that was first signed by current owner and then by the new owner-to-be, making it ready for submission to a registry-node.
casual: This is a gesture that lacks the recipient's (PGP) keyID. The recipient will need to supply this before signing and submitting to a registry-node.
comment: this is the gist of a YeNom. It can really be any digital content, and could amount to say 1) a compliment or constructive critique, 2) an ascii-armored binary (ogg/mp3/jpg/dvd/etc) file/work, 3) a corporate stock option, 4) a discount coupon, 5) an election vote, 6) etc.
[A {YeNom} comment, however, needs to be restricted to an upper size limit - say 8k. Since compressing a DVD into 8k represents a stiff challenge, the originator would cite a URL that points to the file of interest along with its SHA1 digest.]
date of genesis: This is when a YeNom first comes into existence by being entered into the GWR database. It occurs right after a registry-node verifies the signatures of the originator and recipient along with the iCandidate's UID.
angel: This is a possible service run form a registry-node that (as a minimum) forwards only validated gestures to recipients via email, RSS, a messaging protocol, the gnutella network, etc.
gesture: A text file containing a comment for a recipient as identified by their (PGP) keyID. They are created and dated by their originators. The very first line of a Gesture (before being signed) must contain it's UID. Gestures become YeNoms after signing by recipient and entry into the GWR database by a registry-node.
GWR: This acronym stands for Germ World Record (database). The very existence of a YeNom is defined by its presence in this database. Registry-nodes are the unique administrators of the GWR.
inception-date: This is the date of a {YeNom} comment as assigned by the originator, and likely the date presented to recipient.
originator: a (PGP) keyID identified entity who creates/originates a formal {YeNom} open text gesture containing a comment for a recipient.
recipient: the (PGP) keyID identified entity who is the object of a {YeNom} gesture.
SUYO: this acronym stands for Simple Undeniable Yank-proof Ownership (Spanish for "yours") and is used to define the core system along with its moral underpinnings.
redemption status: This is a basic category of state for any YeNom and is assigned by the originator when the gesture is written. States include: "No", "?", or "Yes".
"No" (the default), means that the originator has no plans to extend any further reward to recipient other than the embedded comment.
"?" signifies that originator would like to eventually redeem the YeNom if possible.
"Yes" indicates that the YeNom currently contains a redemption privilege and is thus basically a coupon.
registry-node: This is where a {YeNom} candidate is submitted for inclusion into the GWR (normally but not necessarily done by recipient). Established PGP key servers are excellent contenders for upgrading to registry-nodes since they currently fulfill an important related service and do many of the types of things desirable for this function. It is also envisioned that registry-nodes will run a messaging system (angel) designed for the forwarding of gestures to recipients.
transfer-date: This the date when a YeNom last changed ownership.
transaction-time-limit: This is a possible item/field found in a gesture or YeNom transaction offer for a change of ownership. It establishes the expiration date of an offer and is particularly needed when an originator or owner wants to make the same offer to successive prospects. It is then the originator/owner's responsibility to not issue a new offer until the current one expires.
UID: This is the universal ID and file name for a YeNom. The UID is assigned by the originator before delivery to a recipient.
UIDs have the following format: FFFFFFFF-YyMDd#.ffffffff
Where "FFFFFFFF" is the 8 digit hexadecimal (PGP) keyID of originator. "-" is an arbitrary delimiter. "YyMDd" represents the inception-date ("Yy"=last two decimal digits of year, "M"=hexadecimal month number [1-C], and "Dd"=day of the month [01-31] in decimal). "#" can designate anything an originator wants and runs the range of 0-9,A-Z,a-z which could allow up to 62 unique gestures being sent to the same recipient on the same day. "." is a required ".". And "ffffffff" is the 8 digit hexadecimal (PGP) keyID of recipient.
Note: The arbitrary "-" delimiter above can be any character most convenient for a user. Hence 85E756C6-061200.135EA668 is equivalent to 85E756C6@061200.135EA668 and indicates the exact same YeNom. So this delimiter can signify anything desired within a personal collection of YeNom files (effecting how files are listed in a generic filer). Using the (PGP) keyID of recipient as a file extension also makes for easy storing by this parameter. In the case of a casual {gesture}, the recipient's keyID was not available and hence needs to be applied by recipient.
YeNom: [noun] A plain text file registered in the GWR database, and minimally consists of a comment digitally signed by an originator and further signed by the recipient. A YeNom's file name is also it's UID (universal ID). [adjective] Identified by - part of - or related to the SUYO system.
z.c.
