Yesterday, our second-to-last “big” feature addition got online (last will be a “buy-now” option). So now we have a way to support your favourite open source, commons-oriented, open hardware and other beneficial but non-commercial projects, with moneyless donations.
To check it out: Log in on makerfox.com, then go to “Transfer -> Send Value” and click “Support: + New”. You can find a form for regular moneyless support payments to one or several recipients. Recipients are other users on the Makerfox platform. Entering multiple at once (like your group of favourite open hardware projects) is preferred, as then the algorithm can decide who gets what part of the support. This helps the algorithm to catalyse more network barter deals, and also results in yourself getting more deals. Your support payments are executed as parts of regular network barter deals that include products and services – for example, when you have to give stuff for 30 EUR away in a deal, while getting stuff for 60 EUR, the 30 EUR “profit” would come from receiving payments (donations or “regular” moneyless payments). For sending donations / payments, the numbers would be the other way round. Makes sense?
'Nough said We should now care about publicity rather than tech, and I guess the “donations” feature can help with that. Because creating a support payment does not need a critical mass of users; executing it does of course, but potential beneficiary projects might like to join before that already. Making this a moneyless gittip.com for the open source economy
@Ben and @elf Pavlik, the unMonastery could profit from such moneyless support for example. Edgeryders itself could also get some donations, and can spend them in the community again for Drupal development etc… Should we get us a Makerfox account, Edgeryders-the-Company?
I love this! Will try to figure it out a bit more and promote it! Maybe something to discus at the Spot the Future event as well? This needs to get a lot of attention!
Thanks a lot, Inge – attention is exactly what the Makerfox needs right now. And better explanations about how it works – so if stuff stays unclear, feel free to give me some feedback and we’ll know how to explain concept and features better. @Noemi told me people were interested in the Makerfox idea during the last workshop in Tbilisi already, so yes, I’m up for presenting it at the futurespotters June conference.
Will register a session proposal. We can do a live demo where the Makerfox finds a network barter deal, but users have to create offers in a way so that they include a deal. (Later that should happen often enough by pure chance of course, but it needs a critical mass of users, and even then more than the time of a session.)
Interoperability is about standards development. Remember how long it took mechanical engineering until the development of the universal ISO thread standard, and all the different solutions they had before? Same with e-mail. It takes time, and happens after a phase of exploration. The (mainstream) Internet spent the last 20 years with exploration, and it’s good to see that you and others promote standards actively now …not to say aggressively
In the case of Makerfox however, we’re still well in the phase of exploration (in a space of 648 proposed features … not kidding). So far nobody knows how to do network barter right, not even in a silo, much less in a decentralized system. We currently care for getting it right on one platform. Getting it right as a decentralized system has some hard tech problems for later: for example, we can’t simply agree on a data format for asset sharing – barter trades are made fully automatically, so if we want to grant that capability to any party in a decentralized network, we need to develop a distributed database with distributed atomic transactions to avoid selling / buying the same thing twice. That’s well beyond our capacity for now.
So, sorry but we have to postpone the standards development for now. At this time, other work on network barter creates more benefit; because from the view of both a platform and users, a standard that has zero adoption has zero benefit compared to a silo. And that’s where a standard starts. Compare Mozilla Persona: for most users, at this time, only one of their websites offers Persona login. I still like Persona, and we support it with edgeryders.eu, but you get the point: investing in interoperability is an investment for a platform that may pay off some time in the future, but not immediately. And for investments, you need the resources to invest …
But I agree that we could start with something simple into the direction you propose: product and service offer imports and exports in and from the silo using an open catalogue data standard. Maybe you know what would be the most adequate existing standard for this?
P.S. re. source code: As promised, we’ll release the core part (network barter algorithm) as free software. But give us a little headstart before the open source release – I’ve been competed out of business by big capital before (Amazon and eBay getting into “our” electronics remanufacturing market). Don’t want that experience again
I don’ say that in few weeks we will solve all the challenges, still even by small involvement you can try to keep aligning you stack step by step
By adopting common vocabulary to express listings, I would aim at GoodRelations + Web Payments you can make it easier for people to expose their assets through your system.
I also don’t talk about fully distributed P2P system! Makerfox could offer network barter service and other services could offer various other variants.
First rough idea that comes to my mind for finalizing transactions: once your algorithm finds chains, it sends request to all the parties, first chain for which all the requests return responses with ‘locked until: timestamp’ goes to next step and needs in let’s say (to keep it simpler in the begging) make sure to confirm transactions again within that locked time. We could start with long time like 60s and based on real world usage fine tune it to accommodate for all the network delays!
Do you feel comfortable with asynchronous programs? In javascript libraries like async come of great help and promises landed in ES6 \o/