Doc archive


Discussion of X-trade specification, branch a

The purpose of this page is to aid the discussion of the specification for the URN X-trade, branch a. Use the space below to leave suggestions, criticism, questions, etc.. You may want to make us aware of your additions by raising your voice in a TagTrade discussion group or in the TagTrade irc channel.

Related technology

Some specifications concerning unique URNs/tags/identifiers constructed using email, date/time, etc.:


Ideas for types of identification parameters (see the specification for more parameters):

  • . . .

Ideas for types of description parameters (see the specification for more parameters and explanation of place holders):

  • $type_of_doc="paym":
    • Certificates that the implementor must have. Without these certificates, he won't get payment.
    • Required age of the implementor. Can be used to direct simple tasks at young people.
    • Required area of the implementor. Can be used to direct tasks to people in poor countries.
    • Indicate that part of the payment is not going to the provider of the solution, but is being donated to a certain cause.

Ideas for types of tasks that people may submit (this is probably of more general interest and should be moved to a different page):

  • Implementation task. Request someone to implement e.g. a software extension.
  • Specification task. Request someone to help work out a specification for the actual task. This type of task could be interesting to people who have only basic understanding in a certain area.
  • Search task. Request someone to find information concerning a certain issue. This could be interesting to have done in advance to writing a specification.

Accomplishement of goals

Accomplishment of the goal set a.0.1:

  • Simplicity: Participants have the freedom to continue using their favorite communication platforms when trading. Such communication platforms are, for example, mailing lists, news groups and web based bug databases. This does not mean, however, that the system is simple to use. Creating and interpreting tags is not easy, especially for participants not very adept in computing. That's an area, though, where supplementary services are be of great help. In a nutshell: Because no special infrastructure is needed and because ease of use can be achieved by supplementary services, the system does achieve the goal simplicity quite well.
  • Quickness: As for simplicity, the fact that communication platforms can be freely selected by users is a virtue. For example in the area of software development there are already multitudes of well established fora (e,g. bug databases, mailing lists) where users meet developers. If a user posts an inquiry in such a forum, he can be sure that a developer will at least have a look at it. Also, tasks can for example be made available in easily browsable tag databases, offered as supplementary services. So, quickness also seems to be achieved quite well by the system.
  • Good pay: An important ingredient of the system is that payment can be accumulated: Different participants can pledge money for the same task. This makes it possible for developers to earn good pay, even for small tasks.
  • Trust: Rating tags make it possible to build trust among participants. For example, someone having requested a feature may rate the quality of a developer's patch. The developer, in turn, may rate the payment morale of those who pledged money for the implementation of the feature. Additional trust can be build in by PGP signing URNs and the documents that they identify. Trust databases, offered as supplementary services, would make it easy for participants to to choose trade partners. By specifying corresponding trade URN parameters, for examle, it could be made possible for someone plediging money to state: "I won't pay X" (because of bad reputation). Or that one may state: "I will only pay developers with certificate Y". As the system grows, the trust network also grows.
  • Independence: As no particular infrastructure is necessary to use the system, it cannot be owned by anyone. The specification of the URN trade is planned to be an open Internet standard. Furthermore, the parameters that are part of the URN may not even be part of the specification, thus allowing participants to introduce their own. All supplementary services that help make the system easier to use are optional. If one of these services ceases to exist, then the majority of the meta data encoded in the URNs won't get lost: Most of it will most likely be retrievable from archives e.g. of mailing lists or news groups. So, independence seems to be achieved well.

Proposals for version a.0.2

  • Remove expiry date from task URNs. Rationale: The expiry date makes it impossible for people to extend their support beyond the expiry date, and in this case a new task has to be created. For example, while the person who wrote the specification may really have lost interest in the task when it expires, someone else may want to support it longer.
  • Add expiry date to payment URNs. Rationale: People may disagree with the person who specified the task on how long they want to support it.
  • Allow task providers to version specifications. Supporters (i.e. the people who pledge money) should be given the possiblity to specify whether they automatically support higher versions.
  • Add tags allowing people to specify that two tasks are reasonably similar.
Unless noted otherwise, this page is licensed under the Creative Commons Attribution 2.5 License.
Last modification on 2006-Oct-22 at 11:03. Author: feklee