Time bank use cases - Githubissues

fosterlynn commented 8 years ago

Starting an issue so we can explore the use cases that time banks provide.

Ping @stevebosserman - let's figure out how best to do this.

fosterlynn commented 7 years ago

@bhaugen In your example from Mutual Aid Network, does this exchange require to do the work directly for a person one exchanges something with or it also allows to transfer timebank hours? If later that seems different then what to my understanding most timebanks do, only exchanging timebank hours for hours of work. At the same time possibility to exchange timebank hours for anything else seems like interesting possibility to me at first glance.

A little more explanation: The Mutual Aid Network has 2 pieces of software that they want to make interoperable (and we are just starting to work on it, using ValueFlows). One is the timebank software, which operates exactly timebank hours for hours of work. The other one is what @bhaugen posted the screen shot from, a marketplace app based on Odoo, and it has more flexible choices.

elf-pavlik commented 7 years ago

One is the timebank software, which operates exactly timebank hours for hours of work. The other one is what @bhaugen posted the screen shot from, a marketplace app based on Odoo, and it has more flexible choices.

What software do they use for the timebank part? (maybe http://communityforge.net/ ) When people do exchange on Odoo - timebank hours for something else, does Odoo use the timebank software as 'payment provider' for the timebank hours currency?

bhaugen commented 7 years ago

What software do they use for the timebank part? (maybe http://communityforge.net/ )

Yes. It's the http://www.danecountytimebank.org/

When people do exchange on Odoo - timebank hours for something else, does Odoo use the timebank software as 'payment provider' for the timebank hours currency?

Not yet. They use a mod of Odoo called Wezer that handles hours as well as the coin of the realm. The two systems can't talk to each other yet. That's where the value flows vocab might come in.

fosterlynn commented 7 years ago

When people do exchange on Odoo - timebank hours for something else, does Odoo use the timebank software as 'payment provider' for the timebank hours currency?

Not yet. They use a mod of Odoo called Wezer that handles hours as well as the coin of the realm. The two systems can't talk to each other yet. That's where the value flows vocab might come in.

And they aren't even to that level of requirements. Although I don't think they think of it that way, they think of just agents (as members) doing exchanges, sometimes across contexts. But we'll see. When we get to doing this, anyone is welcome to help or just offer opinions!! I'll make sure to post all in VF.

matslats commented 7 years ago

Greetings all, Bob invited to me comment on this issue of paying for Things, donating and using dollars. Its really very simple. A mutual credit system is not like corprorate accounting or REA. It only records the flows denominated in the unit of account with a description of what the payment was for. the goods and services do not exist on the balance sheet, and are only referenced in formally as they change hands. the ledger simply says: On Jun 31st 2017, account X paid account Y 100 units for "blah blah blah" In principle, any account can pay any other account at any time for any reason as long as accounts stay within balance limits. So if the currencyof reference is hours then the price of services is fixed, but the price of goods must be discovered some other way. If the currency is dollars then goods are more easily priced. But systems don't usually rule that only goods or only services can be traded. Sometimes there is a need to pay, or account for dollars spent - say if the trade involved transport and the passenger pays the driver in hours + dollars for petrol. The easiest thing is to pay cash in the car and record hours in the ledger. But it is also possible to have a second currency on the ledger, 'owed dollars'. In that case dollar accounts would need to return to zero just like hours accounts do. As we move to a cashless tyranny, this could be a convenience. Dollar accounts could also be backed for the moments when users need dollars to pay outside the system. In Drupal I have built payment forms with fields for multiple currencies, but I don't think they have ever been used. Hope that helps

bhaugen commented 7 years ago

@matslats thank you very much! For those who don't know, Matthew developed Community Forge and is now working on http://creditcommons.net/ , which we want VF to support.

enricostano commented 7 years ago

Is there any RFC you're already working on? From Coopdevs we think that probably would be nice to start working on RFCs for basic entities / workflows.

For instance, a RFC that describes how we represent the data related to a time transaction. What's a time transaction and what are the MUST HAVE attributes, how do they works, etc.

I think that if we start working on a collaborative RFC of a really basic data entity and we all agree that it covers the needs that we know for now... then all the existent applications could start implementing it in their DBs.

What do you think? Sorry if this was already discussed before and there are already 20 RFCs defining Time Banking standards 😂 😂 😂

matslats commented 7 years ago

HI Enric,

There is this Request for Information[1] which I may have shown you before. It concerns a web service not only for timebanking for members of any group to store and retrieve notices in a central place, accessible through a rest service. It looks like, this week, some guys will start building it to my spec using CouchDB. The software ecosystem I think we need will not have web platforms like the ones we all use now to serve timebanks. The future (and indeed the present) is mobile apps and REST first. So there are another couple of guys building a RESTful app for timebanking which I've designed to connect easily to any platform. I will give you the code when it is just a little bit more settled! Finally concerning the schema for transactions. I understand this is less important when we use self-describing REST APIs and HATEOAS. In any case I don't think there is much debate. You must have:

A currency ID if you are sharing a ledger
A payer ID
A payee ID
An amount, probably stored as an integer and interpreted elsewhere.
Timestamp for creation.
Transaction workflow state and then optionally
description, probably just one line is enough.
one or many categories, which probably relate to another resource.
Timestamp for last edited
Transaction type (pertaining to workflow)
Group id, if you want to group transactions together.
Comments could be attached, but probably should be a separate resource. and not
Ratings - because we'll never agree on a data format.

A transaction server is on my roadmap, and I promised only yesterday to write a functional specification. Ideally the transaction server would also implement or be a part of a credit commons, but we are far from that. The tricky thing about the ecosystem I want, is that all the stuff in public spaces belongs to a group, and members identities are not put in public, only the groups' identities. The group data & personal identities are private to members of the group, and when data leaves the group, it takes with it the group's identity not the individual's. There is surely a more elegant way of explaining it. That's why nothing exists already. Systems like Synereo are promising very granular privacy as well, but they will be vapourware for a while yet. Matthew

On Fri, Mar 3, 2017, at 07:35 PM, Enrico Stano wrote:

Is there any RFC[2] you're already working on? From Coopdevs[3] we think that probably would be nice to start working on RFCs for basic entities / workflows. For instance, a RFC that describes how we represent the data related to a time transaction. What's a time transaction and what are the MUST HAVE attributes, how do they works, etc. I think that if we start working on a collaborative RFC of a really basic data entity and we all agree that it covers the needs that we know for now... then all the existent applications could start implementing it in their DBs. What do you think? Sorry if this was already discussed before and there are already 20 RFCs defining Time Banking standards 😂 😂 😂 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[4], or mute the thread[5].

Links:

bhaugen commented 7 years ago

@matslats - anything going on between your proposals and http://freecoin.ch/ ?

matslats commented 7 years ago

Good question. I had some trouble getting my head around Freecoin. it might be a nice and ready transaction server, though I don't know how well it support all the other fields I mentioned. I will mention it in the requirements....

elf-pavlik commented 7 years ago

Hi @matslats glad to see you here!

I think we start highjacking this issue a bit... maybe we should create new issue for more general conversation about currencies, APIs etc.

Since in last years I tend to engage with various standarizations at W3C, I'd like to point everyone to https://www.w3.org/Payments/WG/

I haven't followed it that much in last year or two, but it seems that it should support all kind of 'currency systems': https://w3c.github.io/browser-payment-api/#paymentcurrencyamount-dictionary urn:iso:std:iso:4217 comes as default but one can use any currency system denoted with URI (also https: scheme not only urn:)

What I like about W3C standards - if somethings requires web browsers to implement a specific feature, cross-browser features usually rely on W3C standard to specify them.

fosterlynn commented 7 years ago

The tricky thing about the ecosystem I want, is that all the stuff in public spaces belongs to a group, and members identities are not put in public, only the groups' identities. The group data & personal identities are private to members of the group, and when data leaves the group, it takes with it the group's identity not the individual's.

So if there is an offer, or an exchange between people in 2 different groups, then the exchange will show as being between the groups. And it is the responsibility of the group to manage that internally.

(If that is right, then you explained it clearly @matslats . :) )

matslats commented 7 years ago

hi @elf-pavlik I've looked before and now again and it seems to me that the W3C has an assumption of money (and banking) which precludes complementary currencies. I think they would need to broaden their mandate significantly to make it relevant to us. I know Jaromil has been to their meetings but I don't know if he had any influence. Their mission is very clear, to standardise money payments not to enable other monies. Those other monies, such as they now exist do not implement the complex closed source banking grade payment protocols because they have neither the software to do it nor any money worth stealing.

fosterlynn commented 7 years ago

Here is an attempt to map the @matslats web service to VF:

A currency ID if you are sharing a ledger (unit on the event)
A payer ID (id of the provider agent on the event)
A payee ID (id of the receiver agent on the event)
An amount, probably stored as an integer and interpreted elsewhere. (numbericValue on the event)
Timestamp for creation. (we don't have that - but could be a good idea)
Transaction workflow state (I think you have this as 'done' or 'pending', not sure how this maps in VF as we haven't done much work on the protocol side)

and then optionally

description, probably just one line is enough. (name on the intent?)
one or many categories, which probably relate to another resource. (categories on the intent)
Timestamp for last edited (we don't have that, but we could)
Transaction type (pertaining to workflow) (not sure what that one is)
Group id, if you want to group transactions together. (not familiar with the use case of grouping tx's)
Comments could be attached, but probably should be a separate resource. (note from the intent and/or event)

and not

Ratings - because we'll never agree on a data format.

:+1: and also because it is a difficult topic; and easy to game;

elf-pavlik commented 7 years ago

A currency ID if you are sharing a ledger (unit on the event)

A payer ID (id of the provider agent on the event)

A payee ID (id of the receiver agent on the event)

Why IDs of agents and not accounts? Does it make assumption that for each currency one agent has one account? agent 1:1 account (per currency)

matslats commented 7 years ago

I was just simplifying

enricostano commented 7 years ago

I don't think GitHub issue comments are the best place to work on a RFC (or any other standard document). I think we should do 2 things:

decide which entity / workflow we want to work on first (time transaction, etc)
someone should open a PR somewhere with a draft so everybody can comment and contribute

EDIT: as an example give a look at https://github.com/rust-lang/rfcs

elf-pavlik commented 7 years ago

Thank your for your suggestion @enricostano W3C also uses https://github.com/w3c/ heavily for writing spec. For a while I think about after we release 0.1 to ask for feedback and contributions to VF on https://www.w3.org/community/economy/

In https://github.com/rdfjs/representation-task-force we just worked together on one Markdown file and as the work gets finalized now we will convert it to common format used by W3C specs - ReSpec.

One of the challenges I see with VF - we work on general model where credit currencies come as special case with mutual credit and timebanking coming as even more specific cases. At the same time I think we took quite a lot of time for the general part and we could collaborate together on RFC / spec more specific to transactions between accounts in timebanks & mutual credit systems. We could start dedicated repository for that and start gathering inputs from existing implementations. With https://www.timeoverflow.org, http://communityforge.net/ and https://hourworld.org we already have 3 implementations (2 opens source and one proprietary). We would just focus in that mini spec on how to describe various variants of mutual credit and timebank (eg. if it keeps sum of all balances 0 or not) and how to represent transactions between accounts and possibly 'credit exchanges' (eg. if we do 'home swap' with someone using https://www.homeexchange.com or sth. can we also swap some mutual currency credits or timebank hours without need to joining it as 'full member') At the same time I think we should keep concerns of 'intent casting' / 'classified ads' and Exchange Protocos separate since for the same offers-requests agents can find matches using mutual credit / timebanks, ISO4217 currencies, Faircoin, Bitcoin, FooBarCoin, direct barter, multi party (network) barter etc. so 'open marketplaces' may stay agnostic to what currencies participants want to involve as options or or only exchange goods and services directly or as part of barter chains.

fosterlynn commented 7 years ago

I don't think GitHub issue comments are the best place to work on a RFC (or any other standard document)

Thanks for the nudge @enricostano . Maybe that would help us get to agreement more quickly. :) Especially at this point where we have discussed a lot of concepts and a lot of use cases.

At the same time I think we took quite a lot of time for the general part and we could collaborate together on RFC / spec more specific to transactions between accounts in timebanks & mutual credit systems.

I would welcome a focused effort on timebanks and mutual credit, as I could use something like that for work starting for the Mutual Aid Network in Madison.

@elf-pavlik 's description of the situation is helpful though, because it is a minimal vocabulary intended to cover a lot of territory - part of the elegance of the model. But at the same time, we have very much appreciated particular use cases as an essential tool to get there.

At the same time I think we should keep concerns of 'intent casting' / 'classified ads' and Exchange Protocos separate since for the same offers-requests agents can find matches using mutual credit / timebanks, ISO4217 currencies, Faircoin, Bitcoin,

I don't know, that is a big part of the flow in a timebank, and many times that is not true, the intent is cast just within the trusted group based on that agreement. It will be just one particularity of Intent.

elf-pavlik commented 7 years ago

I don't know, that is a big part of the flow in a timebank, and many times that is not true, the intent is cast just within the trusted group based on that agreement. It will be just one particularity of Intent.

In some cases people may choose to run tightly coupled together 'marketplace' and timebanking or mutual credit system. In other cases people may choose to have them loosely coupled, in other cases both 'integrations' will coexist together. If we make sure to keep those concerns decoupled, it will allow to combine them in different ways depending requirements of a different use cases. For that reason I suggest to focus just one the operations on accounts as distinct concern, while keeping it composable with other concerns in VF ecosystem (composable but not tightly coupled).

fosterlynn commented 7 years ago

If we make sure to keep those concerns decoupled, it will allow to combine them in different ways depending requirements of a different use cases. For that reason I suggest to focus just one the operations on accounts as distinct concern, while keeping it composable with other concerns in VF ecosystem (composable but not tightly coupled).

Yes, completely agree on not tightly coupling, we can keep that in mind. I would like to see the relationship between the credit moving event and the intent that eventually resulted in that, however.

matslats commented 7 years ago

Please note I've been working on these specific issues since 2008, namely, how to architect general purpose tools for a solidarity economy. I agree with what's being said at the moment:

Mutual credit should be the starting point, and I can show how that works for everything we need.
Separation of accounting and intent-casting, and rejoining at the user- experience level. I guess that's what we mean by loosely coupled Value flows might be a sort of container for the mutual credit system, insofar as you want property represented on the ledger. I haven't really thought that through. Matthew

fosterlynn commented 7 years ago

@matslats thanks!

Value flows might be a sort of container for the mutual credit system, insofar as you want property represented on the ledger.

VF can definitely be a sort of container for the mutual credit system. I am very confident that VF can represent what you have been doing in this domain, although as we have discussed elsewhere, it will be more generalized, and more normalized / less flattened out. There is a mutual credit issue here https://github.com/valueflows/exchange/issues/33 to make sure this happens.

To clarify, in terms of "property", we want to support coordinating the production/creation of things and services, in addition to exchanging them and accounting for them. In other words, the whole (solidarity) economy in a connected ecosystem. So all "resources" that are useful and part of that, we want to represent, as well as their life cycle.

fosterlynn commented 7 years ago

Separation of accounting and intent-casting, and rejoining at the user- experience level. I guess that's what we mean by loosely coupled

Concretely, I picture a data reference from the credit transaction to the intent that eventually led to it. (If it is available, of course.) Then people can tell what the movement of credits was about. So I picture them easily de-couple-able, having their own identity and properties, but also connectable. This gives a lot more information to the community on what it is doing for each other economically, what else might be needed, etc. (This is the direction the MAN in Madison wants to go with this info.)

bhaugen commented 7 years ago

@matslats you wrote upthread:

Mutual credit should be the starting point, and I can show how that works for everything we need.

That would be really interesting. I have read a lot of your mutual credit writings, but have not read anything about how mutual credit would work for production. We touched on that lightly in a conversation with Stephanie of the Mutual Aid Networks, and I have been thinking about whether mutual credit would work for Peerconomy. I mean, if everything in a community economy runs on mutual credit, would that essentially be the same as Peerconomy?

(Hmmm, I should ask @ChristianSi what he thinks about that...)

matslats commented 7 years ago

The link there doesn't say much about what peerconomy is, but there was a slogan on the page, "from exchange to contributions". It made we want to clarify that mutual credit is the accounting of exchange and of sufficiency, and that in advocating for mutual credit systems I'm advocating for a more just economic system than fiat money has created. But exchange is only the next paradigm. the one after that is indeed 'contributions' and of abundance.

bhaugen commented 7 years ago

The link there doesn't say much about what peerconomy is

There's a book: http://peerconomy.org/wiki/Main_Page#The_Book

But don't feel obligated to read it now. I've read it and will go thru it again and write up how I think mutual credit might fit. Or maybe I was dreaming and it won't...

elf-pavlik commented 7 years ago

Separation of accounting and intent-casting, and rejoining at the user- experience level. I guess that's what we mean by loosely coupled

As an example, while some particular mutual credit instance can have some 'default' online marketplace for casting all kinds of intents. At the same time more specific marketplaces, like https://openfoodnetwork.org/ can just configure that mutual credit instance as one of its 'payment processors'. So if someone selects food product offered in exchange for that mutual credit units, OFN instance will allow to make payment using that mutual credit instance. People should have full freedom to what web marketplace services they use to cast their intents and which currencies they can involve in exchanges that fulfill their intents. Of course any web marketplace service can allow/disallow any currency or focus just on some specific category of intents (like OFN - food).

Once we deploy OFN .mx instance I will also connect more with people working on local currencies in and around Mexico City and work with them in enabling those currencies on local OFN instance. Later in the future, food producers and processors can cast intents for work they need help with and in addition to mutual credit, also support barter (food for work) and timebank hours (maybe one day also more peereconomy style arrangements). To compose such deployments with many complementary currencies (and direct barter) I see need of keeping all those currencies loosely coupled and having possibly to deploy them as web services interoperating with other web services (like web marketplaces where people can cast intents and do Conversation for Action)

fosterlynn commented 7 years ago

@elf-pavlik that is also a good point, and maybe where @matslats was going in terms of decoupling, I don't know. Intent-casting is a different function, and could be done across many settings.

matslats commented 7 years ago

If somebody wants to build it, I've written function requirements for a mutual credit REST accounting service here: https://github.com/matslats/groupaccounting/wiki/Functional-Requirements

bhaugen commented 7 years ago

@matslats

If somebody wants to build it, I've written function requirements for a mutual credit REST accounting service

Passed on to the scuttleverse: https://viewer.scuttlebot.io/%25%2F4DahnKDhVioNV4oaDdcUqpPCUYd98eCxsBldlHXEXE%3D.sha256

@cel is working on it: https://git.scuttlebot.io/%25S2HuUuDNIYnmNAK%2FcNmnhSzhrALoeBEXY4BJwOBTz9s%3D.sha256

matslats commented 7 years ago

That does indeed look close, yes. Is it NoSQL and wouldn't that cause performance problems? Are there any restrictions or wierdnesses that come from scuttlebot as a context?

elf-pavlik commented 7 years ago

Is it NoSQL and wouldn't that cause performance problems?

Not sure if I understand why you refer to NoSQL. Whatever persistence solution particular web service uses it should stay as its internal implementation detail. For the Web API only the public interface matters and here I would suggest to pay attention to https://www.w3.org/TR/webarch/

matslats commented 7 years ago

Yes I get that, but I have a use-case here probably much more serious than a favours system between fans of a niche technology. If I want to build a table showing the running balances of 20 users from a log of 10,0000, which, with the data structure proposed means 20 queries of the form

SELECT SUM(amount) FROM table WHERE payer = $user_id - SELECT SUM(amount) FROM table WHERE payee = $user_id is performance a concern?

Or maybe I should regard this project as a prototype?

Maybe its only a couple of days work for him?

Maybe he's not even building it with me in mind?

Matthew

On Sat, Mar 11, 2017, at 12:51 PM, elf Pavlik wrote:

Is it NoSQL and wouldn't that cause performance problems?

Not sure if I understand why you refer to NoSQL. Whatever persistence solution particular web service uses it should stay as its internal implementation detail. For the Web API only the public interface matters and here I would suggest to pay attention to https://www.w3.org/TR/webarch/

bhaugen commented 7 years ago

That does indeed look close, yes.

Will have some logical resemblance anyway.

Is it NoSQL and wouldn't that cause performance problems?

Yes.

Are there any restrictions or wierdnesses that come from scuttlebot as a context?

Yes. More below.

Or maybe I should regard this project as a prototype?

Yes. Actually, more of an experiment.

Maybe its only a couple of days work for him?

I don't know how serious he and the scuttlers are about this.

Maybe he's not even building it with me in mind?

Only partly. Definitely not your large use cases. This gang loves to do experiments. They have been talking a lot about economic relationships, and mutual credit plus your credit commons writings has part part of the conversation (brought in by me), which they like a lot. They also have several worker coops in the scuttleverse.

The sbot "database" is a merkle tree that each node keeps for themselves. It's an append-only log. There is no global/central db, it's all radically decentralized, which is one of their main focuses, along with privacy.

Each node keeps copies of all of the messages they have exchanged with all of the nodes they follow, and all of the messages that all of their followers keep. That's the distributed gossip base.

So for mutual credit, there would be no global shared ledger. Just each node's transactions with other nodes.

They can also have "pubs", which are nodes where many other nodes congregate. The pub would have a log of all transactions among pub members. And they are figuring out how to do groups. So those could be the "community" nodes where a shared ledger could exist.

I hope that all makes sense. I'll ping @cel and see if he wants to say more.

clehner commented 7 years ago

cel from ssb here. i started on that implementation independent of reading the Functional-Requirements document, but informed by the credit commons documents, and some issue threads here. ssb-mutual is intended for use with ssb networks. whether it will be useful in a broader context, aside from API inspiration, i expect will become apparent as we gain experience using it.

@matslats you are right about the performance issue. this can be optimized by implementing a materialized view for balances.

i am also interested in the next paradigm - perhaps i'll give peer-economy a read.

bhaugen commented 7 years ago

@clehner

perhaps i'll give peer-economy a read.

If you do, be aware that the author, @ChristianSi , has been rethinking some of it. Might be worth another thread somewhere. Or invite him into the scuttleverse...?

elf-pavlik commented 7 years ago

If I want to build a table showing the running balances of 20 users from a log of 10,0000, which, with the data structure proposed means 20 queries of the form SELECT SUM(amount) FROM table WHERE *payer* = $user_id - SELECT SUM(amount) FROM table WHERE *payee* = $user_id is performance a concern?

No one stops you from having internal to your service some denormalized structures, indexes, materialized views or whatever you want to do to make optimizations for performance. I think this presentation shared by @ahdinosaur includes some very well thought reflection on such aspects of databases https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/

@clehner :wave: I wonder if you have possibility to implement in your approach, a common requirement where accounts have a limits for negative balance. In many common nowadays deployments, where particular service provides a shared ledger for mutual credit or timebank, this service may reject requests for transfers if they would make an account go below agreed negative limit. Looking at your documentation I understand that balances on all the accounts stay publicly known, so during negotiation of exchange the party that would receive currency transfer can check the current balance on the 'origin' account and reject proposal of exchange if considers the resulting balance after transaction on the origin account to low. But this removal of the authority which stays responsible for ensuring accounts don't go bellow certain limit, seems to move that responsibility on all the participants.

clehner commented 7 years ago

@bhaugen

be aware that the author, @ChristianSi , has been rethinking some of it. Might be worth another thread somewhere. Or invite him into the scuttleverse...?

good to know. do you have any links for this? i feel i should familiarize myself with the existing work before asking for more...

hi @elf-pavlik,

in the current design, there isn't an explicit accept/reject step, but participants could do this negotiation at a higher level - especially if one is considering whether to convert credits in the system to something external to the system.

bhaugen commented 7 years ago

@clehner

do you have any links for this? i feel i should familiarize myself with the existing work before asking for more...

Here's the book: http://peerconomy.org/wiki/Main_Page#The_Book

Here's his website: http://www.siefkes.net/ and collaborative blog: http://keimform.de/ For example: http://keimform.de/2016/eine-welt-in-der-alle/ (use the translator if needed)

almereyda commented 4 years ago

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/forum-valueflo-ws/-/issues/74.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.

valueflows / forum.valueflo.ws

Time bank use cases #74