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

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.

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

Yep that’s what I meant.

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

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.

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.

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.

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.

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

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.

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