Hi. I am the main (and so far the only) developer of "Circular Multilateral Barter"
project - see https://sourceforge.net/projects/cmb/ . I worked quite hard during the
last 1-2 years, and now project is in late beta stage, so is pretty much ready for use.
I guess there are many common things between my project and yours, so lets
talk and collaborate. My e-mail is epandurski@gmail.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you did a great job with the cmb project! Keep it up!
I welcome your interest in collaboration! We should really do that. First, we have to find out if we are talking about the same thing:
The most striking difference betweem cmb and t4c is that cmb seems to be based on barter whereas t4c is not.
The idea behind t4c is based on prior work on the subject , where it is maintained that barter intrinsically entails the money form. I believe that this is actually true, hence I think that barter can never lead society ahead, transcending capital, rather, it leads backwards. I'm interested in proving exactly the negation of barter: that exchange of equivalents is not a neccessary condition of division of labour.
Second, I think that cmb and t4c differ in scope - although I am not sure about this - please correct me if I am wrong. t4c is designed to be an architectural layer, or maybe you want to call it a protocol. It is not a single website or a piece of software that may power any number of websites, but a piece of software that may power any number of websites which are automatically interconnected and interoperable. I can imagine, for example, that cmb could be based on t4c. This would allow any number of hosts running cmb to be interoperable much in the same way as different web sites are now interoperable in terms of linking to each other.
There are many more points to discuss, and I'd really like to do that. However, I should like to know which way you're heading with cmb: Who will install the server software and why? What socio-political impact do you hope for (if any)? Why do you think that barter is the answer to crisis (situations when cash-flow is tight, as you put it on the cmb site)? Are you still interested after reading this?
Best,
Featha
Karl Marx, "Capital". Volume one, Vintage Books Edition, Aug 1977, p126-163.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The website I did is an early implementation of a more general idea - https://sourceforge.net/projects/cmb/files/cmb-design/cmb-dd.pdf/download
The current implementation is far from perfect because it centralizes
all user's data and processing. I decided to do it this way, because
it is *much* easier to implement. Once the idea is proved, a software
platform must be written that shall drive many different
implementations. But it is not wise to write a full-grown software
platform for an experimental idea.
I should probably explain if and why I believe "barter is the answer
to crisis". Before getting into details, let me make clear that to me
*circular barter* is very different from the ordinary barter. I
explain this in my paper, but in short - I hope CMB will be *much*
more powerful than the ordinary barter. Anyway, here are my thoughts:
If we have division of labor, we must have redistribution of goods.
What kinds of redistribution are there? I divide them in 2 categories:
1) Spontaneous redistribution. Examples: gift, charity, theft, barter
(and most forms of exchange of equivalents), markets. The common
thing is that no elaborate political process in involved in these
processes.
2) Political redistribution. Examples: taxes, funds raising
foundations, subsidies, bailouts etc. The common thing is that a
political process in involved in these processes.
Money can service both kinds of redistribution, but money is
inherently a political contract. Because money in rooted in policy,
it can not serve the the spontaneous redistribution well enough,
unless a *very special kind* of financial (this is political) redistribution takes
place at the same time and place. The goal of CMB is to provide an
efficient method of spontaneous redistribution which does not depend
on any form of political redistribution.
I would say that CMB is hoped to be the right (the spontaneous) side
of the crisis-equation. The left side of the crisis-equation is
probably where t4c is focused, I guess.
I hope you haven't got the impression that I am a some kind of free
market evangelist. My believe is that we always need both kinds of
redistribution. Always! If we get off-balance, bad things happen. In
my view, current crisis will put the political redistribution (a
non-financial one!) to its limits, while leaving no space for
spontaneous one. To me, this is a recipe for disaster. The ultimate
goal of CMB-project is to provide the technological means to
re-balance the equation.
Are you still interested after reading this? :-)
Regards,
Evgeni Pandurski
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
t4c is a system of agents that represent people or institutions.
Such an agent is responsible of
- publishing requests and offers
- negotiating with other agents when fitting request/offer pairs have been identified. This negotiation may involve the agent contacting its owner and it either ends with a successful transaction, or the transaction is cancelled.
Offers and requests are defined in a machine-readable language (RDF) according to the principles of linked data. This makes it (at least theoretically) possible to find offers matching a given request automatically. Agents communicate through RESTful webservices.
Matchmaking services can crawl requests and offers, calculate how well they fit, and inform the requesting representative agents of matching offers.
As all communication is web-based, all data is public and negotiation follows a fixed protocol, agents can be hosted on different web servers. For the same reason, matchmaking services can operate from different machines as well.
This set of features is what I'm working on at the moment. Later (If I ever get there) I'm planning to implement synchronized transactions - multiple transactions that depend on a common condition.
This would probably make it possible to require circular exchange when offering something, i.e defining that you would give X away only if you got something that you are actually requesting in return from a different agent/person.
Anyway, given the fact that cmb is in late beta stage, is this type of collaboration (building cmb on top of t4c) something you would consider? Are there other ways of collaboration?
best
F
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. From what you describe, your project is quite general, and if I
understand it correctly, it is quite big and important. I will be
interested in implementing CMB 2.0 over t4c if:
* There is some real-world interest in CMB 1.0
* t4c is a stable platform, which maches the needs of CMB.
So, yes, but probably not in the near future. Nevertheless, for me
t4c is interesting on its own, so I might help you in your work. Here
are some things that I could do (there are probably more):
* I can review your design and try to find weak spots. I can also
give ideas how to improve the design, so that it become suited to
additional applications' needs. I consider myself good at that kind
of work.
* I can write some testing/demo applications using the platform and
thus find bugs and places that are not designed well.
* I can review your code and spot bugs.
* I can give general ideas and suggestions.
It seems to me that your project is quite ambitions. This isn't bad,
but in my view, it somehow changes the way it have to be approached.
I personally managed to write the first line of code that managed to
survive, several years after I started working on CMB (and I consider
CMB a much simpler project than yours). I simply did not know what I
want to do until I did it! Chances are that you are facing the same
problem unless you've worked on t4c for several years by now. For me,
the turning point was when I managed to write a good enough
documentation (the paper you probable have read). I guess, writing
some documentation will be of great help to you too. For example, I
see several layers, that should probably be identified and documented
as early as possible:
1) Physical layer. This is probably http + XML. But you may consider
make an abstract physical layer, so that you can change you mind later.
This will probably improve the code quality. Are there any cryptography
planned?
2) Trader IDs and Agent IDs. Do you generate them or you use some
existing or emerging ID-infrastructures (like OpenID)? This is
probably a very important question. I can imagine that you may borrow
some solutions from existing projects, one that comes to my mind is
"Diaspora".
3) Digital signatures. I suppose the final outcome of all the
messages being passed through the system will be to get some documents
digitally signed. What cryptography will be used? RSA? Eliptic?
Abstract layer? These are all tough questions.
4) What language will be used to describe the behavior of the agents?
XML-derived one? XML looks great until you actually have to write
something in it :-) Or you plan to create a brand new language? Or
you may just provide the API and say: "You mat use every language you
want as long as it is java". Well, this is not as bad at it sounds
:-)
These are some of the questions that comes to my mind, but there will
be much more.
Regards,
Evgeni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right, there is almost no documentation, and I don't know how anyone would go about to understand what the heck t4c is about. Thanks for your questions and suggestions!
As for your proposals of contribution: I'd love that!
If you are familiar with java and maven, just check out the trunk and build the main project (if not, and if you're interested, I can explain). In netbeans 6.9.1, I was able to do that in a matter of minutes. The best way to get to know the sources is by looking at the unit tests in the t4c-rep-server module. Please note, however, that the application is not very friendly to anyone but me at the moment ;) (Much in contrast to CMB, I must say ;)
As for your questions 1 and 4:
The whole idea of t4c is massively influenced by the concept of linked data. Recent developments (or maybe not-so recent ones, meanwhile), like the emergence of dbpedia, freebase, linkedgeodata, and other projects improve the ability of computer programs automatically to coordinate. The main reason for this is that objects of the real world and general concepts are getting globally unique IDs. This enables us to write software that can decide eg. if an offer and a request for something relate to the same general idea, compatible points in time and space, and so on. The language for this kind of information is RDF (which may be expressed in xml, n-triples, n3, turtle, and probably more formats I'm forgetting just now).
Together with what I said in an earlier post, this defines the technological basis of t4c as HTTP + RDF. What is currently being developed is a protocol that defines the structure of messages and agent interaction. In the process of doing that, a reference implementation is being created in Java. It is actually one of my goals that t4c be agnostic of programming language and operating system.
ad 2+3:
In general, I think that t4c should be made secure by making it impossible that subverting it yield an advantage. At the moment, the application allows anyone to create any number of agents just by sending the right http request to a t4c server, and to publish any number of requests and offers through that agent. This approach appeals to me for its simplicity. I'm planning on requiring a user's public rsa key (or something similar) when an agent is created, so that subsequent messages can be digitally signed by the user and verified by the agent.
As for cryptography… For the sake of traceability and ease of planning, I thought it may be a good thing if all offers/requests as well as communication were in clear text. This is in stark contrast with the nature of contemporary society, however, so I'm really not so sure about this.
other points:
I'm planning to develop the main t4c server component without a user interface. It should be enough to have a RESTful webservice with which different client applications like a web site, an android/iphone/… app, a browser plugin, etc. can interact. One of the most important and hard parts, however, should be a good user interface that allows for the definition of requests/offers in RDF without acually having to write RDF - The data editing functionality of freebase leads the way here (get a user account and try to edit some data on freebase - it's awesome!)
best,
F
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, from what you explained, it is not clear what *exactly* t4c is about. You
are referring to very general ideas, so I do not understand what distinguishes
t4c from other RDF/ontology/smart-bots/voodoo-magic projects ;-)
Evgeni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's hard to say what t4c is *exactly* about as it is in an early stage. The goal is to develop the tools that people in a free society would need in order to satisfy their self-interest through cooperation. I don't know of any other project with comparable goals, so it's hard to make a technical distinction.
I may add that I am cought pants down by this whole discussion - I wasn't hoping for feedback before the first end-user ready prototype got out. Some things are not thought through; others are not yet demonstrable. Maybe you should just wait to see. If you are really interested, ask more specific questions;)
best
F
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. I am the main (and so far the only) developer of "Circular Multilateral Barter"
project - see https://sourceforge.net/projects/cmb/ . I worked quite hard during the
last 1-2 years, and now project is in late beta stage, so is pretty much ready for use.
I guess there are many common things between my project and yours, so lets
talk and collaborate. My e-mail is epandurski@gmail.com
Hi epandurski!
I think you did a great job with the cmb project! Keep it up!
I welcome your interest in collaboration! We should really do that. First, we have to find out if we are talking about the same thing:
The most striking difference betweem cmb and t4c is that cmb seems to be based on barter whereas t4c is not.
The idea behind t4c is based on prior work on the subject , where it is maintained that barter intrinsically entails the money form. I believe that this is actually true, hence I think that barter can never lead society ahead, transcending capital, rather, it leads backwards. I'm interested in proving exactly the negation of barter: that exchange of equivalents is not a neccessary condition of division of labour.
Second, I think that cmb and t4c differ in scope - although I am not sure about this - please correct me if I am wrong. t4c is designed to be an architectural layer, or maybe you want to call it a protocol. It is not a single website or a piece of software that may power any number of websites, but a piece of software that may power any number of websites which are automatically interconnected and interoperable. I can imagine, for example, that cmb could be based on t4c. This would allow any number of hosts running cmb to be interoperable much in the same way as different web sites are now interoperable in terms of linking to each other.
There are many more points to discuss, and I'd really like to do that. However, I should like to know which way you're heading with cmb: Who will install the server software and why? What socio-political impact do you hope for (if any)? Why do you think that barter is the answer to crisis (situations when cash-flow is tight, as you put it on the cmb site)? Are you still interested after reading this?
Best,
Featha
Karl Marx, "Capital". Volume one, Vintage Books Edition, Aug 1977, p126-163.
Hi.
The website I did is an early implementation of a more general idea -
https://sourceforge.net/projects/cmb/files/cmb-design/cmb-dd.pdf/download
The current implementation is far from perfect because it centralizes
all user's data and processing. I decided to do it this way, because
it is *much* easier to implement. Once the idea is proved, a software
platform must be written that shall drive many different
implementations. But it is not wise to write a full-grown software
platform for an experimental idea.
I should probably explain if and why I believe "barter is the answer
to crisis". Before getting into details, let me make clear that to me
*circular barter* is very different from the ordinary barter. I
explain this in my paper, but in short - I hope CMB will be *much*
more powerful than the ordinary barter. Anyway, here are my thoughts:
If we have division of labor, we must have redistribution of goods.
What kinds of redistribution are there? I divide them in 2 categories:
1) Spontaneous redistribution. Examples: gift, charity, theft, barter
(and most forms of exchange of equivalents), markets. The common
thing is that no elaborate political process in involved in these
processes.
2) Political redistribution. Examples: taxes, funds raising
foundations, subsidies, bailouts etc. The common thing is that a
political process in involved in these processes.
Money can service both kinds of redistribution, but money is
inherently a political contract. Because money in rooted in policy,
it can not serve the the spontaneous redistribution well enough,
unless a *very special kind* of financial (this is political) redistribution takes
place at the same time and place. The goal of CMB is to provide an
efficient method of spontaneous redistribution which does not depend
on any form of political redistribution.
I would say that CMB is hoped to be the right (the spontaneous) side
of the crisis-equation. The left side of the crisis-equation is
probably where t4c is focused, I guess.
I hope you haven't got the impression that I am a some kind of free
market evangelist. My believe is that we always need both kinds of
redistribution. Always! If we get off-balance, bad things happen. In
my view, current crisis will put the political redistribution (a
non-financial one!) to its limits, while leaving no space for
spontaneous one. To me, this is a recipe for disaster. The ultimate
goal of CMB-project is to provide the technological means to
re-balance the equation.
Are you still interested after reading this? :-)
Regards,
Evgeni Pandurski
I would like to learn more about what t4c is about.
t4c is a system of agents that represent people or institutions.
Such an agent is responsible of
- publishing requests and offers
- negotiating with other agents when fitting request/offer pairs have been identified. This negotiation may involve the agent contacting its owner and it either ends with a successful transaction, or the transaction is cancelled.
Offers and requests are defined in a machine-readable language (RDF) according to the principles of linked data. This makes it (at least theoretically) possible to find offers matching a given request automatically. Agents communicate through RESTful webservices.
Matchmaking services can crawl requests and offers, calculate how well they fit, and inform the requesting representative agents of matching offers.
As all communication is web-based, all data is public and negotiation follows a fixed protocol, agents can be hosted on different web servers. For the same reason, matchmaking services can operate from different machines as well.
This set of features is what I'm working on at the moment. Later (If I ever get there) I'm planning to implement synchronized transactions - multiple transactions that depend on a common condition.
This would probably make it possible to require circular exchange when offering something, i.e defining that you would give X away only if you got something that you are actually requesting in return from a different agent/person.
Anyway, given the fact that cmb is in late beta stage, is this type of collaboration (building cmb on top of t4c) something you would consider? Are there other ways of collaboration?
best
F
Hi. From what you describe, your project is quite general, and if I
understand it correctly, it is quite big and important. I will be
interested in implementing CMB 2.0 over t4c if:
* There is some real-world interest in CMB 1.0
* t4c is a stable platform, which maches the needs of CMB.
So, yes, but probably not in the near future. Nevertheless, for me
t4c is interesting on its own, so I might help you in your work. Here
are some things that I could do (there are probably more):
* I can review your design and try to find weak spots. I can also
give ideas how to improve the design, so that it become suited to
additional applications' needs. I consider myself good at that kind
of work.
* I can write some testing/demo applications using the platform and
thus find bugs and places that are not designed well.
* I can review your code and spot bugs.
* I can give general ideas and suggestions.
It seems to me that your project is quite ambitions. This isn't bad,
but in my view, it somehow changes the way it have to be approached.
I personally managed to write the first line of code that managed to
survive, several years after I started working on CMB (and I consider
CMB a much simpler project than yours). I simply did not know what I
want to do until I did it! Chances are that you are facing the same
problem unless you've worked on t4c for several years by now. For me,
the turning point was when I managed to write a good enough
documentation (the paper you probable have read). I guess, writing
some documentation will be of great help to you too. For example, I
see several layers, that should probably be identified and documented
as early as possible:
1) Physical layer. This is probably http + XML. But you may consider
make an abstract physical layer, so that you can change you mind later.
This will probably improve the code quality. Are there any cryptography
planned?
2) Trader IDs and Agent IDs. Do you generate them or you use some
existing or emerging ID-infrastructures (like OpenID)? This is
probably a very important question. I can imagine that you may borrow
some solutions from existing projects, one that comes to my mind is
"Diaspora".
3) Digital signatures. I suppose the final outcome of all the
messages being passed through the system will be to get some documents
digitally signed. What cryptography will be used? RSA? Eliptic?
Abstract layer? These are all tough questions.
4) What language will be used to describe the behavior of the agents?
XML-derived one? XML looks great until you actually have to write
something in it :-) Or you plan to create a brand new language? Or
you may just provide the API and say: "You mat use every language you
want as long as it is java". Well, this is not as bad at it sounds
:-)
These are some of the questions that comes to my mind, but there will
be much more.
Regards,
Evgeni
Hi Evgeni,
You're right, there is almost no documentation, and I don't know how anyone would go about to understand what the heck t4c is about. Thanks for your questions and suggestions!
As for your proposals of contribution: I'd love that!
If you are familiar with java and maven, just check out the trunk and build the main project (if not, and if you're interested, I can explain). In netbeans 6.9.1, I was able to do that in a matter of minutes. The best way to get to know the sources is by looking at the unit tests in the t4c-rep-server module. Please note, however, that the application is not very friendly to anyone but me at the moment ;) (Much in contrast to CMB, I must say ;)
As for your questions 1 and 4:
The whole idea of t4c is massively influenced by the concept of linked data. Recent developments (or maybe not-so recent ones, meanwhile), like the emergence of dbpedia, freebase, linkedgeodata, and other projects improve the ability of computer programs automatically to coordinate. The main reason for this is that objects of the real world and general concepts are getting globally unique IDs. This enables us to write software that can decide eg. if an offer and a request for something relate to the same general idea, compatible points in time and space, and so on. The language for this kind of information is RDF (which may be expressed in xml, n-triples, n3, turtle, and probably more formats I'm forgetting just now).
Together with what I said in an earlier post, this defines the technological basis of t4c as HTTP + RDF. What is currently being developed is a protocol that defines the structure of messages and agent interaction. In the process of doing that, a reference implementation is being created in Java. It is actually one of my goals that t4c be agnostic of programming language and operating system.
ad 2+3:
In general, I think that t4c should be made secure by making it impossible that subverting it yield an advantage. At the moment, the application allows anyone to create any number of agents just by sending the right http request to a t4c server, and to publish any number of requests and offers through that agent. This approach appeals to me for its simplicity. I'm planning on requiring a user's public rsa key (or something similar) when an agent is created, so that subsequent messages can be digitally signed by the user and verified by the agent.
As for cryptography… For the sake of traceability and ease of planning, I thought it may be a good thing if all offers/requests as well as communication were in clear text. This is in stark contrast with the nature of contemporary society, however, so I'm really not so sure about this.
other points:
I'm planning to develop the main t4c server component without a user interface. It should be enough to have a RESTful webservice with which different client applications like a web site, an android/iphone/… app, a browser plugin, etc. can interact. One of the most important and hard parts, however, should be a good user interface that allows for the definition of requests/offers in RDF without acually having to write RDF - The data editing functionality of freebase leads the way here (get a user account and try to edit some data on freebase - it's awesome!)
best,
F
Well, from what you explained, it is not clear what *exactly* t4c is about. You
are referring to very general ideas, so I do not understand what distinguishes
t4c from other RDF/ontology/smart-bots/voodoo-magic projects ;-)
Evgeni
HI Evgeni,
It's hard to say what t4c is *exactly* about as it is in an early stage. The goal is to develop the tools that people in a free society would need in order to satisfy their self-interest through cooperation. I don't know of any other project with comparable goals, so it's hard to make a technical distinction.
I may add that I am cought pants down by this whole discussion - I wasn't hoping for feedback before the first end-user ready prototype got out. Some things are not thought through; others are not yet demonstrable. Maybe you should just wait to see. If you are really interested, ask more specific questions;)
best
F
OK, I will just wait to see. Good things need time :-)