LocalPay technical options

This document outlines a range of technical options and estimated costs of each.

Technical projects by nature are notoriously hard to cost because by nature each one is breaking new ground and risks are hard to calculate. For projects to work to a predetermined budget, the technical risk must be priced in from the beginning and this takes the form of high salaries for developers to meet specific technical goals. There are many mIf the goals are softer, if some corners can be cut, if some features are considered optional - i.e. included only if the essential things are completed.

The below estimates are based on the cost of hiring developers at commercial rates and writing all the software ourselves. CoopDevs prides itself on executing nonprofit projects at below these types of estimates by identifying developers with intrinsic motivation and putting a lot of time into collaborating with adjacent projects. We have identified many adjacent and potentially adjacent projects, some with developers, some with funding. See this Proposed solution for federated social & economic network(s) for more details.

Who are CoopDevs?

CoopDevs is a team of professional software developers committed to working on local and solidarity economy projects. They currently maintain a network in Spain of over 100 time banks, and manage the software for an international project, Open Food Network, which provides open source platforms for managing logistics and money for veggie box schemes. Like us, CoopDevs are very cautious about using blockchains and tech which is too new because long term impact and project sustainability is more important than wowing their clients. They are currently involved in several projects, including one Horizon2020 project, Platform Labour in Urban Spaces (PLUS).

CoopDevs plan projects of this scale using the following 5 phases

1. Specification - a lot of talking to decide what exactly needs building and how
2. Prototyping - building the core system, perhaps trying different approaches.
3. Development - Building the features and configuration and user interface
4. Pilots - Trying the software with real users, and iterating with their feedback.
5. Migration & Launch - Translating the data from the old system to the new when users are ready.

CoopDevs identify various skills required in different proportions depending on the project.

• Product owners, to ensure the project really serves the organisation.
• System administration, to set up infrastructure, and make it run efficiently
• Backend development, to code all the databases and logic running on the server
• Frontend development, to make the user interface (the mobile app)
• User experience designers, to design the app so that users find it intuitive
• Project management to ensure all the above are in harmony

Technical vision

We are working towards a world in which any local community can set up and own a node on a global alternative economy network. In public they might be a LETS, a time bank, a transition town, a mutual aid network, or a babysitting circle, or book club. Technically they would be just a node, publishing certain types of data object between themselves and sharing with other groups they designate. Some groups would be hosted on machines they own, others would work together to share those costs. Thus members of a group could see say, the posts of its neighbouring groups, and register their interest without having to create an account in a new platform.

This functionality is already familiar to most of us through Facebook, but only for the sharing of simple posts. Recently web standards have been established to make possible the sharing of new types of data, independently of any one platform or social network. We envisage not only news posts, but offers, wants, events and even complementary currency payments going between groups.

A new standard protocol called ActivityPub allows communities using independent web sites to federate around content management. Content is shared with neighbouring communities, who can edited, tagged or answer it according to their permissions. One social network Mastodon was built using ActivityPub and it is growing impressively. To us, starting with the ActivityPub protocol offers two major advantages to community groups:

• they can operate independently AND as part of a network, sharing and interacting around content as needed.
• they can share backend software components while customising their user experience in their own apps

I co-authored this document inviting other social networks considering their future to consider ActivityPub.

This diagram shows how a web server would host all the data and services for a community currency system, making some of it available for reading and writing through various ActivityStreams. Each actitivity stream would serve one function of community. For each activityStream there would be a component which could be easily incorporated into a mobile app. Administrative functions are often provided through a separate app. Data in each activityStream could be shared with any other community implementing these web standard protocols.

Sub projects

We identified and estimated the cost of four technical options to accomplish this in varying degrees. Each options involves a combination of the following seven software projects. This table shows the price of each project, a few details, and the secondary benefits.

