Three years ago, when our team at Kassi began sketching our idea of an online service for sharing goods and skills, we were not aware that others were doing the same thing. Since then, we have found that the idea is definitely not new. This catalogue alone lists more than a hundred services that allow people to lend, borrow, swap and recycle goods, and it probably includes only a fraction of them all.
How could collaborative consumption services collaborate?
While it is great that there are so many people working to promote sharing, this also causes problems from the users' point of view. When there is more than ten sharing services working in the same city, it becomes tedious to find the stuff you're looking for or list what you have. As a result, it's difficult for a single service to achieve the network effect. A traditional capitalist approach would be to rely on the survival of the fittest. But could there be a more collaborative way? After all, our common goal is to boost sharing by mapping all the resources that people have to share and linking them together. Would it be possible to form a huge pool of resources that all sharing economy services could then use to their benefit?
I'm going to look things from a practical (read: technological) point of view here and suggest two collaboration approaches that could solve these issues: a common API and a distributed data storage.
Approach 1: Common API
A common API would be a rather simple solution since it does not force current services into major changes in their infrastructure. Basically it would mean that each sharing service would build an API according to the same specification. The method would be somewhat similar to Google's Open Social initiative for social websites. We would have to define an ontology that maps all the resources that can be shared (stuff, skills, space) and their subtypes and properties related to them. For example, in the case of goods, the specification could require the API to provide some basic information of each item, such as name, picture, location, category (books, tools, etc) and how they will be shared (lending, swapping, giving away, etc). This would mean that when I wanted to show all tools that people can lend near San Francisco area I could use the same query to retrieve results from all the different services.
The benefit of this approach is that it would be easy to display results from different services when a user does a search in one service, because there would be no need to build a separate integration mechanism for each service. For example, if you were searching for a certain tool from NeighborGoods and did not find it, the search would then return results from Share Some Sugar and Freecycle. And since most modern online services plan on building an API at some point, using an existing specification could save time and resources.
Using this kind of API connection would benefit all parties. Those who displayed results from other services in their search would be able to offer a better service to their users. It's a good customer service and marketing practice to point to your competitors if they can serve your customer better. Those offering their APIs for others to use would get exposure and traffic when other services pointed to them, and the people would get a wider selection of available resources and would be introduced to new sharing services.
This approach is not perfect. When actually borrowing the item, the users would still need to sign up for those services. They would not be able to take their data from the original service with them. This data would include feedback received from other users and other information that is vital to facilitate sharing. A person with an excellent reputation as a frequent lender and a trustworthy borrower in NeighborGoods would become a suspicious newbie in Share Some Sugar.
How could this issue be addressed? It's not easy, but it could be done, at least in theory, using a technique called distributed data storage.
Approach 2: Distributed data storage
Diaspora is a project familiar to many due to its huge Kickstarter success. Diaspora's main idea is to create a social networking site like Facebook but with a significant difference: people own all their data and can move it as they please, and only display it to people they choose. It uses peer to peer technology to distribute data between servers (or "pods") set up by the users of the service. This means that it has no central place where all the data is stored.
Applied to collaborative consumption, this would mean that some core data--like users' profile information, things they are sharing and their reputation in different services--would be an identity that could be shared between different services. Each time a user came across a new service he could conduct a "collcons connect" (similar to Facebook Connect) which would transfer the data he selects to transfer to the new service. A publish/subscribe method could be used to ensure when some data is changed in one service, the change gets transferred to all the other services using that same data.
This approach would make it easy for people to discover new services and start using them, and therefore start sharing with even more people. It would also create a huge catalogue of shared resources which new entrepreneurs could then use in innovative ways.
Challenges
The main challenges in this kind of collaboration between services are not technological. All the things mentioned above could be done. The actual reasons that are preventing collaboration between services are very similar to those that are preventing sharing between people in collaborative consumption services: convenience and trust.
Startups have limited resources and want to be agile. The collaboration cannot take too much time away from their core business of developing a good service for their users or slow them down. Moreover, most startups have their own strong vision and want to test it first before considering collaborating with others. We all think that we should eventually collaborate, but no one is ready to take the step beyond talking.
Then there are the trust considerations. If I'm going to pull data from somebody else's service, I need to be able to rely on the quality of the data. And if I let them take my data, I need to trust them to handle it responsibly. For the biggest players, it might seem that smaller services areusing their content and not giving enough back. The small services might think their users have no reason to return to them if their data is available on the bigger hubs. And naturally, owning data can be also viewed as a competitive advantage, which is why walled gardens are so prevalent on the web.
There is no single one-size-fits-all solution for all collaborative consumption services. But there is certainly room for more cooperation than what currently exists. With this post I hope to get the discussion going. Should collaborative consumption services collaborate more? Are the suggestions provided in this post viable? What else could be done? How do we get this thing started? Share your thoughts!
Comments
Juho Makkonen wrote on 04.08.11, 12:18am:
It is true that the field is very new, but on the other hand it might also make it easier for services to adopt common patterns and make changes. But yeah, probably a few services should try to implement something like that at first to see how things actually work.
An open classified ads API would be a good start, many collcons services could probably benefit from it. It's a shame that Craigslist doesn't have an API http://www.quora.com/Why-hasnt-anyone-built-any-products-on-top-of-Craig...
The transaction API you are working on sounds very interesting! Where can I find more information about it? We've also been pondering on whether we should add an option to use complementary currencies in Kassi.
--
Juho is a Co-Founder and CEO of Sharetribe, a platform for creating custom peer-to-peer marketplaces. http://www.sharetribe.com
Matthew Slater wrote on 04.08.11, 1:18am:
Regarding the mutual credit transaction API. First of all I'm working on a Drupal module called mutual_credit for accounting within a community. This is working in Drupal 6 and I'm upgrading to 7. The first version of 'intertrading' is being built by CES, but they're not in the habit of blogging. I'll write about it on my blog when it's done.
Intertrading for Drupal 7 is a while off, although I just learned that LETSlink UK is also working on an API. Again, watch my blog for the latest in all these matters.
Dan wrote on 04.09.11, 5:44pm:
Hi, I think its a fantastic idea, and you've touched on the critical problems of trusting the other service, and moving data between services.
Along these lines I have wondered if there should be a Diaspora module to manage a user's resources (items and skills). The advantage of that, is that as with Diaspora, the user owns and manages their data and is not locked in by third-party providers who have gained legal ownership of their data.
One of the biggest problems for a decentralised sharing network (as opposed to a network of large sharing websites such as ecomodo, sharesomesugar, etc), is as you touch on, how do you trust the reputation of the other node that you are connecting to?
The only way through that I can see at the moment is having a few central reputation and trust servers. In that design, users would manage their resources and interactions, but the outcome of the interactions (reputation) would additionally be published on a central server. Sort of breaks the decentralised model though...
Would it be useful to create a community of practice or loose association for people operating and building p2p sharing sites who are seeking greater collaboration, interoperability, and communication within this space? To slowly start edging towards the vision that you are painting..
Note & disclaimer: If all goes to plan, its something I'd like to move my sharing site (http://sharedearth.net) in the direction of - i.e. decentralised sharing network potentially leveraging diaspora's technology.
David Gleason wrote on 04.10.11, 2:03am:
I'd say complexity is the biggest barrier to a decentralized model. Until it's as easy for users as facebook, it won't get far. Diaspora does not look good in this regard. Nor do the numerous protocols and formats involved in organizing and sharing the data.
A possible approach:
1. Design a local app that users run which allows them to organize data, i.e. files, personal info, stories, pics, links, contacts, friends, messages, etc. on their own computer (or iphone or whatever), in a true object-oriented (and standardized) way, and to define relations for those data objects and aspects, i.e. dependencies, permissions, local and remote relations, etc. The key here is an intuitive, natural, flexible data structure, rather than something with limitations like xml.
2. Make this data set available as something like a .torrent file. Set up private data within it to be encrypted with a private key scheme, and/or have separate torrents for different privacy levels.
3. Instead of users having to sign up on individual websites to share their data, reverse this so that websites have to get permission from users. For example to allow facebook to access your data, instead of ever creating an account on FB or another site, you would simply provide your .torrent file and optionally some of your private keys to sites thereby authorizing them to access your data through a P2P network.
Paul Mackay wrote on 04.10.11, 5:07am:
I think this is a great idea but certainly would need a lot of exploration to find a model that might work.
One issue I initially thought about solving that is perhaps a step before this was improving discovery of such services and networks. I've done quite a lot of Freebase schema design around sustainability themes, including this Sharing base (http://sharing.freebase.com/). The goal was to define anything that is some form of sharing system to describe what area it relates to, what kinds of things are shared and what method is used for sharing. Other more specific types might go into this domain, for example car/bike sharing operations with details of their sites, but this is start.
Freebase has an extensive API so if this was filled out it would be easy to query things like what sharing systems are in my local area, etc.
Juho Makkonen wrote on 04.11.11, 3:14am:
Dan, what you are suggesting sounds a bit like what I tried to illustrate in my approach 2. A distributed Diaspora-like model would definitely be an interesting, albeit challenging direction.
In the article I talk very positively about distributing users' reputation across different service but actually I see quite a few problems there. Reputation is always heavily dependent on the context. That is why we can never have a "centralized reputation server". Bryan Glass and Randy Farmer have written a lot about this in their excellent book "Building Web Reputation Systems" http://www.buildingreputation.com/ As they explain, you cannot even transfer movie reviews from one service to other, since the two services might have a different target user group, which affects the total score. But one solution to this would be that each service would simply show separate figures from other services: this guy has 3,5/5 stars in NeighborGoods, 98% positive in eBay etc. That way people could put those reputations into context.
Your SharedEarth project also looks really interesting, and really close to what we are doing! Especially the bit about transparency is interesting, since we are doing the same exact thing: sharing our code and process via Github, Pivotal Tracker and Google Docs. :) We also have a blog called "Avoin yritys ("open company" in Finnish) where we tell about our progress. I'd love to talk a bit more with you about all this!
David, I also thought about having the data in your own computer. Now I'm wondering whether that kind of playing with torrents and private keys would be too complicated for a regular user that does not understand that much about computers. And would it also mean that you can only access these services on your own computer? At least the data would probably have to go through one's own computer every time, which might make it tedious to use multiple services on the go.
Paul, Freebase looks really interesting, I have to check it out, especially your sharing base. There actually was a comment in this article about using linked open data to enable this collaboration but it seems to have disappeared, I'd love to hear more about that.
--
Juho is a Co-Founder and CEO of Sharetribe, a platform for creating custom peer-to-peer marketplaces. http://www.sharetribe.com
David Gleason wrote on 04.12.11, 2:15am:
Juho, a couple of thoughts, I think that in a more general case it's good to start with the data on the user's computer, as that's initially where they're likely to have most of their pictures, files, etc. Once a user has arranged their files and data into a larger structure though, it would then move onto a distributed network, and then be accessible from anywhere. And by the way my mention of a .torrent type of file and encryption keys is just conceptual, and of course the user should not need to know anything about those sorts of things, and ideally should not have to use more than one application. Another way to look at it might be to consider the user's data structure to be like a git repository (most users may not need versioning of course, however if you could support it at some point there might be some use for that as well). Anyhow, giving the user an easy-to-use local app to assemble their data into one nicely organized structure could greatly simplify things, as they wouldn't need to depend on any websites or internet connectivity (a plus for mobile users who are not always in range of a network). Also, if they had a lot of large files, it could save time since they wouldn't have to upload everything to a server. And while that might not be significant for a classified ad application, I was thinking of a more general solution, that could also support other social media functionality. From the user's point of view, it would be nice if one app could support multiple needs rather than having to deal with numerous different apps/sites/services. I think that if a solution is not going to streamline things for users on a more general level (i.e. not just for the short term uses you're focusing on), you'll have a harder time achieving widespread adoption. And though a more general approach might take more time up front, the potential payoff is much larger, particularly if you can get some other developers to partner with you who are also interested in furthering these sorts of functionality.
A side benefit of this approach is data backup. Probably few users have a solid backup plan implemented for their important files and data, as that's often a tedious process, especially for users who use more than one computer and/or mobile device. Enabling a user to organize their data and distribute it in a P2P sort of way to various sites and services of the users choosing, would give the additional benefit of their data being online where it can be easily retrieved if needed.
Dimitris Tzortzis wrote on 04.13.11, 4:53pm:
What if you focused on the actual item/service that is being shared, instead of the user that is sharing it? I mean, if the API was formed around the transactions that can take place between community members, then the people won't have to give out to other websites their personal data.
The "transaction" (if I may use this word) is what is being communicated between the two or more websites that are using this API.
So the websites-communities could send to each other (on demand) data about what's being shared but focusing on the actual item/service instead of who's doing it. The user could simply be shown as a nickname, thus protecting his privacy. Then if they both want to engage in the actual "transaction", both parties could authenticate a peer-to-peer communication so that contact details can be shared.
So, in the end, everyone has chosen their preferred community to be with while still being able to interact with other communities without ever leaving his. Everybody wins I think :)
What do you think?
David Gleason wrote on 04.14.11, 10:53pm:
p.s. - The pieces probably already exist that could allow this to be done in a distributed way without a lot of work required. Here is a great article from a few days ago that talks about some projects that might be useful: http://emergentbydesign.com/2011/04/11/88-projects-standards-for-data-ow...
Judy wrote on 04.15.11, 12:36pm:
We're using CouchDB on Cloudant (https://cloudant.com) at Givmo (https://www.givmo.com), and one of the first things we thought of was having all our items in a public couch database and then since Couch provides a RESTful JSON API, it'd be easy for other people go come along and pull out data for whatever they wanted. We still want to do it, just haven't yet. But in general, CouchDB's rest api, easy replication, and schema-less design could work really well for this.
Juho Makkonen wrote on 04.17.11, 7:10am:
Matthew, so you work in collaboration with CES? I know some folks in Finland who are using it and I think the system is really interesting. The current problem with it - according to many people I've spoken with - seems to be that the user interface is rather complicated for most, and the general look and feel of the system is a bit old fashioned. With some simplification and some efforts put into user experience in order to make it more user friendly and modern it could be a truly amazing platform (well, naturally the biggest barrier preventing it from going mainstream is naturally of cultural sort and does not depend on the user interface).
David, thanks for clarifying your thoughts. A git repository -type approach was also in my mind when I was talking about the distributed storage, and I think that storing the data originally also on the users' computers is an interesting approach that should definitely be looked into. However, that creates a problem: who should be the one responsible for that application? Would this party then have too much control over everything, and would other services be dependent on the application? And creating an app like that collaboratively is a difficult path, especially when many parties might feel that the time put into the project would be away from their core business.
I also feel that the system should not be too general. A line has to be drawn somewhere, too general approach will not be useful to anybody. That's why I would be limiting the solution to sites that are about sharing physical resources (possessions, skills, spaces) since those have a lot in common. While an idea that everything could be handled via a single interface sounds tempting, that might also mean that that single interface becomes extremely complicated. For example, I still haven't found an application that would enable me to use both Facebook and Twitter from the same UI in a satisfactory manner, so I keep using those services separately.
Dimitris, that's a really interesting idea! It's an excellent compromise between the two approaches I presented in the article: something that would enable transactions but still would not require too heavy dependence. One thing I'm left wondering is how trust information is transferred. I would probably only share my contact details with a person that seems trustworthy. Seeing a nickname at that point would not be enough, I would need to somehow get assurance that the person who is requesting something from me via another servide is trustworthy before I could make the actual decision of engaging in a transaction.
Judy, thanks for sharing that. If a common database would be formed, CouchDB would definitely be a good option for that.
--
Juho is a Co-Founder and CEO of Sharetribe, a platform for creating custom peer-to-peer marketplaces. http://www.sharetribe.com
Matthew Slater wrote on 04.17.11, 7:36am:
Hi Juho
The extent of my official collaboration with CES is to support their new API for trading between groups.
CES is certainly aging but it remains the most fully featured and mature off-the-shelf solution for mutual credit systems. The next thing for the software is a total web 2.0 overhaul, but its a big job and the money just isn't there. My intention is to support them by working on the tools (in Drupal) and the APIs for the rebuild when it happens.
The tools are: mutual credit module, global offers and wants directory, and some kind of reputation system
Sophie Garrett wrote on 04.20.11, 2:44am:
Thanks for this post, it coincides with some of my recent thinking. I should state right away that I'm not a developer, but I have been running yours2share for well over four years and I've seen a lot of sharing websites come and go.
It strikes me that whilst the second approach sounds great, I think it might be impossible to implement, whereas the first approach should be relatively easy to achieve and provides a win-win for both the large and small services, and more importantly the user.
There also appear to be two big issues with the Diaspora approach, firstly I can't understand Facebook's privacy controls (and neither can any of the non-techy people I've asked) so anything more complex has no hope. Secondly the trust issue is enormous and not just between services, the user has to trust that this potentially huge and complex co-operation has sufficient control on its data. The whole service is only as strong as its weakest link.
Regarding reputation, I think there is a bigger picture than just sharing. There is a need for bigger aggregator service/website to take reputations from a huge range of websites and forums etc. The individual should then be able to agree or not to having this reputation status pulled into any other service. I'm not aware of such a service, I don't know if anyone is working on this, but I can't believe they aren't.
Whichever way, I would really like to be involved in any developments to bring together the various sharing services simply because it will make it easier for people to find stuff to share and thus increase sharing. And I'll work hard for anything that does that.
Helping people to share stuff
yours2share, WiRE Norwich and JellyNorfolk
Antti Virolainen wrote on 04.21.11, 3:42am:
Good points have been brought up here! I also tend to think that even though the diaspora-style distributed data management systems are fascinating in a way, I doubt that it could in practice be carried on as the way to unite collaborative consumption services. The level of complexity in simpler API level cooperation is already quite high for a single collcons startup with hands full of work.
For API approach there are some good suggestions, like concentrating on the transaction i.e. the item, service or whatever is being shared and leaving the user information and reputations on the service.
One problem that was mentioned in the article was that even if the searched item is found via API, but it's available in another service, the user would need to register there. But if the API would also define interservice messaging, the registering could perhaps be avoided (if the user wants to avoid it). The requester could send a message from his/her "home" service and the other party could receive it in his/her own service. Then they could communicate peer-to-peer (without exposing their contact details if they don't want to) and agree about the details of the transaction.
If the services have public profiles, those could also be checked and maybe even reputation info would be visible there. The users could easily put the reputation information in context as they see it in that service's page where ratings are coming from.
However, this probably would not make it possible to give a rating to the other person without registering to that service... So the interservice transactions would be less likely to increase reputation, and thus maybe less preferred by some.
Dimitris Tzortzis wrote on 04.21.11, 7:55am:
Antti, what you described in the third paragraph is exactly how I had it in my mind. About the reputation, I think there could be a measure for reputation that counts (positive) transactions with other platforms. I think that also could be implemented easily alongside the API.
Also, I believe that if someone feels like sharing then they don't need the reputation as an incentive to do that. For example, when I joined couchsurfing, I wasn't hosting people to get references, I just did it. And if you think about it, communities like freecycle without *any* measure of reputation, references, feedback etc. are doing quite well for many years now. So maybe that's also not such a huge problem :)
Dimitris Tzortzis wrote on 04.21.11, 3:36pm:
After some more thought I want to add something:
what in my mind is the hardest part for this API is the fact that a lot of the communities we're talking about (communities about sharing) are using a multitude of platforms for their web places. So, for example, in my city, Freecycle is using a mailing list (a yahoo-group) while some other community has created a social network on Ning. So, even if they wanted they couldn't add the code for the API on these platforms.
All in all, this sums up to the fact that if the communities we'd like to connect with such an API are not using a database "behind the scenes", or if they don't have access to such a database, then I can't think of a way this API could work.
Juho Makkonen wrote on 04.26.11, 2:02am:
Matthew: good to know that a web 2.0 overhaul is on the way for CES, hopefully they get it done!
Sophie, there have indeed been people working with all kinds of reputation aggregators, but the problem always lies in the contextuality of reputation. Reputation in one service might not mean that much in another.
Dimitris, I think the need for a reputation mechanism depends on the type of the service. Freecycle works because people have little to lose: they are simple giving away stuff they do not need any more. On the other hand, services like eBay would probably be used a lot less without a way to determine whether the other party is trustworthy. Some people would still use it - like you used couchsurfing, not everybody is that concerned about trust - but it would definitely have hard time achieving the same critical mass it has today. So I do see the reputation systems as a vital part of these systems, so some kind of an implementation should probably be considered for the API.
Also, a good point about some communities that are using existing platforms they have not developed themselves. But while that is true, there still exists a great deal of services that have created their own platform and would benefit significantly from the API. Even getting one tenth of all communities to collaborate would be huge, since currently there are hundreds or even thousands of different platforms.
--
Juho is a Co-Founder and CEO of Sharetribe, a platform for creating custom peer-to-peer marketplaces. http://www.sharetribe.com
Dimitris Tzortzis wrote on 04.26.11, 3:22am:
Hello Juho,
I understand what you say about reputation. Reputation is definitely more important when money or other sensitive "stuff" is involved. However, although I understand the need for reputation I strongly believe that a "reputation system" should not be based on an external service, a reputation "provider", a commercial service that "syncs" our reputation across the web. That, in my opinion is in complete contrast with the idea of peer-to-peer. It becomes a "peer to reputation-service to peer" thing. Trust, though important is the argument the corporations have used against peer-to-peer alternatives and I think we need to create a system so that the users provide feedback for each other, for the transactions they engage in but still is autonomous and truly peer-to-peer.
:)
Davison wrote on 04.26.11, 11:44am:
"[...] our common goal is to boost sharing by mapping all the resources that people have to share and linking them together. Would it be possible to form a huge pool of resources that all sharing economy services could then use to their benefit?"
As per Judy's comment, a RESTful API seems like a relatively easy approach for technical-minded organizations to integrate with. Fluidinfo (http://fluidinfo.com) is a startup working on a publicly shared cloud datastore. They provide a RESTful API so that you can read and write information in there. The main idea is that the world should be writeable and shareable. I think that it would be a good fit for the sharing API that Juho advocates for collcons organizations.
The idea is that you can tag anything. Objects have no owners, so anybody can tag them and are "public", but the tags themselves (presumably owned by users, applications or collcons organizations) can be hidden if desired.
It wouldn't solve the problem of the distributed data store, but perhaps that could be addressed with the following approach:
1) Original silo/application data residing in the collcons organization
2) Local user computer (whether they choose to store their transaction information & reputation metrics in a cloud)
3) Public sharing repository
4) Distributed/federated Diaspora or Locker (https://github.com/quartzjer/Locker) data stores
Judy mentioned that Givmo is thinking of providing a public CouchDB instance; that would work just as well as Fluidinfo for #3 above since they both offer the same types of advantages (single-instance public datastore, RESTful API, schema-less, redundant).
The question around interfaces and reputation management related to different metrics/weighting per service context is not easy. I am more in favour of each individual collcons service augmenting their existing service in babysteps as Juho described in his post.
"This approach is not perfect. When actually borrowing the item, the users would still need to sign up for those services. They would not be able to take their data from the original service with them."
Yes, users may need to sign up for separate services (unless somebody else implemented a Single Sign On solution such as OAuth among the collaborating services?), but at least they should be able to share their data from the original service publicly. This would at least allow the user to selectively share certain information with other providers. Whichever public data store is used would hopefully have a permissions model that allows selective sharing of information that you imported in; Fluidinfo has one, but I'm sure others would be able to as well.
Dan wrote on 04.26.11, 3:42pm:
great to see so much response on this. juho, you've really struck a chord with the idea of sharing sharing services.
i've been reflecting on what are some of the ways we can work together, as separate providers of sharing services.
davison, i'm feeling quite comfortable with your suggested approaches. just to clarify though, is that 4 approaches, or 1 approach with 4 steps?
something that would be worthwhile for us to work on is creating standardised definitions of reputation metrics. doing so would allow us to interchange the information where they are the same.
for e.g. for sharedearth, there are 3 reputation metrics
1 - gift actions - the number of gift actions someone has completed (either they have shared or gifted an item, space, or their time to someone)
2 - distinct people - the number of distinct people that a user has gifted to\shared with. this metric is handy to assess the authenticity of the user, i.e. if someone creates 2 accounts, and performs 85 false transactions with the two accounts, the first metric (gift actions) will be 85, but the second metric (distinct people) will only show 1. alarm bells should start ringing for people.
3 - positive feedback - this metric covers gift actions and receiving (unlike the other metrics). quite simply its the percentage of interactions on the site where the other party has rated the overall experience as being positive. e.g. user has gifted 5 times and being rated positive, and borrowed someones item 5 times, but received 1 negative rating and 4 positive for the borrowing. the positive feedback metric is 90%
what reputation metrics are other people using?
naturally, my hope is that by sharing our thoughts on this, we can all take advantage of the experience and reflection everyone has done in this area - take the best metrics, and all build better and more useful sites.
Dan wrote on 04.26.11, 3:43pm:
one more thing - how can we constructively continue this discussion in an ongoing and semi-structured way.
perhaps someone should setup a mailing list?
Davison wrote on 04.27.11, 7:59am:
Hi Dan,
"1) Original silo/application data residing in the collcons organization
2) Local user computer (whether they choose to store their transaction information & reputation metrics in a cloud)
3) Public sharing repository
4) Distributed/federated Diaspora or Locker (https://github.com/quartzjer/Locker) data stores"
Upon further reflection based on your comment, I should have flipped the order of #2 and #3. I meant for the steps to be a suggested incremental approach to ease the implementation and use of a sharing API; definitely not to be implemented all at once because there are surely higher priority items to take care of in the day-to-day running of the service.
bryan wrote on 04.27.11, 10:07am:
We are: native professional inca trail guides, trekking machu picchu and inca trail guides in cusco, peru tours operator, specialized team, quechua and english speaking peruvian tour guides, trekking guides in cusco, independent peru tour guides. Take your time to explore all our site, inca trail experienced guides. Write us for more info about our unique and new tours in peru.
http://www.inkachallengeperu.com
phone: +51-984356699
cusco-peru
Juho Makkonen wrote on 05.03.11, 12:24am:
Hi everybody,
Great discussion here!
Dimitris, it is definitely true that a p2p reputation system would be at least a good baseline upon which services could then build their own additions.
Davison, Fluidinfo definitely looks like something that is worth looking into, it might very well be suitable for this. And the incremental approach you suggested sounds good, this definitely has to be implemented step by step.
Dan, your reputation system sounds interesting. I think the traditional feedback system is in place in most services - also in Kassi. What I'd like to add to that is the impact of the social network. For instance, if there's a person I don't know but we have both shared with a same person (or have a friend in common) that creates trust between us. Another possible metric could be reputations of people in my network, but that might be overly complicated.
Again I'm not sure whether the same metrics can be effectively used by all services, at least I do not believe in creating any single "reputation figure" that could simplify a person's reputation. Reputation is made of many things: stuff like what a person's profile looks like and what kind of information has he provided about himself also play a role. But I still agree that some kind of standardization in reputation metrics would be at least a good start.
I also agree that we should definitely set up some kind of a discussion forum to extend these ideas further in a more structured manner. Would a google group be suitable for this? A created a group that can be found here, please join http://groups.google.com/group/api-for-sharing/
--
Juho is a Co-Founder and CEO of Sharetribe, a platform for creating custom peer-to-peer marketplaces. http://www.sharetribe.com
Adam Berk wrote on 06.25.11, 9:08pm:
I started a p2p sharing the sharing trust aggregator on www.thanQ.us - the goal of course is to get the sites to contribute via the API - as of now we just rely on users.
The link is just a rough prototype sans design - comments and criticism welcome!
@neighborrow
@adamberk
@weddingphotoapp
Adam Berk wrote on 06.26.11, 8:04pm:
http://www.facebook.com/group.php?gid=146288305388803
i started a facebook group about a year ago for this purpose:) i love the extreme transparency angle - i think its a no brainer, esp in this space
@neighborrow
@adamberk
@weddingphotoapp
Juho Makkonen wrote on 06.26.11, 11:00pm:
Adam, this sounds very interesting! The work you have done might be just what we need. I invite you to join the discussions in the google group http://groups.google.com/group/api-for-sharing
--
Juho is a Co-Founder and CEO of Sharetribe, a platform for creating custom peer-to-peer marketplaces. http://www.sharetribe.com
Yes!
You should go a step further and see how practical this API is. The field is very new at the moment and the services you mention are all doing things rather differently, so it might be a bit early for such an API.
I'm looking for an open classified ads API, with geolocations, and working on an API to allow complementary currency transactions between systems.
Diaspora isn't the only platform in town either. See en.wikipedia.org/wiki/Distributed_social_network