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.
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.
We are building for tens of thousands of users, each with a handful of ads. If they each browse the site once every two weeks, making 5 page requests, that is still much less than a request every second. Therefore performance is NOT an issue.
There should be no need for a user interface on the global database, or at least phpmyadmin would be just fine. However if a UI was provided, it could be useful for outsiders to peek in.
We don't know enough about authentication to include it here.
GET all the data for one object
PUT some or all of the properties to update an ad
DELETE to delete an 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.
POST a message to the owner of the ad with the passed id
POST Notify the owner of the ad using an email twitter or phone number, and message body.
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.
We envisage this as a single table database.
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!).
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 firstname.lastname@example.org