Systems architecture

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:

  1. user signs up, confirms a contribution related to a certain service level, and gets immediate access as a “free” user
  2. the user onboarding team (possibly decentralised through different collectives) validates the account, and the user account gets upgraded to the desired service level
    Note that the users in the this process can all get access to the same domain name, where they can create and share rooms between each other. This is a powerful feature that in the current service level proposal we can’t really use (yet).

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 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, 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 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, 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 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.

1 Like

Fair enough, on both counts @chris yes . . especially, absolutely, regarding repayment for all the work that has been ploughed in to date. :+1: :+1:

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 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

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 . .

  • how accounts will be set up
  • how/who will perform (and be paid for) account admin/members registration/enquiries
  • how initial contaners will be managed (will it be centralised or to some degree decentralised across coops - founder coops?)
  • what the future implications are for recreating containers under more distributed management
  • what kinds of account types can be offered to incoming members - one container fits all?
  • what pricing to place on these?

. . 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, 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 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.

1 Like

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 and start again with all new Greenlight containers on, 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 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 services”. Rather it looks like a way of not constituting any service at all, other than the reselling of bandwidth on the server that, the multi-stakeholder, user-oriented organisation, might have been be developed on.

If that is, 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.

I’d rather you didn’t dichotmise the ideas being proposed here based on the role of the one proposing it. Also, positing the ideas proposed here as an obstacle seems upside down since we’re responding to the actual obstacle of next to nothing resources and a set of tools which don’t quite fit.

I realise that this curt comment might make it seem like I don’t appreciate the work and planning that is happening on governance. I apologise for that. To re-phrase, this seems like the most viable plan for bringing in money quickly based on the technical limitations we now understand. I don’t see this plan of action in opposition to the wider goals of being multi-stakeholder.

This isn’t just about sharing bandwidth, although a lot of bandwidth is essential for the service to work, the reason that the three founding co-ops came together to create this project was because we didn’t have the resources to provide a co-operative video conferencing system on our own, we were then joined by other who also contributed resources such as time and money — without this co-operation we couldn’t have got to where we are now.

This is spot on and it is also exactly what Webarchitects and no doubt lots of other small co-ops and other small organisations providing services using Free software tools have to work with all the time (if they are not working for rich organisations) — we have no capital, we earn just enough to stay afloat by working very long hours and we wish we could could produce software with all the features you would like to see but these things take a lot of skills and time and if we are not in a position to do it ourselves then money is needed to pay others to do the work and as I have said before we have no money… So we are just doing what we can with the small amount of resources we have, what else can we do?


I didn’t see it as curt @decentral1se , thanks for your comment. I can see how things look from the server resources standpoint, and as @chris has just pointed out, there is server/bandwidth resource available now that wasn’t, before the federated strategy was adopted. So a real step forward.

Also can see that from the pragmatic standpoint of now running something on that resource that is revenue earning, there may only seem to be “one logical way forward” given the inadequacy of the front end for any more complex social and economic plan. So I didn’t mean to be snarky or polarising when I wrote of a sysadmin view. I think its a very straightforward description of what’s leading the development at this time.

It does seem clear at least to me, that to achieve anything more complex in economic terms, or room-creation and -usage terms, or governance and collaboration terms, is going to require investment in major tools development (Greenlight). Thus . . Plan B in parallel. I don’t imagine it could be booted from the revenue base of piecemeal selling by individual coops - that’s barely enough to cover the bread and butter ops and repay the up-front labour? So it needs something like crowdfunding, and a re-spec of what a proper Greenlight would need to do? That approach would take some time to spin up.

1 Like

I get it @chris It’s a rock and a hard place, with very litle slack.

Not being someone who has to make ends meet in the hard place, I find myself looking for some other approach, that might enable some other broader outcome, thro making some broader kind of alliance maybe. It’s taking some time to understand the pragmatic constraints that currently prevail in this venture, and I do sympathise with the position I now understand you and other small coops are living with, and are stating here in the thread.

I do genuinely supprt Plan A. I do absolutely need to discover the possibilities for a Plan B, involving some other/expanded grouping of allies and resources. I understand Plan A will make some small contribution to immediate difficulties in a tight situation. But it’s a Plan B that will make a difference to the agendas that my work is derived from, as a commons economy activist rather than a server-services cooperator. It’s my grand-daughter’s ‘hard place’ in 20 years time, that I have my eyes on.