Loomio
Tue 30 Jun

Next generation 'room' services and stewarding of digital tools infrastructure

M
mike_hales Public Seen by 114

An exchange around Big Blue Button in OpenCoop triggered this thread. Reposted here, as a starter. The questions are around . .

  • persistent shared video-mediated workspace ('rooms') as an element of digital infrastructure which has now become basic? but is (politically and functionally) flaky and incomplete?

  • affordances that collaborator-organiser-coproducers need to be provided with in this kind of workspace (=use cases? social intentions? genres and cultural modes of collaboration?); and

  • how 'public' versions of such infrastructure can be effectively stewarded, as commons, as ecosystems. Including stewarding the design, production and mobilisation of large bodies of FLOSS code that will be needed, to give the necessary affordances to an infrastructure of 'useful rooms' for ongoing collaboration within distributed practices of commons development?

M

mike_hales Tue 30 Jun

Reposting this thread from Open2020, with encouragement from @Danyl Strype . .

Oli SB · Jun 25

There is now more detail about Murmurations - and a video from the Presentations and Demos at OPEN 2020 here: https://murmurations.network/blog/

Danyl Strype · Jun 26

This is a fantastic introduction to protocols! Thanks for this Oli. Again, I'm really sad I missed out on participating live.

<snip>

Blue sky thinking; it would be amazing if BBB [Big Blue Button, open source conference software] could produce webinar recordings where the viewer can choose what to see as they watch; speaker, slides, audience, or a combo thereof.

M

mike_hales Tue 30 Jun

mike_hales · culture hacker, geek of another kind · Jun 26

amazing if BBB could produce webinar recordings where the viewer can choose what to see

Sadly, BBB is miles away from that capability. It takes loads of hands-on editing to get the re-publishable video extracts that Oli is putting up in OpenCoop. However, the entire conference stream (video thumbnails, slides, chat) can be viewed in the BBB front end, Greenlight. https://ca.meet.coop/playback/presentation/2.0/playback.html?meetingId=1f7e85c99e0d0f6572888c75c883a7eb0e605c5d-1591858104685&t=3h51m44s

Use the slide view on the left, to navigate to a segment if the (14 hour) conference.

Amendment: The file at the above link is now a 404. Although sysadmins had taken steps to prevent such resources being pruned, the install process for BBB resulted in all history being deleted. An example of how unfriendly sysadmin machinery can be for FLOSS apps, and how painfully users depending on 'friendly' front-ends can discover such things out. An ongoing part of the story in this post . .

In meet.coop we’re discovering that BBB/Greenlight is very oriented to the back end (server ops, docker containers, etc) and barely engages with the reality of how movement organisations and working collaboratives (‘circles’ in the DisCO model, for example) will want to use video ‘roomspace’ as persistent shared workspaces for ongoing work, and to configure different workspaces to suit different kinds of working-together. BBB/Greenlight doesn’t even monitor room usage and server resource usage - sysadmins have to write custom scripts if anybody wants to handle anything so basic as ‘fair use’ or distribution of participation, across a community of rooms, for example.

The whole architecture is oriented to one-off drop-ins. No support for organisation and continuity at all - just glorified ‘chat’. Huh! The video meeting medium has a LONG way to go to meet movement-organisation needs. I don’t think the commercial versions of the tech are any different - there is an individualist, ad-hoc, stream-of-chat mindset. Integration with the “trinity” (Rich Bartlett/Nati Lombardo) and the (DisCO) “stack” of collaborative tools (esp shared document handling) is at Square One-minus. But as ‘the trinity’ makes clear, chat is just one of the capabilities that organisers and collaborators depend on.

Our movements need to get cracking, and develop some (app) integrations and front-ends, to support organisational integrations and circles, if we’re to have anything that counts as movement infrastructure.

Flame over ;-)

The Open2020 conference has been a big learning curve in this regard.

M

mike_hales Tue 30 Jun

Danyl Strype · Jun 26

Sorry if my little grizzle rubbed you up the wrong way Mike :D You raise some valid points here.

Sadly, BBB is miles away from that capability

