The Unassuming GNU.hope
Table of Contents
Introduction:
The underpinning idea of the GNU.hope is to provide a highly visible and effective reward mechanism that recognizes competent individuals.
GNU.hopes are simply text files archived in the GNU World Record database (GWR). More pertinently, a GNU.hope is 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 GNU.hope may or may not be anonymous, they are both unambiguously identified via their PGP keyIDs.
2) A GNU.hope is very much an owned thing. The initial owner is the recipient as designated by the originator. In fact, a GNU.hope 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 GNU.hope has unlimited rights and power to transfer their GNU.hope to another willing owner.
4) All GNU.hopes are archived in the GWR database which is freely read accessible by anyone.
5) While the initial intent for {GNU.hope} comments is to compliment/recognize the work/achievements of recipients, said comment could literally be anything (digitally speaking).
6) Although there are no limits on a comment and thus its significance, the only GNU.hope items/fields assured to be indexed by the core GWR database are:
a) originator's PGP keyID
b) inception-date of the {GNU.hope} 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 GNU.hopes as alluded to above, and their categorization is an excellent project for 3rd parties. However, every GNU.hope 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 {GNU.hope} comment itself). "?" signifies that originator would like to 'redeem' the GNU.hope at a latter date if possible. And "Yes" means that the GNU.hope currently contains a redemption privilege. In other words the GNU.hope is also basically a coupon the recipient (or any subsequent owner) can present to the originator for fulfillment. On this issue, originators are encouraged to be on the conservative side. A Redemption status of "No" in no way prevents anyone (including originator) from tendering an offer to acquire/redeem any given GNU.hope.
Details:
1) The process starts with an originator writing a {GNU.hope} 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 GNU.hope always needs to specify the recipient's 8 digit hexadecimal PGP keyID. Without a keyID (either because the recipient's public key is not available or non-existent), said gesture is called a casual.
3) The recipient who receives a {GNU.hope} gesture can ignore or accept/reject it. "Ignore" is just that, while accept/reject requires action on the recipient's part.
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 {GNU.hope} gestures).
5) To reject a GNU.hope 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 {GNU.hope} 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 GNU.hope 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 GNU.hope with our recipient as its first owner.
9) Recipients could both emit and receive offers concerning their GNU.hope(s). Should the transfer of GNU.hope ownership be mutually desirable, transaction details are first appended to the GNU.hope (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 {GNU.hope} tCandidate and is ready for submission it to a registry-node. This technique assures that the GNU.hope's full history always remains intact.
11) The registry-node verifies that a) all the digital signatures (and in the case of a transfer there could be a great many) of the tCandidate are valid and b) that the tCandidate is identical to the existing GNU.hope on file with the exception of the additions noted in 9 above.
12) After the above verification and validation test are passed, the tCandidate now becomes the new current GNU.hope in the database (replacing its predecessor and thus effecting the transfer).
13) There are two main means of expiring a GNU.hope.
a) The originator offers to redeem or buy back the GNU.hope 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 current owner revokes their PGP key pair.
Observations:
1) The notion of a market in 'compliments' may understandably sound pretty damn curious, but here are some ways this could come about.
a) Anyone (with Internet access) who wants a copy of the worlds very first GNU.hope (as owned by the renowned RMS) can get as good a copy as Mr. Stallman himself has. Nevertheless everyone still has to recognize Stallman as the legitimate owner by virtue of his digital signature appearing at the bottom of said GNU.hope. It is like a virtual collectors item who's authenticity is 100% assured and who's ownership is undeniable. Now if Mr. Stallman should (for whatever good reason and in return for whatever consideration) transfer ownership/title of this article (GNU.hope) to another; then I can see where the new owner could be quite elated as well as the originator (myself in this case).
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; isn't it 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 through the accumulation ('buying-up') of GNU.hopes.
c) I know you have mused about a system to make small payments to musicians an option that's embedded within their digital works. Well, while GNU.hopes in many/most instances may only be equivalent to a public 'pat-on-the-back', many thousands of them could take on significant meaning. GNU.hopes represent an excellent means for anyone from concert promoters to end consumers to find the real scoop on the hottest upcoming performers free of typical advertising hype.
d) Many heroic causes could certainly appreciate some GNU.hope. And like the above examples, a mountain of supportive GNU.hopes 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 GNU.hopes to their favorite causes. These GNU.hopes could in-turn contain a welcome by the originator to their fans/backers to help redeem the GNU.hopes (with a clever bonus possibly employed). Alternately, the GNU.hope 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) GNU.hope participants may even strongly encourage would be supporters of whatever form to proffer their proposals through the GNU.hope system.
2) One might note with reason that this kind of turns PGP 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 play a vital role in the objective(s) of some GNU.hope strategies.
3) While there is no limit to the number of times a GNU.hope 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 of any GNU.hope is simply 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 system developers). Everything is voluntary from originating gestures to owning GNU.hopes to even standing by commitments. Core developers are only providing the GNU.hope submission mechanism and a well kept public GWR database for tracking and trading. Consequently, if a user 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 help insure good conduct. Additionally 3rd party developers could build protective governing structures that individual users 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 GNU.hope a GNU.hope is merely its inclusion and maintenance within the GWR database of GNU.hopes.
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 {GNU.hope} iCandidate. Moreover, the recipient determines if a GNU.hope is classified as accepted or rejected.
7) A GNU.hope 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, GNU.hope 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 GNU.hope 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) Modifications are limited to:
a) originators writing a {GNU.hope} gesture.
b) Commentary and signing by recipient which promotes a gesture to an iCandidate.
c) Owners with the exclusive power to modify their GNU.hope property (normally to initiate a transfer).
12) The GWR only holds clean unmodified copies of all current GNU.hopes 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 GNU.hope 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 least GNU.hopes would create a dynamic "Who's Who" of unprecedented scope.
14) Obviously we need not call a GNU.hope a "GNU.hope". Indeed, if this term is not readily embraced/welcomed by the GNU powers that be, then that potential name is readily retracted. I've also considered calling it an "OR" (abbreviation for "on record") or an Olga (por mi suegra) or perhaps a Sinf (Sinf is not fiat). For me, "GNU.hope" has a great ring to it, but there maybe strategic reasons for avoiding its use (for instance people may get the wrong impression that it is primarily intended to be used within the GNU community or it may be construed as 'politically' charged/tainted).
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). I've got a copy of my latest resume for you *here* plus my brief Logic Elegance page. I take photos and want to develop programs promoting talented Central Americans along with established & emerging artist. 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 truly quite amazing if you'd like to hear it sometime.)
You can see what the newspaper said *here* (see articles 2-5, 6, 7, 8-10, 11-14 of 31)
2) If the system you are promoting is based so much on maximized openness and public visibility, then why did you encrypt this?
Two part answer:
a) The cloak provided by my Zack Clark pen name is admittedly damn thin and it would be awful easy for undesirable contact to still get through. Nevertheless, I wanted to give you the expanded details as done above and still not overly expose myself just yet.
b) More importantly, the GNU.hope represents a potential that far exceeds its initial intent (providing an effective arena to present meaningful moral support to deserving recipients). However, I believe it may be well advised not to elaborate on the GNU.hope's full potential ab initio. The 'compliment business' is not going to threaten anyone nor invite menacing attack. It consequently makes for an ideal environment in which to develop and perfect a full functioning system before opening everything up to destiny.
3) To whom have you explained this idea/plan? -- Just you.
4) Why me?
Well, I do have almost 900 public keys & email addresses of GNU related persons. So the option of launching a modest email campaign to advance this idea does exist. However, after due consideration I believe that you're my best bet. I'm familiar with your written, audio, and video material. And I feel that the odds of you relating to my quest are better than any other personality I've considered.
5) What do you want from me?
Glad you asked! ;) So here is my wish list:
a) It really would mean a lot to me if you'd kindly sign my {GNU.hope} gesture bearing UID 85E756C6-061200.135EA668 that I'm presenting to you via attachment. You should first verify integrity of the gesture against my public key. After you digitally sign my gesture it is then an iCandidate ready for submission to a registry-node. For the moment only one registry-node exists and submissions are made via email to GNUhope@world1tours.com. After the submitted iCandidate is received, the gesture part (what I as originator wrote) will be double checked for integrity and then the entire iCandidate package is tested against your public key. If both our signatures verify then the iCandidate is stored in the GWR database and you are sent an email verifying the existence of the world's first GNU.hope. For now the GWR will be humbly available to the whole world at http://world1tours.com/garage/GNU.hope. (If you'd like to provide an alternate first depository, I'd most likely be in total agreement.)
b) Your questions & comments are dearly sought.
c) And if interested, then your saburia should be ideal for coming up with the right strategy to introduce this idea.
d) I admire your uncanny talent to clearly elucidate important points key to your positions. And this is exactly what is needed to best advance the GNU.hope to its rightful status (of acceptance).
e) You should also be excellent for soliciting the talent necessary to pull the whole thing off in first class style.
f) I'm anxious to do a blog on GNU.hopes using WordPress; but it will be my first. So I want to learn all the ins and outs of good blogging to assure it's done right. My only concern is delaying the blog while I'm getting up to speed on the technology. So if you know a good (hopefully) interested person to assist on this, that could help out nicely.
g) Finally, I have never mentioned the one key word (English verb) that truly encapsulates the full significance of this proposal. If you could tell me what this magic word is then I'd be elated beyond anything you might imagine!
6) What do you personally want?
I want the opportunity to work on this full time plus and see it through to fruition.
7) Are all the terms you tediously define really necessary?
Maybe not, as I certainly do not want to complicate things with unnecessary verbiage. (Most terms, incidentally, were formulated while writing this.) 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. The most notable terms are gesture, iCandidate, and GNU.hope 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, it is not needed.
b) The database requirements are not too fancy, but should be designed to handle potentially billions of GNU.hopes. 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 GNU.hope to all.
10) If you're talking about trading GNU.hopes, 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 could even emerge that function on top of the GNU.hope 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 GNU.hope in terms of how other humans perceive said GNU.hope. Nevertheless rejections are technically neutral and have no effect on how GNU.hopes are handled within the system. This alternative is needed for the advantages inherent in balanced options.
12) Sounds like you might be inviting flaming, etc.
Flaming should not be a significant issue (despite the rejection option). The formality of the GNU.hope process should cause people to be careful and considered in their usage (as a GNU.hope 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) What would you have me do with this document?
To be blunt - whatever you think is best. After all, my gesture (UID: 85E756C6-061200.135EA668) specifies that when your signed iCandidate is registered and thus becomes the first GNU.hope; then in addition to your ownership of said GNU.hope, the file (showMe.gpg) also becomes your property. However, I would personally suggest that you keep the un-encrypted document in its entirety under wraps. Independent of the ideas and propositions this contains (which should be actively disseminated), the document currently has NO value on its own (no soy famoso). However, should this hope get off the ground then showMe.gpg could gain interest and notoriety (i.e. value) proportional to the system's success. You'll also probably note that my gesture is admittedly written in a manner to somewhat enhance intrigue.
14) Doesn't all this smack of 'IP' sorts of things and the type of evil ownership many of us are fighting??
Excellent question - if I do say so myself! Actually, I'm confident that you (RMS) 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 your 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 GNU.hope 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 - who's popularity will categorically undermine traditional propriety propensities.
b) Clearly the ownership of a GNU.hope hardly serves to place its digital content out of reach of others. In fact the entire system is intended to maximize dissemination and accessibility. In the GNU.hope domain, individual OWNERSHIP is validated, assured and enhanced by increased public possession! Isn't that the opposite strategy perpetuated by the propriety camp? Admittedly, GNU.hope ownership does not enjoy the rights of ownership based on the same (scarcity) principles of the plate of spaghetti you made. 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 GNU.hopes. But if a GNU.hope could represent most anything then why in the world wouldn't you start-off with a fixation on something more practical than '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 GNU.hope.
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 individual 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 GNU.hopes 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 GNU.hopes 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.
Definitions:
accept/reject: This is an attribute of the GNU.hope which merely reflects the basic propensity of the recipient toward said GNU.hope. If not eexplicitly found within the {GNU.hope} 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 GNU.hope. 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 {GNU.hope} 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 GNU.hope 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. Gestures becomes GNU.hopes after signing by recipient and entry into the GWR database by a registry-node.
GNU.hope: [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 GNU.hope's file name is also it's UID (universal ID). [adjective] Identified by, part of, or related to this system.
GWR: This acronym stands for GNU World Record (database). The very existence of a GNU.hope 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 {GNU.hope} comment as assigned by the originator, and likely the date presented to recipient.
originator: a PGP keyID identified entity (person) who creates/originates a formal {GNU.hope} open text gesture containing a comment for a recipient.
recipient: the PGP keyID identified entity (person) who is the object of a {GNU.hope} gesture.
redemption status: This is a basic category of state for any GNU.hope 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 GNU.hope if possible.
"Yes" indicates that the GNU.hope currently contains a redemption privilege and is thus basically a coupon.
registry-node: This is where a {GNU.hope} 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 GNU.hope last changed ownership.
UID: This is the universal ID and file name for a GNU.hope. 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). "#" runs the range of 0-9,A-Z,a-z and so allows for any given originator to create up to 62 unique gestures 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 can be any character most convenient for the user. Hence 85E756C6-061200.135EA668 is equivalent to 85E756C6@061200.135EA668 and indicates the exact same GNU.hope. Hence this delimiter can signify anything desired within a personal collection of GNU.hope 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.
z.c.
