From Online Meeting Coop Wiki
Jump to navigation Jump to search


  1. Would we want a Jitsi like front-end that allows people to create rooms on the fly for the Alpha stage in addition to creating user accounts for member organisations?
  2. Or would that be for the Beta stage?
  3. Or would the Greenlight front-end be a useful way to get started and explore meanwhile what can be improved where desired?
  4. Would user accounts be conditional on membership of a membership organisation? How are we going to manage this? What automation processes can be thought of to allow users to register an account, confirm membership to any of the host organisations and make their contribution and get a certain user role?


  1. In case we do want to have a custom front-end, following are some draft ideas for how the front end BBB server selection could work, this could be implemented using JavaScript with a fall-back to server-side code (PHP? however that is slow, so perhaps SSI as SSI is very fast and is supported by Nginx and Apache), or perhaps if JavaScript is required by BBB then simply implement everything using JavaScript and fall back to asking users to enable JavaScript?).
  2. For creating user accounts and rooms, the simplest seems to be to use the GreenLight interface that allows users to create rooms, start meetings, and manage recordings. It is a reference implementation by the BBB team and provides many useful things. We could allow everyone to register a user account and let them have one personal room (maybe initially keep it unlimited, but at some point limit it to 60 minutes sessions for non-contributing users?). Users can share rooms with others and self manage their recordings and room settings. Besides we could define a specific, more powerful role for the organisations and people who make a contribution to the project. While initially we can manage such member roles by hand, at some point we'll need a more automatic process from registration, contribution and user role, but that should probably not be necessary yet in the alpha stage. We can share admin roles between the co-producers.
  3. In both cases we need to decide the front-end at when we have three servers to start with, one in Canada, one in Germany and one in New Zealand. In time more could be added and also each server could be expanded to be a load balancer with multiple BBB servers (in the same data centre) behind it.
  4. At some point between alpha and beta stage we could prepare a loadbalancer at the front. There are various BBB loadbalancing projects, but Scalite is possibly the best maintained, by the founders of BBB: "Scalelite is an open source load balancer that manages a pool of BigBlueButton servers. It makes the pool of servers appear as a (very scalable) BigBlueButton. A front-end, such as Moodle or Greenlight, sends standard BigBlueButton API requests to the Scalelite server which, in turn, distributes those request to the least loaded BigBlueButton server in the pool."
  5. There's value for the users in having one account and being able to share rooms with others even though they might be on different geographical nodes. A unique frontend at could at the end serve all users on the planet following two criteria: a) nearest node and b) availability of that node. In case all instances in the nearest node are under heavy load, the then nearest node could be polled for an instance to open the room there. Possibly such logic could be built in after developing a customisation in GreenLight and Scalite, in the case these will be used of course. GL, with some customisation, could know the region of the user, just as right now it knows the user's language as defined in the user profile. The loadbalancer would need to receive that parameter when provisioning the requested room at the most appropriate BBB instance. Another idea would be to have a loadbalancer in each node or continent.

  • Redirect to
  • Serve in the first matching language in the HTTP request that the User Agent sends, unless a cookie is set to serve it in another language.
  • Display a language picking select list to allow users to change the language used.
  • If a cookie is set for a location preference redirect to the location last used.
  • Ask users to pick a location and redirect and set a cookie based on their selection, for example:
    • Australasia →
    • Europe →
    • North America →

  • Redirect to
  • Serve in the first matching language that the HTTP request that the User Agent sends, unless a cookie is set to serve it in another language.
  • Display a language picking select list to allow users to change the language used.
  • Display a continent picking select list to allow users to change the location.

As NZ above.

As NZ above.

Keep it simple at the start

  • Redirect to and present a list with servers, and let the users choose where they want to go. Consider that mostly the meeting hosts will make such choice, and then send the room link to invite participants. The home page could basically say this:
Region Service URL Hosted by Contribute
Europe Webarchitects, femProcomuns, See Membership
Canada Hypha & Koumbit See OpenCollective
Australasia NZOSS ...
  • explore ways to have one userbase so users in one region can participate with their account in instances in other regions.