Systems architecture

Product circle Platform tools
, ,
1

I have tried to draw a diagram to put the different ideas in one picture, here it goes:

Draft systems architecture diagram
(maybe we should enable the inclusion of images in Discourse)

Brief notes:

  • each user has one account to login to the various services
  • we use the existing loadbalancing architecture with Scalite. This means one loadbalancing setup at each node/datacentre. The main drawbacks for users of this setup are mitigated through the shared user account server.
  • I didn’t paint in yet the customised Greenlight frontend for bigger organisations, but would expect that they could connect to the loadbalancer in the same datacentre.
  • external apps, like WordPress or NextCloud instances of members, could install the appropriate plugin and integrate the meet.coop videoconferencing service in their UI. Testing is required, but this seems to be an option.
    Does this match your ideas, please shoot and improve. The diagram is in editable format inside the /architecture folder.
2

You can embed external images in Discourse, it is Nextcloud being too clever in this case that is the problem, I worked around that by downloading the image from Nextcloud and uploading it to the wiki and then putting the image URL on a line on it’s own to generate this:

1 Like
3

excellent, thanks Chris. So how do you find this diagram, does it make sense? What would you do different?

4

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:

  • Deploying and running running multiple Greenlight Docker containers
  • Deploying and using the BigBlueButton WordPress, Drupal, Nextcloud and Moodle plugins
  • Deploying and running multiple BBB servers behind Scalite
  • LDAP
1 Like
5

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

The diagram now includes also a “Private Greenlight” server connecting to one of the node’s loadbalancers.

  • We suppose here that the loadbalancer provides an API that allows for several frontends to connect to and dispatch a room to be deployed at the BBB server in the node’s pool that has most available capacity.
1 Like
6

Yesterday we discussed to have different Greenlight instances for

  • individual members
  • organisational members
  • events that need a dedicated GL server with customised configuration

I have tried to depict that in the updated diagram:

2 Likes
7

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.

1 Like
8

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?

9

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.

10

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?

11

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
12

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

13

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?

14

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.

15

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?

16

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.

17

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.

18

@wouter I’ll post a slide deck in the next hour, containing maps/prompts on executive circles, membership classes, contribution accounting, voting rights.

19

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.

20

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.