I don’t know yet, I think I need to spend some time experimenting with these things before I can give you a proper answer:
The draft diagram is so far just a proposal of how we could imagine the systems would come together, in a way that makes for the users and based on the existing tools and plugins. But as @chris says, there is a lot to be tested first and then we’ll adjust the diagram most likely. But maybe it can serve us for now to give us a desirable architecture we could work towards. No concrete milestones committed yet 
The diagram now includes also a “Private Greenlight” server connecting to one of the node’s loadbalancers.
Yesterday we discussed to have different Greenlight instances for
I have tried to depict that in the updated diagram:
One addition thing that we might want is a “small organisation” container – setting the length of meeting and maximum number of people in meeting can only be set at a Greenlight container level, not a user account level, see the suggested service levels wiki page I created this morning to reflect this.
I understand that now, with the code of ColloCall, we’re able to set the environment variables of a Greenlight container to define, for the whole container three key variables: max #participants, #rooms per host and #duration of a session. That’s a great step forward as these are key variables to define service levels and share somehow the costs of running the services. Good for now. But what if these variables could be set on a user role level inside Greenlight? That way with one instance we could run users with various service levels inside the same container and thus enable them to share rooms more easily, and on the same domain name. Ultimately that could lead to a simpler and better user experience.
I’d imagine this process:
Maybe it would be good to study the discussions inside the the BBB community for this purpose and see how much effort it would cost to enhance Greenlight for this purpose? When we can obtain funds for developing this, wouldn’t it be a valuable contribution?
We can’t currently do this so I think we are going to have to set these variables high for almost all the containers as organisations are not going to generally want to have more than one container, in fact to start with (for the whole of the Alpha stage), we might not want to set any prices and simply charge different organisations based on their size, the type of organisation, wealth of the organisation, an estimate of possible usage and level of non-financial contribution from the organisation. We also need to be aware that if we want to raise funds for things like our own hardware we are going to need to bring in a lot of money.
Seems to me, the capacity to configure kinds of rooms at member-organisation level is fundamental, with different fair-use arrangements assigned to each kind of room. Any member organisation (coop or movement organisation) would need to have a room admin (aka meet.coop Greenlight account admin) with the skills and privileges to configure greenlight containers for the organisation.
This would be a key role in the working ecology of meet.coop, which we would need to support well with a dedicated circle. Contrary to what @chris suggested, I think the capacity to configure a bundle of room types at member-organisation level (under fair use obligations) would be a big selling point. For example, circle rooms (ateliers) for ongoing collaboration under frequent use by seven or so people, town squares for random gathering with straw polls, confluence rooms (cameras-off conferences plus cameras-on breakouts), personal rooms (up to seven in a room for 2 hours).
Account pricing would be according to how many circles/room bundles/room types were ‘licensed’ in the fair-use agreement for Greenlight containers that is signed with each member organisation. It’s clear though, as @chris has noted, that in the first phase of meet.coop operation, some macro pricing scheme based roughly on member size might have to be used. Even so, it should approximate to the room-bundle use cases above (maybe three categories - single-circle org up to 50 personal rooms, multi-circle org, own-server org?) No personal accounts issued directly by meet.coop, Only org membership. Personal accounts may be offered by member organisations, under fair use.
Greenlight is by no means up to this kind of admin at present, but needs to be. It’s good to hear that Collocall has made steps in this direction.
Greenlight also needs to be given capacity to monitor, at least, the allocation of room capacity at account level (aka room admin level), and really, to monitor usage too, to enable fair use to be well managed, and to collect stats for profiling the activity of the meet.coop user community - . essential, so that the entire community can get a view of how the infrastructure is being mobilised, as a commons
I would say that, soon, we need to be approaching the Greenlight code community on this matter of forking the front end. It could be hacked in a weekend hackathon, if the will was there? What d’you think @hng ? Is it harder than that? Are there obstacles in the BBB api, for example?
If Greenlight isn’t up to this, we need to be thinking about another front end? Usability by member organisations to organise their own workspace is the pivotal thing?
I would suggest that it would be potentially weeks if not months of work by experienced developers, of which we have none — sorry but we do not have the resources for this, we don’t even have the resources to pay ourselves anything for the work we are doing at the moment.
Fair enough, on both counts @chris yes . . especially, absolutely, regarding repayment for all the work that has been ploughed in to date. 
If that’s what it takes to get a proper front end that serves organisations’ needs, then there’s serious P2P code organising/lobbying to be done in the Greenlight community, and probably serious fundraising to be done (crowdfunding, maybe?). But developing users’ capacity to manage room bundles is a pivotal thing? For users, the rooms are the reality of the system. they live there.
In the long run, surely meet.coop is not just reselling server bandwidth under fair use? We’re eventually offering well-adapted means of organising for coops and movement organisations. What they need is digital rooms equipped for purposes of diverse kinds, with appropriate tools, so they can inhabit them, and do work in them? For them, the front end is everything?
This is a short-term strategy consideration for a room admin circle? To be formed soon - before Alpha launch of the service.
I note that there are major front-end issues regarding account admin and Greenlight containers in the Marketing thread Marketing Meet.coop.
Being constrained by what Greenlight will and won’t do is a critical issue, and it seems some working compromise is going to be needed, short-term. Finding the balance on this calls for a joint heads-down by the contribution accounting circle (eg @chris @wouter @osb ) and the operations circle (eg @chris @hng Koumbit etc) - which as-yet haven’t been constituted. This immediate compromise (and longer-term intentions) needs resolving asap? This will not resolve in the weekly all-in open video forum, without detailed prep, it’s too tech, and the Marketing thread is already too complex to easily follow.
Let’s kick in with executive action in circles asap? An ‘organise in circles’ decision is urgent business for Thursday? With preparatory/pre-emptive work in the above named circles before Thursday?
There isn’t anything to resolve @mikemh, all we have the are tools we have, we are not in a position to change them at the moment so all we can do is use them as they are or not use them.
Let’s make sure we distinguish clearly between what we can and fins desirable to do NOW and what constitutes our WISHLIST of how we’d like to be working and offering our services. For the NOW we can do a sprint with the limited resources in time and software that we have (which is already a lot really) and at the same time we go find the means to work towards fulfilling our wishes.
That may involve 1) early movement building with likeminded actors who have already certain awareness of privacy and the need for cooperative platforms and are willing to do a little extra effort compared to the big data exploiting oligarchs like google and zoom, 2) seek grants from funds around privacy and cooperative commons development, 3) develop plans for collective financing of the cooperative entity and server infrastructure that we need.
If we want to get somewhere collectively, we cannot forget the NOW, and here’s where I think the ideas of executive circles might be good to define further - I understand that it relates to responsibilities and also to economic compensations, and rules for inclusion / exclusion shall be defined, a little task in its own. @mikemh have you developed this idea somewhere or care to define it in a wiki page?
Of course we can also not forget the mid- and long-term vision to realise our shared wishlist, but we should at least keep these two levels separated to not confuse ourselves or new people reading up on this. How do we organise that best?
I understand @chris. What needs resolving, in my perception, is not sysadmin tools stuff (yes, we have the Greenlight that we have) but account-admin practical stuff . .
. . within (short-term) admin limitations of existing tools? Currently this seems to me to be very unclear, in need of urgent resolving.
I don’t see a form of practice yet emerging, that will underpin a public launch of a service (and a development project) that looks coherent and interesting to a would-be member organisation already participating in Zoom.
If you believe there’s a current post in a thread that defines an adequate working method, for the Alpha phase of membership registrations, do please highlight the link Chris? It would be a relief to discover I’m mistaken.
As I have said before we need to delegate the admin of each Greenlight container to a member organisation, this is the only simple and straightforward solution I can think of for the short term.
@wouter I’ll post a slide deck in the next hour, containing maps/prompts on executive circles, membership classes, contribution accounting, voting rights.
Uh huh . . so, is this three member organisations (Webarchitects, femProComuns, collective.tools) with three locally administered Greenlight containers, offering just one kind of plain-vanilla room deal? Or with possible variation of room deals, across the three coops? One price fits all, or different levels of pricing for ‘the same’ plain-vanilla, fair-use deal, from any Greenlight admin? Centralised, one-stop-shop, member registration and account/Greenlight setup, or the original idea that intending members would be able get just one (equivalent?) room, from any of the three founder coops?
The original three-coop shopfront looks to me - and to @osb I think - like a complete maze as a registration approach, of no appeal to any but the most enthusiastic, early-adopter, principled supporters of platform cooperativism. Do we not have an alternative to that?
In that case it would call, I think, for a very low-key, small community launch of the Alpha phase, which basically would constitute a prototype to be replaced eventually by a model suited for large-scale membership. And with a whole bunch of fundraising and freecode hacker enlistment in parallel, to develop a more adequate account admin front end, before going large.
There are more than the three founding member organisations involved now and I’d simply leave it up to the organisations in question regarding how many Greenlight containers they need for their own organisation and their clients and how they are configured and how they raise money to pay for them.
We have no way of automating the setting up or removal of Greenlight accounts so this isn’t something we can do in a way that can scale, all we can do is manually manage this process and to make management simple I’m suggesting that the organisation responsible for each Greenlight container should be the organisation responsible for the management of the accounts.
We’re already scoping out client needs for re-selling meet.coop services through Autonomic Co-op and would easily be ready to start marketing this, managing accounts and rolling our own greenlight container all from Autonomic side! This seems like the only logical move we can make right now and I think it would be fine. It would really be great if we could prioritise and close off what is blocking us from getting this step done this week.
I agree and I’m afraid that I haven’t been able to make the progress I hoped to be able to make in the last 10 or so days, in terms of the updates to the Ansible role to enable multiple Greelight containers to be run, this is in part because I have spent a fair amount of time discussing governance and what we can and cannot do with the software we have at hand, however I’m getting there…
One thing we will need to make a decison on is the existing accounts, I suggest I should try to retain them on demo.meet.coop and start again with all new Greenlight containers on ca.meet.coop, as I don’t think anyone is in control of accounts on this server? Or have I got that wrong?
[@chris ] up to the organisations in question regarding how many Greenlight containers they need for their own organisation and their clients and how they are configured and how they raise money to pay for them
Goodness, this is pragmatic and no mistake! Not so much a coop of coops, or a federation, but an un-federation, under a minimal server-sharing protocol. It’s not that I have a problem with a sysadmin-led way forward (well, i fact I do) but that if meet.coop is ever to become a coop under multi-stakeholder governance, or even a commons of digital means, driven by use-situations in the commons-coop economy, such a fragmentary financial and operational start is likely to be an obstacle.
I think that then, the launch could only be seen as a prototype of an organisation (Plan A), which might lead to a proper, user-oriented version (of system, and of organisation) only after achieving some serious development of front-end capability for managing containers. There is a real bootstrapping problem here. Yes, some revenue does have to be brought in thro selling something soon. But I think we need to start also thinking crowdfunding for front-end development, and a properly specified, use-oriented Greenlight, as an urgent Plan B.
[@decentral1se ] prioritise and close off what is blocking us from getting this step done this week [launching marketing from Autonomic Coop]
I get that, and wouldn’t want to stand in the way of that practical step. I recognise that something has to be sold, soon, to pay back sysadmin labour. And that Webarchitects and Autonomic (Koumbit and Hypha too?) have no problem with that plan, which seems ‘the only logical move’. But I don’t think this amounts to “re-selling meet.coop services”. Rather it looks like a way of not constituting any meet.coop service at all, other than the reselling of bandwidth on the server that meet.coop, the multi-stakeholder, user-oriented organisation, might have been be developed on.
If that is meet.coop, July2020, then governance is simple enough, I think: an informal federation or a coop, of sysadmin producer coops, re-selling bandwidth in room-sized pieces to passive customers.
(Genuinely) good luck to Plan A. Time to start parallel Plan B.