As is every other video chat tool, which is why I started that final comment with "blue skies " ;) But from what you describe, what I want is already possible by viewing the recording on BBB itself, which is exciting. Can I do that or is it admin-only? If I can, how do I find it?

The whole architecture is oriented to one-off drop-ins. No support for organisation and continuity at all

That's because it was built to add digital classroom features to existing LMS like Moodle and Canvas, which already provide those things. As I mentioned in the VOICE report, Greenlight is a newer project, which allows BBB to be used as a standalone service. Give it time ... or money! ;)

BBB+Greenlight is not intended to meet all "movement-organisation needs", just as Loomio isn't. Each aims to one thing really well (video conferencing, deliberative decision-making). I agree 100% that ...

Our movements need to get cracking, and develop some (app) integrations and front-ends, to support organisational integrations and circles

That's my goal for the cat-herding I do in the OAE group, fediverse.party, and the web forums for SocialHub/ ActivityPub, Solid, talk.Feneas.org, Humane Tech Community, Snowdrift.coop, etc. Give me time ... or money ;)

M

mike_hales Tue 30 Jun

mike_hales · culture hacker, geek of another kind · Jun 26

BBB+Greenlight is not intended to meet all "movement-organisation needs", just as Loomio isn't. Each aims to one thing really well (video conferencing, deliberative decision-making). I agree 100% that ...

Me too. Except . . seems to me BBB+Greenlight doesnt do the 'room' thing really well at all . . if what we want is a work room for some kind of productive circle, with persistent 'furnishings' (resources, tools) for collaborative co-production (which isn't what the LMS world is basically about in the first place?). If all we want is to stop and chat on the street, and be filmed by CCTV, it's cool. I think the expectations that we have of 'rooms' have to be really lifted. I don't think (from Open2020 experience) it even does conferencing well. What it does, in an OK way, is meetings with a few active speakers (classrooms, yukk). Feedbacks from multiple breakout rooms to a main session - essential in engaging really complex systems - are very poorly supported, for example. No equivalent for good-old flipcharts/butcher paper posters ;-) Which can be stuck up all around the walls of the plenary room. Generating a new context for what happens next.

Same is true - as you noted - of video 'conferencing' generally. This is a basic challenge for the technology, not a BBB issue.

A video room has no intrinsic ongoing context. I think maybe context should reside in the 'core' app bundle (BBB+Greenlight front-end) not in a 'parent' frame like Moodle or Canvas or Wordpress, which links thro plugins. I think ongoing shared context is the essence of a meeting in a room between collaborators, and I think that (eg) Wordpress is quite likely to be the secondary rather than the primary co-working frame for a well configured suite of workrooms. Wordpress has all the development effort and plugins (bcos everybody loves to blog and publicise and sell) but that doesn't make it the primary app, in the pairing with a 'room' platform. The room is where the work gets done, rather than the blog trail or the storefront or whatever?

it was built to add digital classroom features to existing LMS like Moodle and Canvas, which already provide [resource supports and process supports]

That explains much, thanks. But as a stand-alone bundle, it offers no hint that it's moving towards other distinct kinds of usage. The LMS use-case isn't a lot of help for real-world collaborative work, seems to me. Different kind of work?

Give it time ... or money! ;)

I'm impatient. And I don't feel we have time.We need the distributed collaborative workspace NOW. The world is going up in flames. The commons are urgent - and the commons of digital means are geek enclaves that are really hard to manage, despite all the praise for P2P culture?

OK with you @Danyl Strype if I copy this mini-thread to OAE? There are further things I'd like to link in more explicitly . . like the Open2020 session on tools infrastructure, and trinity/stack/specials, referenced above.

M

mike_hales Tue 30 Jun

Danyl Strype · Jun 27

OK with you if I copy this mini-thread to OAE?

Funny, I was going to ask you to do just that :)

BH

Bob Haugen Tue 30 Jun

Glad to see this more detailed feedback about the Open2020 BBB experience. I had, unfortunately, recommended it to OSHWA based on the earlier report of a successful experience. And I also see that social.coop has decided to join meet.coop which hosts BBB sessions.

Should I rescind my recommendation?

M

