Fullscreen
Loading...
 
[Show/Hide Right Column]

Close
noteNote
This page is to document "what Tiki should do". For feature documentation (what Tiki does), please see corresponding page on doc site

Community Currencies

See also: Bitcoin

Community currencies for Barter networks, such as http://intercanvis.net . Using CCLite ( http://sf.net/projects/cclite ) - see CCLite manual (pdf)

One use case would be the "Time Banks" (see time banking), getting quite famous and common world wide. CCLite software (see below) seems to be the best option to have something working before the end of April June 2010 (deadline for the funding of this project), and to avoid the spread of closed source systems such as CES (Community Exchange System).

Basic documentation about this feature is on:
http://doc.tiki.org/Community+Currencies

1. Community Currencies (Take2)

[+]

Wishlist

1. Open

2. Pending

[+]

3. Closed

[+]

2. Deadline

  • February-March 2010: Installation of CCLite 0.7 in a server with ssh access (ourproject.org). Done
  • Mid - April 2010: Tiki trunk (6svn) also installed and woreking on that server. Reinstallation of cclite on our userspace and not the doc root of op.o Done
  • 1st half of May 2010: Learning how to use and extend Tiki payment and kart features. Done
  • 2nd half of May 2010: Some interaction between Tiki 6 and CCLite 0.7 is expected. Done
  • June 2010: The system should be ready for testing on some server Done ( http://c2c.ourproject.org )
  • July-August 2010: System should be working (alpha). Xavi also testing CClite 0.8 in other servers.
  • September 2010: System should be working (beta) and basic documentation written on http://doc.tiki.org/cc Done.
  • October 2010: CC System released with Tiki6
  • November 2010: Better error reporting with the communication between Tiki and CClite
  • December 2010:


Our budget needs to be spent before June 2010, and the system should be working by then. Arranged to have this new deadline set.

3. People interested in being involved

  • Xavi, requesting coders to suggest how to design such a system. There a modest budget to pay coders for implementing it.
  • Luci, at least in the social networking part (as far as Xavi knows :-) )
  • jonnyb: yup, i'm interested, but rapidly running out of 2009. I will try and investigate though, sounds like an excellent project!
  • sylvieg coded a few pieces here and there (like the Batch feature linked to a cron)...
  • add your name here and you topic of interest

4. People potentially interested

As far as Xavi knows...:

  • mose

5. Plan

Phase 1

Premises:

  • Users will have to register in Tiki, and in CClite, with the same username. In Phase 2, other methods will be allowed (either openid, if properly supported by CCLite 0.8 or by other means in tiki, such as allowing each user to set their own CCLite username in the user tracker)
  • payment permissions:
    • admin
    • view
    • view_own (needed, not done yet as of July 21st, 2010)
    • manual
    • request


