@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.
Definitely agree with the importance of documentation to try and make efforts replicable; Autonomic is hoping to do more in this area as time allows.
Tech-wise, we tried and gave up with Ansible for app deployment. To add to our brief notes about our rationale in the Co-op Cloud FAQ, we found Ansible fragile as a front-end (several of us ended up in very cursed situations with our local Ansible set-ups, which were huge time-sinks to resolve), and found playbooks difficult to reuse between deployments, especially those coming from other groups.
I’ll also repeat here some comments from an e-mail thread about single sign on, which does seem like a key part of the puzzle tech-wise:
To explain: a key part of the idea behind cooperative.computer is that SSO-linked open source platforms are better than “everything apps”, even open source ones, because it lets app developers play to their strengths, and gives administrators freedom to experiment in choosing between them. We also see SSO as a killer feature vs proprietary systems which, if they support SSO at all, usually hide it behind an “enterprise” pricing tier, see https://sso.tax. So we’ve ruled out several great pieces of tech (notably Cryptpad, and email) unless and until they support OAuth or SAML.
We’ve started to explore the inter-group federation possibilities – git.coopcloud.tech supports (as well as some convenience corporate providers) logins with Autonomic’s Keycloak, and Local-IT’s (a Co-op Cloud federation member organisation) Authentik.
