Infrastructuring of tools platforms thro coop-to-coop federating was surfaced as a strategic topic in the meet. coop Board 27april : Evolution 1 - Find a new home - #44 by mikemh. The purpose of this thread is to assemble a session of commons.hour where this issue can be explored.
In a sense, migrating our BBB platform provision into WebTV is a move of coop-to-coop federating (based on their greater hosting and sysadmin capacity). It’s not clear whether a more extended mode of federating than this can be realistically supported by meet. coop in the future - for example, multiple regional servers, servers with plural languages, servers supporting specific municipalist-coop-solidarity economies, etc. So this is a good time to explore what might and might not be attempted through federating of coops in the field of digital infrastructure.
The Board of Stewards feels this needs initial assessment during May, preparing for a review of meet. coop mission and vision as we enter the relationship with WebTV. A time poll for a session is here: [Framadate]. Please do sign up with dates.
Please include your name below if you wish to contribute and/or be notified, edit one of the wiki lists to help frame the discussion topics, and/or comment in the thread. Thanks.
@jamie /@Jaime @ May First Movement Technology (mayFirst regards security and privacy as militating against hosting distributed across separate organisations?)
What dimensions are there, for possible federated relationships?
A Provisioning servers (bare metal) - server rental
B Provisioning servers (virtual machines) - server rental
C Provisioning sysadmin media & tools (scripts, package mounting tools, etc) - admin toolkits
D Provisioning ready-to-mount software packages (containers etc) - repositories
E Pooling sysadmin labour (work hours)
F Provisioning a full ‘back-end’ (A, B, C, E above) - Full hosting service for tools
G Mix-&-match provision of tools to coop members, across differing toolstacks hosted by different hosts - platform-to-platform federation (for example, BBB in one toolstack, Jitsi in another, maybe Talk in another (NextCloud) toolstack)
share installation scripts like ansible internationally (like https://coopcloud.tech/ but more production ready ansible scripts) (C & D)
share sysadmin and servers on a continent(?) level (gets complicated in the EU if you have servers in other places) (A, B, E)
support, training, sales and some code customisations and plugins done locally/nationally
Don’t know if this is applies to the rest of you… but the issue for us is that we provide Nextcloud to organisations and Decidim to cities (and would like to provide BBB), and we do quite a lot of trainings, workshops, customisations etc, but really only use a few hours per month for sysadmin. A lot of the work we put into updating ansible scripts seems like it could be coordinated with other coops, while it’s a good thing to be able to do the training and support locally (and in swedish for our swedish customers).
For BBB our ideal scenario would be to be able to customise the frontend (things like integration with Nextcloud, getting rid of the echo test etc…), do trainings and sell this for our local context , but have shared responsibility for backend, servers and sysadmin.
Yes you did an amazing job with that @chris ! Maybe it’s time to go back to parts of that original plan… at least it would be great if we could find a way to maintain updated and open ansible repos.
@dvdjaco@Yurko What’s the relationship between the present admin toolkit and the Ansible toolkit of early days? Is it an extension, or is it a distinct set of different tools?
Either way, what’s the prospects of an open toolkit as @petter is advocating ? Within the timeframe of migrating server ops to WebTV - before mid June, say?
@gcotnoir what tools admin regime are you in, at WebTV? What requirements would you specify for a working toolkit? D’you in fact have all your tools in place already? Guess so - you host BBB! So, how dyou feel about tool sharing, in the fashion @petter is outlining?
Noting this for future discussion (commons.hour). Local customising of ‘the front end of the back end’ - integration, echo test, greenlight UI and account admin tools, etc - does seem like a requirement. So the Q is, how to federate the skill required to do mods of such kinds?
Just a note - Regarding 'the front end of the back end’ above - the front end of the coop - as distinct from the software stack - is not code or an API. It’s the relationship between the coop and its user members. This is implemented thro various media spaces. Email, website, forum, FAQs, some videos , etc. In other words, the membership relations role, and its toolkit.
Should also point out that the biggest “changes” where made to the “frontend” (green light) that was based on ColloCall’s stack that we got open sourced.
These were things like Downloadable videos and support for RTMP broadcasting (with special deployments) and SSO. Backend for the most part was fairly untouched.
The commons.hour discussion identified a few practical steps that might be taken as meet. coop migrates into an operational rtelationship with WebTV. See notes Nextcloud.
It might be seen as a federating ecosystem with four basic functional areas: back-end tech, front-end membership, front-end community-facing stewardship, community outreach/research/education). Slide here: Nextcloud full slide deck here: Nextcloud . The tech back-end isn’t rocket science: exchanging services, agreeing standard deployment, etc. The front-end org stuff is probably more challenging. @evolution to work on this.
Summary:
Determine whether meet.coop members subscribing to BBB service can get access to other tools provisioned by WebTV (e.g. nextcloud toolstack). How to enable this: financially (layered subscriptions, an additional service level bundle?), administratively (SSO?). @gcotnoir@evolution
David @dvdjaco : draft a framework agreement for exchanging (tech?) services between coops.
Make sure that operational agreements in meet. coop v2.0 (aka contribution economy) are explicit and available in a ‘book’. @evolution
Include documentation for: how to make agreements (provide templates for agreements? agree protocols for making agreements?).
Create ‘a playbook for how to collaborate’? For example: How to go from 'we have spare resources in this location, which we would be glad to share across regions’ to 'we are a working operational part of the federation’?
meet. coop handbook is intended as ‘a playbook for collaborating’ Handbook evolves - moves into Outline. Not fully available for use yet but a sample is here, on principles for meet. coop . The handbook is where operational protocols for meet. coop v2.0 should be logged/shared. @mikemh@wouter This is a continuation of a function of the meet. coop Org circle.
@osb where are you at with OpenCoop toolstack/platform projects (with @petter ?), and these kinds of federation moves?
@flancian of social. coop was in the discussion @mnoyes . Also @ivan of Bonfire. Autonomic (and specifically Coop Cloud) was mentioned more than once @3wc . @bhaugen Mikorizal/valueflo.ws will have a take on this, yes? All welcome in this thread
@dvdjaco@Yurko Can we write a page for the handbook, that points to the location of shared sysadmin resources (as in Yurko’s link above)? Ping me in Element/Matrix for read-write access to the handbook.