Tasks:

  1. add tracker name and first "isMain" field to the notification emails sent when someone adds a comments to a tracker item. (Useful also for the bug tracker at dev.tw.o, btw) (Jonny)
    1. Notification emails should parse wikitext in statictext fields, so that users don't get wiki syntax, but simple text from parsed html (jonny)
  2. Admin can define several registries existing in CClite, with their corresponding currency for each one, in "Admin > Payment > CCLite". (Jonny)
    • Done, but buggy: there seems to be some confusion in tiki between the currency used in tiki payments (beyond cclite), and the currencies defined in the cclite installation.
  3. get email sending to work in c2c.op.o (Xavi) Done
  4. request Hugh how to create a new registry or edit currencies in them:
    • cclite is complaining that the c2c3 new registry exists already, but it's not shown in the list of registries, however. The database is created beforehand (c2c3)... so we don't know how to add this othyer one. (Xavi)
    • I don't know how to edit one currency ("time") from the list of currencies from registry c2c1. (Xavi)
  5. add the feature to allow reverting the item/money you got (in case of errors, payment in community currency lower than agreed, etc.). The receiver or manager can revert it, not the sender/payer. (Jonny).
    Revert might be implemented by just creating a new transaction request of the same amount, in the opposite direction. Even if for the technical it will not be real "reverting", for the end user, clicking in just a button called "revert" (or similar), it will act as reverting. The system will keep that as a new transaction, like in common banks.
  6. communicate Tiki user balances (in that community currency) with the accounts in CCLite without the need to trade with manager (just any user directly to any user). Done (Jonny)
  7. user homepages should show items offered and requested by that user, splitted among open/pending, and closed. (Luci)
  8. Show cclite balance for the Tiki user in the user profile page bundled within Tiki: "My payments" or "My Tradings" or "My Transactions", (one only name has to be chosen). (= even if SNiPTT is not applied in that Tiki site). (Jonny)
  9. "trade & cclite plugins": make them work, so that it can be added in the SNiPTT user pages, etc., and make them payment-permission aware (jonny)
  10. user homepages should be easily printable with all the information on them: public contact deails, offers & wants at least, cclite account status and/or history of transactions done, plus comments/reviews/recomendations from other users, etc. (Luci and Jonny ?)
  11. add new permission tiki_p_payment_view_own (needed, not done yet as of July 21st, 2010) Done
  12. understand how payment_request permission works in fact, looking at the code and trying or asking lph (Jonny)
  13. once the money of the payment request is transferred, change status of that tracker item to pending (or closed?) (jonny)
  14. update Barter profile to match current improvements in c2c.op.o/tiki, as of July 22th 2010. (Xavi)
    • new tracker fields for offers and wants
    • update pretty tracker templates to use those fields
  15. user profile should allow for comments from other users, like "recommendations" in Linked in. Afaik, this is planned or done in the SNiPTT profile? Luci?
  16. FOAF should get messages from those recommendations posted in a user's wall (like linked in, or facebook, etc). Afaik, this is planned in the SNiPTT profile? Luci?
  17. change in tracker status after some time specified by admin in a tracker basis. (sylvieg) Done
  18. test that user creation in cclite can be handled by tiki, even if the email sending in the cclite at op.o is not working. (at least nowadays that we successfuly have new user accounts created by default in cclite as "accepted" without user nor manager intervention). (Jonny?)
  19. document cron tasks based on the example by jonny at c2c.op.o/tiki as of July 22, 2010 (Xavi)
  20. newsletters: when an email attempts to be subscribed, and that email already exists, no email message is sent to that user saying anything, while the tiki page says to that user that he/she will receive an email with instructions. Solution: either report at subscription-request time that the email is already subscribed and valid, or say that in an email to the user, with the link to validate the account (if not validated yet). (Sylvie)
  21. Ensure that a user is able to follow clear steps to have tiki profile "Barter" installed, and to know which changes need to do in their tiki local configuration to have their tiki site working with the cclite installation at c2c.op.o (if something else is needed beyond applying the Barter profile): a simple transaction using currency from cclite, ... (Xavi). Started at http://doc.tiki.org/Community+Currencies#Add_a_new_barter_node_to_the_network
  22. Provide some error reporting to the user (plus record it in the action log) when:
    1. "username [from user X willing to trade in tiki through cclite] doesn't match any username in cclite
    2. "transaction request would exceed the maximum negative budget allowed for user X. Contact the cclite trading network (registry) manager [email or link to intratiki messaging to that user] if needed."
    3. "currency name X in Tiki doesn't match any currency name for this trading network (registry)"
  23. update Barter profile to match current improvements in c2c.op.o/tiki, as of the end of phase 1. Add the equivalent pages for "wants" as they are for "offers"(Xavi)



Phase 2

  1. gpg support for Tiki to CClite comunication
  2. Users can write themselves the name of their CClite username at the user tracker in Tiki.
  3. add the ability to work with several community currencies Done once the tiki admin adds the information of the registries and their own currencies as created/defined in CClite.
    + in Mod CC that was designed as:
    1. admins can create new currencies
    2. users can see the list of available currencies, and agree to use one or several of them So far, not clear if we want to work in that direction, or just let tiki work with whatever is supported by CCLite.
    3. trading among users can be done if both users have one currency in common (they both have agree to use at least one common currency). Keep in mind that each local barter network can have decided to use only it's local currency internally, which might be different respect to other currencies. So far, not clear if we want to work in that direction, or just let tiki work with whatever is supported by CCLite.
  4. a simple way to allow future exchange of money among different currency systems would be if each currency keeps some relationship with the unit time (hours, or minutes). Beyond tiki features. It can be agreed among barter networks and defined (hopefully) in the CClite side.
  5. "add to wishlist" (beyond "add to cart"). Wishlist: so that others know what I'm interested in, and they can look for that object, service, etc,, if they need something that I'm offering and they don't have my need right now (yet).
  6. extend trackers with the ability to use { $f_n } code (similarly to the behaviour in pretty trackers) in the field "static text", so that payment plugins can work in standard trackers, without the need to use "Pretty Trackers". (Jonny)


6. Uses cases for cclite & external cms interaction

Extenal CMS is Tiki, here. But these use cases should be applicable to other external CMS (Drupal, Elgg, ...)

6.1. Creating nodes