Project	Description	Wider benefits
ActivityHub Server 150K	Each ActivityHub would host all the user profiles, authenitcation data, content and logic while allowing sharing with other hubs. It would have many configuration options and features. It would have no user interface but be controlled only through a REST API. It could be built to serve many groups as one, or ideally, one group per instance. Our partners have already started work on this.	This is critical infrastructure. Many kinds of implementation already exist, (the most prominent being mastodon) and we are forking another. Our work here should be widely used by resilient communities.
ActivityHub Provisioning 150K	If we have one ActivityHub per group, there will need to be a provisioning system to manage the creation and updating of large numbers of instances. This involves quite a lot of complexity. These kinds of platforms will be widely needed and the cost could be much reduced if we find somebody else working on this.	If we are the only ones building this, it could be widely useful.
Client 100K	Every software needs a user interface. Modern appliations often have one app for users, and another app for administrators. Each network will want a slightly different UI but they would share a lot of code.	Useful to local currency groups running OUR ActivityHub Server
Holo Client 300K	Every network (or every group) would have its own holo app, and data would be shared between apps using activityPub.	ActivityPub integration would be useful to other holo projects who want different versions or variations of apps to share data.
TimeOverflow 2.0 100K	Timeoverflow, CoopDevs' existing timebanking software's minimal feature set would be expanded to meet the needs of CES and Community Forge, so all four networks would be able to use the same software. The new version would implement activityPub to enable content federation between instances. A new REST API would be needed to enable the application to run headlessly, i.e. independently of the front end.	ActivityPub integration would be useful to other holo projects who want different versions or variations of apps to share data.
Network services 100K	While ActivityPub enables asscociated groups to federate content, we want to provide two services at the global level, enabling member-to-member interaction regardless of relationships between their respective groups. First would be a global marketplace for the solidarity which could be filtered by location, keywords, and preferred means of payment. Second would be a payment system between groups, meaning a global complementary currency payments network. (Both are already prototyped; funding could be sought seperately)	Our hopes for impact reside here, where all the groups interact and become greater than the sum of their parts.
Migration 50K	Each networks stores its data in its own format and will need a separate migration process into the new system. There will be efficiencies from doing these processes all together.	Some benefits if/when other local currency networks decide to use our ActivityHub / Holo App

Four approaches

Shared hosting The shared hosting option is similar to how CES and all the timebanking platforms currently work. The network provider runs the application on their server offers the sofware 'as a service'. This means all groups' data is stored together, typically in the same database. It means groups have very little freedom to configure, alter, hack or skin their software but all alterations must be done by the network provider at a time and cost of their convenience. Any group seeking autonomy must become a network provider for themselves which is difficult.	1. Piggybacking Timeoverflow EUR300K would enable sharing of costs henceforth, but do very little for other networks or to shape the future. Time Overflow 2.0 + Network services + Client + Migration
	2. Shared ActivityHub EUR350K - Each network would have one software instance which would be built to serve many similar groups. Networks would be connected using ActivityPub but groups would have very little control. ActivityHub Server + Network services + Client + Migration
Decentralisation Full decentralisation means that any group could set up its own hub, maintain its own data while still participating fully in the network. This is expensive because it entails not only packaging the hubs to make them easy to install, but also publishing and testing updates to the hubs, and doing version control and ensuring backward compatibility. Community Forge offers full dencenralisation using Drupal's provisioning platform Aegir, to give a Drupal instance to every group.	3. Decentralised ActivityHub EUR500K - For full independence each group should host (or choose where to host) its own data, and who to share it with. However this requires building and maintaining a provisioning platform, which is a software project in its own right. ActivityHub Server + ActivityHub Provisioning + Network services + Client + Migration
	4. Holo EUR400K requires writing less software because there is no server side, and no API to communicate between clients and servers. Every instance of the app runs exactly the same code and stores a shard of each group's data. The drawback of Holo is that it is a very new technology and so entails the technical risks of not working, political failure of the project, not being widely adopted. And the Holo coders could be more expensive than other developers. holo Client + Network services + Migration
Stopgap	5. CES to CoopDevs platform EUR100K is the cheapest possible option that would be meaningful. Coopdev's platform would be upgraded to include numerous CES features and 100 active CES and CES Australia sites would be migrated over. This would buy time because the CES platform is obselete is would reduce migration costs for future developments.