mike_hales Tue 30 Jun

meet.coop is working hard on formulating its service offering in the light of hands-on piloting, and is constrained as a start-up by (human and financial) resource shortages, small-coop economics, practicalities of coop-to-coop federation and shortcomings in the available software (eg the front-end for administering bundles of rooms). Thus, the service at first will be of an early-adopter Alpha-release nature, and users will need to be ready to go through a bit of a learning process in how the coop membership works, and how the service evolves and becomes richer.

A lot will rest at first on fair-use agreements, rather than nicely-targeted service bundles. But the current server provision (Koumbit coop, Montreal) is good, so long as lots of users don't go crazy with big rooms and lots of cameras on. As revenue comes in, load balancing across multiple servers is part of the roadmap. All good.

The BBB tech itself works, no problem, the challenges are more about the large-scale administration of the front end, as a user-facing platform and a paid-for service. A BBB room works fine (depending on browsers being used and of course broadband connections) and quite large numbers can participate (with cameras off, preferably). If an organisation just wants a virtual space to meet in - especially, in smallish teams - a BBB room will do the job (in a slightly different way than Zoom/jitsi but the learning curve isn't too great). At this stage, with regard to meet.coop (there are other providers of BBB access too) the issue is more about wanting to contribute to the coop project per se, and engaging the challenge of putting core infrastructure in the commons, rather than in corporate hands. Being a commons-cooperative federated venture is a big part of the proposition.

In the next month, in meet.coop, things will firm up membership-wise and offering-wise. If a large or complex organisation with high levels of usage wants to join, it might be good to have a chat with meet.coop. It is a small start-up.

GC

Greg Cassel Tue 30 Jun

Good topic; thanks! I'm not here often but here's an intentionally broad generalization: the stewarding of persistent teleconferencing 'rooms' has most of the same challenges as the stewarding of physical settings & rooms. There are of course special technical challenges to stewarding digital resources, just as there are special challenges to stewarding a physical setting with physical risk factors, but I think the primary issues are the same: who gets to make decisions & how? Anyone can try to be a benevolent dictator, and some people can perhaps succeed on very small scales where shared demands don't get too bottlenecked; however, few people IMO are good at collaborative decision process which is genuinely inclusive and sufficiently speedy & efficient. Unfortunately, I think our survival as a species depends on developing inclusive and efficient decision process which can scale to all levels of organizing. It's a big problem & that's why I won't generally talk about much else.

One of the key issues IMO is to be clear if there in fact any final arbiters/ governers of potential conflicts within a specific context or domain. Final arbiters are based usually (during this immature phase of 'civilization') on either (1) informal co-working agreements or (2) legal ownership rights. Ownership often applies ultimately. Software & other information resources can be open sourced, and that's great, but even activities which are based mostly on open resources often depend also (either directly or indirectly) upon proprietary resources. I think it's bad policy to ignore any ownership structures which could be invisible most of the time, but which will almost inevitably take center stage in extreme conflicts (unless nation-state governments collapse, but that's another story!) I'm all about identifying and being super clear about ownership issues wherever they do apply. If you can develop a system which involves no proprietary rights whatsoever, well good luck although it'd also lack legal protections including the reduced personal legal risks in incorporated activities. (Actually I wish I could focus deeply on reducing the legal risks of unincorporated collective activities; others might have important learnings on that front.)


Of course, stewardship is not the same as governance or ownership. People can and IMO often should steward resources which they don't "own" legally or otherwise. But let's please be clear when & where ownership applies to any supposedly common resource.

Stewards can and IMO must suggest guidelines indicating the preferred use-cases for specific resources, and any discouraged behaviors. Stewards who are also owners must sometimes establish restrictions and prohibitions. Authority matters, even though many of us are trying to develop inclusive & distributive governance practices.

To end on a more positive note: assuming that society doesn't collapse and we get to keep on developing digital networking technology, I do think that non-ownership, non-coercive processes of stewardship & facilitation will become increasingly important and (through trial and error) effective. We'll get better at stewarding unowned digital resources, and those learnings will benignly infect our attitudes towards other resources. Our species will somehow learn to become a relatively healthy and whole family. I'm pretty optimistic actually although I see plenty of disaster potentials, and it seems important to create some informative time capsules for others to learn from in case we disappear.




M

mike_hales Tue 30 Jun

A response very much in the spirit of the posting @Greg Cassel thanks - for example the way you focused on awareness of ownership and property, and contrast stewarding with these, and imply that working in this field is some kind of 'dance' which needs a lot of self-consciousness.

When I get another bit of time I'll post some material from the recent Open2020 confeence, where a session - approaching the matter of stewarding of infrastructure - explored relationships between classic P2P open source rationales and full-fledged commoning (alongside classic consumer coop relations, and roots-movement traditions of governance). I have a strong sense that although all bring insights and relevant frames, none of these can be done in 'pure' form in relation to everything that needs to be in the commons, and some new kind of hybrid mode is going to be needed (since full-fledged commoning is arduous dedicated labour, and most folks in any context have their eggs already in other baskets, and just want 'a service' rather than a lifetime of dedication).

stewarding of persistent teleconferencing 'rooms' has most of the same challenges as the stewarding of physical settings & rooms

I think I broadly have the same feeling. But am very aware of how easy it is (for a skilled facilitator) to furnish a physical space with coproduced material that gives history and context to the present action; and how very hard it is to do this for distributed participants in a digital 'space'. There's a great need for interactively manipulable representations of complex systemic stuff, that can be held in the digital space and 'performed' with by participants, during a live session. My sense is, this kind of technology is almost at zero - tho corporate tech like the Miro whiteboard has made a powerful start on stuff that I think has no good free software equivalent (despite plenty of attention to mapping and to graphs). If I have one ambition specifically for for BBB, it's that this FLOSS tech should be developed, and integrated into the presentation space. A 10-year trajectory, a least 🤔

GC

Greg Cassel Wed 1 Jul

Thanks Mike for the thoughtful & detailed response! Yes there are technical challenges to teleconferencing, but personally I've found simple screensharing to be extremely helpful in going over intended subject material, especially if that material includes diagrams or other models of systems. Screensharing enables shared visual focus on almost any type of software tool, without everyone needing to use the same software, although that's often desirable anyway. Of course it's important for the meeting or session facilitation role (possibly relayed, like a "baton") and thus screensharing permission to be mutually understood throughout a meeting.

DS

Danyl Strype Sat 11 Jul

It really is a shame my world descended into another circle of chaos around the time Open 2020 was happening. I suspect I would have a much better grip on the limitations @mike_hales is describing if I'd been able to attend some of the online conference sessions. So far I've only really used BBB for informal chats with small groups (5 or less).

@Bob Haugen I think BBB is suitable already for a one-off online conference, especially for hackers like OSHWA. My interpretation is that Mike's comments were aimed more at orgs wanting to use BBB as part of a daily organizing workflow, where video rooms persist, have defined memberships, and integrate smoothly with other group tools (eg a Loomio group, NextCloud filestore and calendar, or matrix text chat room). Such affordances (as Mike put it) would make BBB more useful for organizing conferences and following up afterwards, as well as just being the online equivalent of an empty conference centre.

M

mike_hales Sat 11 Jul

> video rooms persist, have defined memberships, and integrate smoothly with other group tools

Yep that’s what I meant.

DS

Danyl Strype Wed 15 Jul

In a nutshell, I don't think the solution is to add lots of UI bells and whistles to BBB, any more than we need devs to start building a video conferencing server into Loomio, or polls into Synapse (matrix server). The BBB backend is sound and that's what we want them to focus their dev resources on continuing to improve.

Instead, we need to look at how a co-op like social.coop or DigiLife can integrate tools like these under one login. Combining, say, Loomio, BBB, and Synapse, to provide a seamless UX that offers an invite-only decision-making group, text chat channel, and voice/ video conference room. It's like someone has already made good patterns for arms, a front, and a back, and now we need someone to knit it all together into one jersey (or jumper or whatever).

M

mike_hales Wed 15 Jul

integrate tools like these under one login

My experience of DigLife is that although there is single sign-on, this doesn't really generate any experience of integration. Numerous discrete apps with distinct interfaces in numerous browser windows. TBH I'm not sure what 'integration' might call for - but I do feel that I'm doing a 'dance around the browser tabs' these days, which is pretty demanding and confusing, and I doubt most people have an inclination of willingness to do this. I may be beginning to favour discrete desktop apps. Or at least, a choice of browser or desktop implementations. Some of the time I want to have something in a separate browser window. And sometimes in an adjacent tab in a single window. This kind of "architecture on the desktop" - or "choreography on the desktop"? - is pretty hard to figure - and I'm a designer 🤔 and good with 'space'.

I suspect there might be an argument for putting a (Smallish) repertoire of tools in a single app/interface 'box' bcos most people wont attempt the work of work-design.

arms, a front, and a back

A tempting metaphor 😉 But a body does anatomically have arms, a front and a back . . whereas a practice, or a collaboration, or an interaction, doesn't have an equivalent discrete anatomy. A practice/collaboration/interaction is 'seamless' and a 'dance'. Everything happens all at once, in all senses, in all dimensions, in the material and cognitive place where the user is. Workspace design/interface design (and underlying that, app design) that really supports communicative interaction is hard. I suspect we still dont have much shared learning about this. And folks differ.

Whatever . . I'm not happy - for myself, or for less app-literate people - with umpteen apps running in umpteen browser tabs, which is how things look to me at present.

DS

Danyl Strype Thu 16 Jul

I hear your frustration Mike. But I worry that there's some shared context missing here. Let's see if we can fill it in by taking a step sideways and talking about fediverse tech for a minute. Terms in Ancient Geek are shifting sands, as in philosophical language, attempts to describe and relate abstractions, not things (in the world). So apologies if I'm oversimplifying or stating the obvious in places, but I want to lay this out as clearly as possible. Apologies in advance for the Great Wall of Text.

Most fediverse software stacks like Mastodon and Pleroma consist of two distinct parts; a "server" and a "client". The server is the part that runs on someone else's computer, under their control. The client is the bit that the user sees, what we generally called an "app". To confuse matters, there are also P2P (or "serverless") "apps", but we'll come back to that.

Pleroma includes a "web app" (an app that runs in the browser), and from an end user perspective, this app is what Pleroma is. But from a dev perspective, the server part is what Pleroma is. To them, the app is just "UI", an optional set of buttons and switches that, like a mechanical control panel, can be easily swapped out for something else.

The same is actually true for "serverless" apps like Jami or SyncThing too. The "app" a user installs actually includes a client - the set of controls that the user interacts with - and a server - the bit that connects to the P2P network and does things in response to the controls. As with apps that depend on remote servers, the client UI can usually be improved (within the limits of the server's existing features) or replaced entirely, without any major changes to the server part.

Coming back to Pleroma, a user can use a separate web app like Pinafore to connect to a server running Pleroma (or Mastodon), instead of using the default one. This is possible because devs have to decide on a consistent protocol for how the server communicates with the default web app. This is what we mean by API (Application Programming Interface). If there's enough information available about how to make your app speak that API protocol, then other devs can make their own apps talk to that server as well. This is even easier when the project uses an "open" API like the client-to-server (C2S) bits of the ActivityPub "standard" (a standardized set of protocols), which Pleroma now does.

The most essential work the devs on all these projects do is on the server, as this tends to require specialized software engineering skills that vary from project to project. Developing the UI component of apps involves a more generalist skillset that is more widely available. Server engineers like to think of it as the difference between a chef and a waiter. But it's more like the difference between a barista and a short order cook, in that a barista's job requires them to do one thing really well, while a cook's job is to do lots of things, all at once, fast, but good enough that the customers don't complain.

So if the software is free code, and it pretty much gets you where you want to go, but you don't like the design of the steering wheel and the pedals, that's not a problem to take to the server devs. It's better to look for some app developers who share your needs and frustrations, or can empathize with them, and design some new apps with them. In some cases, the upstream project will borrow UI ideas from third-party apps, such as when Mastodon switched from its 3-column layout to the new 1-column default, following the example of pretty much every others fediverse app.

So, let's circle back to our hypothetical combo of BBB, Synapse, and Loomio. Like Pleroma, all three of these consist of a server and a web app, and it's these web apps that are frustrating you in these multi-tab organizing workflows.

BBB uses a de facto standard, WebRTC, defined by Goggle. Synapse uses an open standard, the matrix client-to-server API, defined by the Matrix Foundation. I'm not sure what API Loomio uses, but if the devs haven't clearly defined it somewhere, writing that documentation could be a valuable contribution to the project.

In theory, it's possible to create a single app - from an end user perspective - that can speak all 3 APIs, and connect as a client to instances of all three servers at the same time. This could be a web, desktop, or mobile app, or all three, depending on who we can get to work on it. That would be a whole new software project, requiring commitment from some UX designers and app framework geeks. Funding might help, although it doesn't always (see the history of Chandler). But it would be much less work, and much more likely to succeed, than trying to shoehorn what we want into any of the server projects.

SG

Simon Grant Fri 17 Jul

Interestingly, this is an issue that the co-op I help run, Cetis, has identified and focused on recently in terms of thinking, but not much in terms of action. Which issue? Well, to rephrase it, the issue of lack of integration between different tools. From my perspective (in this community as well!) there are always the questions "where is the (asynchronous) conversation happening?" and "where are we meeting (synchronously) now?" My guess is that this challenge, in particular, exactly needs some deep joined up thinking of the kind that simply is not feasible for any one person. "How to join up effectively?" remains a strong focus for me.

SG

Simon Grant Fri 17 Jul

Thanks @Danyl Strype -- useful summary! One point of interest for me is the governance of the protocols / APIs, and their underlying ontologies. My (informed) guess is that where their is ontological dissonance (riffing off "cognitive dissonance") between the protocols, it will be more difficult, or uglier (with more unsatisfactory kludges) to create a single end user app. I can't say if that is consistent with @mike_hales Mike's appreciation, but as I replied to him, I think this is exactly the time for joined-up thinking between us wannabe architects, based on deeper connection at the intuitive level. From my perspective, the issue circles around ontological harmony.

SG

Simon Grant Fri 17 Jul

(p.s. I see the concept of "ontological dissonance" has been used in the context of social psychology, but I can't find it being used in the context of https://en.wikipedia.org/wiki/Ontology_(information_science)

DS

Danyl Strype Fri 17 Jul

I strongly suspect that, as in contemporary science, a lot of software development consists of cargo culting. I'm not sure if or how this relates to "ontological dissonance", but I suspect it does.

SG

Simon Grant Fri 17 Jul

"Cargo culting" makes sense! Just as it's not a question of "if we get the software right the people will come", equally it's not a simple case of "if we get the ontology right the software will follow". I'm suggesting a bit of the reverse: if we don't get the ontology right, then glamourous software may tempt people in, but disillusionment is likely to follow. Go right back to source -- and I'm not talking about code! Getting the values right will help the relationships; which will help the process to agree the ontology; which will help the software be more deeply and robustly interoperable; which could provide foundations for a more solid user experience. No guarantees at any step. More like the removal of obvious obstacles. Healing wounds.

LF

Lynn Foster Mon 20 Jul

Nothing to add, but wanted to say thanks for looking into this set of tools. And I learned a new term, "cargo culting"! :)

DS

Danyl Strype Wed 22 Jul

There are some tools here that may be useful when using BBB for online conferences, including BBB-Render:

"Scripts to convert a BigBlueButton recording into a single video file" https://github.com/plugorgau

I've found a few ad hoc collections like this, associated with groups that put on this or that open source event. There seems to be a need for a meta-project to pull all these bits together into a comprehensive online conferencing suite. That's what I was envisioning with Core-Us (chorus, get it?). See: https://git.feneas.org/disintermedia/public-wiki/-/wikis/Core-Us

DS

Danyl Strype Thu 6 Aug

Meething is an experimental video conferencing system being developed by ERA, with sponsorship from Mozilla. Could be worth checking out whether/ how they plan to design for,the user needs we've been discussing here. Their code forge is here:

https://github.com/meething/meething

@mike_hales