User Maria is an admin of the Tiki for the Barter Network "EcoXarxa Barcelona", and she requests to the central cclite admin Xavi dp. to have her Barter Network as one registry in the central cclite, with registry name "c2c1".
Two currencies are defined for that registry c2c1:

  • Eco-coops, EC (ECC)
  • Hours, H (HOU)


User Xavi L. is an admin of the Tiki for the Barter Network "Xarxantoni", and he requests to the central cclite admin (Xavi dp.) to have his Barter Network as another registry in the central cclite, with registry name "c2c3".
Two currencies are defined for that registry c2c1:

  • Ecos, E (ECO)
  • Hours, H (HOU)


User Gloria is an admin of the Tiki for the Barter Network "La Marina", and she requests to the central cclite admin (Xavi dp.) to have her Barter Network allowed to trade in the central cclite within the registry name "c2c1".

Maria, Xavi L. and Gloria follow the steps described at the documentation in:
http://doc.tiki.org/cc

6.2. Managing users

Note/Suggestion: Usernames whould be case insensitive in cclite, to avoid issues with cases in the communication between cclite-external app, as we have had in the past with cclite-Tiki.


User Pep (Pep A.) registers in a Tiki for the Barter Network "EcoXarxa Barcelona".

  • He decides to use cclite as the paying mechanism in that tiki-powered barter network, so that he goes to some interface in Tiki to accept to trade using all currencies defined at the cclite registry "EcoXarxa Barcelona" (c2c1, in the cclite central site).
  • When Pep clicks at that button in Tiki, Tiki creates a username for that registry c2c1 in cclite, and remember the user election to use 1 or more currencies defined in that cclite c2c1 registry.
  • Since there is no other user with such username in cclite registry c2c1, cclite creates such username for such registry, reporting back to Tiki that the user was created successfuly.
  • if some missmatch in the currency names between the request in tiki and the ones defined in that cclite registry c2c1, some meaningful error message is shown to the user in tiki plus some way to report that issue to the admin is enabled.
  • If everything goes alright, Tiki shows that message to user Pep, confirming that the process succeeded, and that he can start using the tiki-cclite system to trade in Tiki with cclite-c2c1 budget up to XXX amount of that currency.
    (the XXX amount is the one defined for that cclite registry)


Another user called Pep B., from the Barter Network "Xarxantoni" (c2c3 in cclite), is also registered as user "Pep" in that other tiki site. He then decides to accept using all currencies from the registry c2c3, and proceeds in a similar way as Pep A. did for c2c1, but in this case, Pep B. does at c2c3.

A third user Pep C., from the Barter Network "La Marina", is also registered as user "Pep" in that third tiki site. He then decides to accept using currency Eco-coops (but not Hours) from the registry c2c1.

  • When Pep C. clicks at that button in Tiki, Tiki attempts to create a username for that registry c2c1 in cclite, and remember the user election to use Eco-coops currency defined in that cclite c2c1 registry.
  • Since there is another user with such username in the same cclite registry c2c1, cclite creates such username for such registry appending a correlative number (e.g. "pep1", reporting back to Tiki that the user was created successfuly with such username because "pep" was already taken).
  • if some missmatch in the currency names between the request in tiki and the ones defined in that cclite registry c2c1, some meaningful error message is shown to the user in tiki plus some way to report that issue to the admin is enabled.
  • If everything goes alright, Tiki shows that message to user Pep, confirming that the process succeeded, and that he can start using the tiki-cclite system to trade in Tiki with cclite-c2c1 budget up to XXX amount of that currency.
    (the XXX amount is the one defined for that cclite registry)
  • Tiki saves that username "pep1" in a field of the user tracker, to remember that when user "Pep C." ("Pep" in that tiki) wants to trade in that c2c1 registry of the central cclite, tiki has to use "pep1" as his username in c2c1.

6.3. Managing currencies


Something similar to what has been described with users above?

7. Potential extra funding for this project

See nlnet Foundation: Open Application for Project Financing
http://nlnet.nl/foundation/request/application.html

Documentation

http://doc.tiki.org/Community+Currencies

Development sites

Custom profile to show this feature

Related profiles

Other links

Accounting
doc: Payment


Closed source alternative (getting very popular worldwide):

Aliases

CC | cc | c2c | CommunityCurrencies | CommunityCurrency | Community currencies | Community currency | Communitycurrencies | OpenMoney | Open Money | Barter | Currency


Spaces [toggle]

Search Wishes (subject only) [toggle]

Keywords [toggle]

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.




TogetherButton [toggle]

Documentation: PluginTogether