Your help in identifying existing solutions to some of these problems, identifying flaws in them, as well as potential attack vectors, and suggest improvements will greatly speed up the design of a working protocol. That will in turn accelerate the bootstrap of the SAFE Pod network. The draft is in the public domain (CC0) and there is no intent to monetize it other than implement it in practice.
Are you looking to build a new protocol from scratch or reuse open source solutions that already exist?
Or simply use one of existing OSS platforms?
In the draft I see “based on existing technologies”, but I don’t understand whether you want to adopt those to MaidSafe, or just pick one and have MaidSafe algos provide some inputs that go impact or determine certain parameters in decision making of those pods.
Pods can get listed on any existing Bitcoin 2.0 platform and distribute fees based on however they want to organize themselves in each particular case. They could also release a different token based on each activity so that one pod member can have more “shares” in one activity that the pod does and less or none in another that’s of no interest to him.
Those platforms already have decentralized exchanges that function on various blockchains, so stakes can be bought and sold as well as issued and bought back (by the issuer, to wind or scale down (by buying a % less than 100) activities around particular project (asset)…
I am looking for the simplest and fastest available solution to make the pods self-funding in the short term. Once the SAFE network is operational, some or all operations of the protocol could be migrated to it.
I want to avoid any kind of shares-based mechanism because the regulation around emitting shares is quite complicated. I am looking for a solution in which when a transaction occurs, some percentage of the transaction amount (ex: 5%) is routed directly between the transaction sender and some of the participating organizations or individuals in a way that will spread fairly the amounts of all the transaction fees amongst all participants of the redistribution set.
It might require a new protocol design if no existing protocol is sufficient, although the implementation could probably reuse many parts of existing systems.
I am not talking about the SAFE network operation, I am talking about transaction fees made on business operations done by related businesses operated by SAFE pod members outside of the SAFE network.
In that world, you are already paying transaction fees to all intermediaries (payment processors, good and services taxes, etc.).
@hamiltino: I recon though that the title of the post could lead to confusion so I added ‘Business’ to it. Thanks for mentioning it though, I was so focused on regular business transactions that I forgot that there was ambiguity on the term in the context of the SAFE network itself.
You did say subset and voluntary but it sounds like a tax, HOA, Melloroose, it doesnt sound voluntary
and sounds almost like it could convert project SAFE into a subcription service with debt and penalty fees, guilt. Voluntary right?
I meant shares as in “percentage stakes in a pod or pod-based project”, not stocks.
So far none of numerous crowdsourcing projects (except an odd Ponzi scam) have been challenged by the authorities.
This transaction - is it a transaction on the MaidSafe network (a general transaction) or SAFE coins incoming to a particular address?
If it’s the former, then it becomes a problem of incentive (to use a less negative example: why would they let more people join - although that can increase their revenue - when it has almost no impact on the size of the worldwide cake?)
If it’s the latter and there’s no mechanism for staking (“shares”), then you can’t include (or have to exclude) a part time participant because everything else being equal, he can’t put as much effort as his clone could if he was a full time contributor.
And how do you change percentages of participants whose circumstances change and who have to retire - or want to join - a project?
Sometimes it’s possible to measure one’s contribution, but many times it’s not. Stakes allow voting and through various mechanisms (e.g. issuance, buyback) it is possible to run things in a fair and transparent way.
On the simplest level you could personally run a script that would query for the amount of transactions that you’re interested in and make payouts to a set of participant addresses supplied by each pod. But that would be crude and labor intensive.
It is outside the inner workings of the SAFE network. Think of this as a global and decentralized business agreement between SAFE developer Pods that offer services paid with regular payment channels. Every Pod (or even Pod participants) would be free to participate or not.
If they do not participate they do not obtain money from the redistribution mechanism, and they are free to operate in a different way.
I was thinking of Bitcoin transactions or credit card charges. I guess it could be implemented on the SAFE network payment infrastructure.
The set of participants that participate in the redistribution of fees is collectively agreed by participants and may include anywhere from one participant (usual business model), to a subset of participants (set of all SAFE Developer Pods), or all participants (I’ve never seen this already). The process for joining the redistribution set is yet to be determined and could be progressive, depending on proven value added to the network by a participant.
It would be possible for the participant in the redistribution set to be elected by other participants and be responsible for local handling of contributions and reward. For example, the legal entity of the Montreal SAFE Pod could receive the funds and @francis and @erick could both decide how to allocate the fund. If participants, in the redistribution set or not thought we did a bad job, that could kick the Montreal SAFE Pod out of the redistribution set. Or we could handle the matter internally.
The general principle is that there is provision for a granularity at which humans intervene in the scheme to add flexibility if required, while encouraging a global collaboration.
There’s some PR value in that, but until that’s ready how would people get paid?
If the flexibility and PR value are important, then manual processing would be better while a SAFE-based system is being developed.
Decentralized project-based crypto-assets (CANEDU, CANENG, CANSUP) could make it much more easier to accept and dispense cryptocurrency payments and such systems are needed anyway (according to many who argue there’s a need for a decentralized exchange where SAFE can be bought and sold for BTC).
I’m thinking that having an elegant user-friendly system for doing this would be worthwhile, particularly if we can break it into modular parts.
So say we have a business model, one of the seven high-lighted by @erick above.
That business model generates an “invoice” which is electronically readable and the same, no matter what the specific use-case is. So there would be a module which would need to deal with generating invoices based on a set of rules. For example in the decentralized education model that @erick and I discussed, people pay for a certain amount of time in a webchat. Right now this can be accomplished by a simple method where people pay ahead of time to get on a calendar. If we could set up a system, where a WebRTC implementation would evaluate the quality of the connection and generate micropayments using cryptocurrency whether minute by minute or second by second, this would greatly reduce the need for trust in the relationship.
So once the invoice is generated, money leaves the buyer’s account and goes into an escrow account, which can be distributed according to another set of rules, so we can agree that certain persons get a certain percentage.
If I want to do this right now, I can’t without a great degree of specialized knowledge. So I think this would really add value.
Canada Education, Canada Engineering, Canada Support - just random examples of activity-based teams in a given “pod”.
Sounds good, but that’s a lot of non-core (unrelated to the main product/service) development for a simple payroll feature. Of course it is necessary, but for a smaller organization it’s sometimes better to outsource non-core things until core product/service is built.
Isn’t that precisely what we are talking about? Creating a protocol so that smaller organizations or individuals don’t have to invest disproportionate amounts of resources on these functions?
This begs a question, what is a POD? Is a POD an organization? If so, what type of organization is it? It can’t be a corporation (including a non-profit) because its not registered with the government. Is it a partnership? Anyone thinking about this should be very very careful, because in many countries, rules about civil liability flow from the type of organization you have.
If you have one legal entity or person who holds the money and has a contractual duty to transfer that money to other people, that also raises all sorts of complicated legal issues.
When you consider all these things an automated escrow starts looking really good.
The underlying viewpoint behind the proposal is that we should not view each POD or business created by POD developers as individual units but as part of a larger ecosystem of complementary organizations that pool resources while being as decentralized as possible. The redistribution of money would allow some developers to address “non-core” issues by creating an open source implementation of the service that everybody can leverage at minimal or no cost.