Intro

Community Exchange Systems (CES) and Community Forge (CF) are both networks of Community Currencies creating and implementing appropriate technological solutions. Together they provide several hundred communities, including for Timebanking New South Wales with hosted mini-social networks with accounting and other community tools. We are working towards nothing less than a parallel financial system in which peer to peer credit is used as an interest-free medium of exchange.

We notice that a great deal of software innovation is focused on building global communities of individuals; when local or geographic communities are mentioned it is merely as a way for users to connect, and groups are rarely enabled to configure their software, govern themselves, or even collectively migrate to other software. Our approach to social software is towards creating open protocols, so as not to trap users in silos but empower them with tools and standards.

CES started as a single web application which grew to host multiple groups. CES communities depend heavily on the server administrator and have few configuration options, but they enjoy a high level of integration, for example being able log transactions and view offers and wants between communities. In contrast CF gives each community its own Drupal instance, which means they have a high level of control and configuration, but great difficulty interacting between each other...

The two organisations are working together to give member communities a full range of hosting options and integration. We understand the best approach is to abstract features which should run between communities into web services. This is in line with the thinking of the Collaborative Technology Alliance, though we are concerned almost exclusively with two particular services.

1. Accounting. While each community should keep its own accounts, transactions between ledgers need to be stored by a neutral 3rd party. We briefly described a model for such a web service, called the Credit Commons, which would be economically sound and very scalable in a recent white paper. This is the less urgent of the services, since we have an early prototype working.
2. Classified ads allow members to advertise opportunities for exchange, support and interaction. They are a vital part of any community hub. Local economies are often too small for exchanges to be identified. Also many services are increasingly online and thus independent of location. We therefore need a web service which simply stores and retrieves categorised classified ads outside and hence between each community's social network silo.

Other requirements

We have considered a few options of existing software such as ShareTribe but found nothing which supports this community approach; everything assumes that the account-holders are individuals. The distinction is important because because we prefer to keep member information on a local server and store the ads in an anonymised way. The web service would forward contact requests to the local server which would then forward expressions of interest to owners of the ads.

Taxonomy is a special challenge when making objects searchable accross languages and cultures. There would be a great deal of negotiation involved in agreeing a taxonomy of ads, and translating it would throw up all kinds of issues. However we do not desire a perfect solution. It is more important to support local categories, local searching and local retrieval. It seemed to us therefore that each object would be stored with some untranslated keywords which may or may not correspond to taxonomy terms in the community social network. It would also be possible to filter ads using the full text of each. This, in combination with other filters detailed below, should be adequate without being complicated.

For speed and to work better with modern app design, the service would allow the client to interact directly with it, but using the account of the users local social network. So a local community portal/social network would have an account with the web service, and might be always logged in. When the browser or client app wants to connect to the ad directory service, it would log in to the local social network and recieve a token and the url of the service. Then it would make requests directly to the service and the token would identify the client as requesting from that community's account.

Geopositioning is crucial, especially if the service were to support immediate transactions, and especially for people not at home.

Draft API

Endpoint: /login
We don't know enough about authentication to include it here.

Endpoint: /ad/{id}
GET all the data for one object
PUT some or all of the properties to update an ad
DELETE to delete an ad

Endpoint: /ad
GET a list of ads with enough properties to show in a list, filter by the url params
POST create a new ad with some or all of the properties.

Endpoint: /relay/{id}
POST a message to the owner of the ad with the passed id

Endpoint: /forward/{id}
POST Notify the owner of the ad using an email twitter or phone number, and message body.

Proposed properties of the ad object

• Advertiser's community ID
• Advertiser's local user ID
• Title
• Details
• Keywords
• Latitude
• Longitude
• type (this would be offer, want, activity and possibly few others)
• visibility (int) 0 means hidden/unpublished, 1 means visible to the owners own community, 2 means visible to all
• expiry - the date on which the ad should be deleted
• Barter (bool) Willing to barter
• Goods/services (bool)
• Cash (bool) part or full accounting in cash.
• Local currency (bool) part or full accounting in local currency
• Identity required (bool) The owner will only trade with someone who's identity is known to their community

Other thoughts

Ideally we believe this is a good case for a blockchain but we don't know how much harder that would be to create, or where to start. In the long term we would like to move our tens of thousands of users onto distributed pluggable, open source social network like Synereo or Fermat, but we nothing is even nearly ready yet.

For the foreseeable future though, we would be content with a centralised service which we would host for all who needed it.

If we had to build it ourselves we would use a simple REST framework, but we believe Symfony or something similar would be much more appropriate.

Our Request

Part of our approach is to work without money as far as possible. What money we do have would cover the merest fraction of the commercial cost of what we are doing, and we prefer to spend it less as wages and more on teambuilding. This RFI then is as much an appeal for volunteers as for advice. (We have a number of other technical tasks awaiting skilled volunteers who can see a jobb through!).

1. Who else is actually implementing web services for communities or even talking about it?
2. Which web framework would you use to develop this?
3. How long would it take you?
4. How much would you budget?

While money may be short, we do have an abundance of hospitality in France and credit with many local communities accross the world! Please respond to [email protected]