Loomio

chat

Wael Al-Saad PublicSeen by 129

Original discussion starter:
Have u discussed adding group and subgroup chat as new way of communication beside discussion?

Often brainstorming and warmup through helps to formulate the discussion ..

Proposal for community-led research and evaluation

Existing free code chat software could be integrated into Loomio as a module, or a Loomio server could be connected to a stand-alone chat server through an API, with the chat integrated into the Loomio UI. Some chat code/ protocols are designed with one-to-one chat in mind, with conferencing added on as an afterthought (eg SIP, WebRTC), while others are designed around group conversation in a "room" that can persist with or without having active users in it (eg IRC, Mumble). The latter type are more suited to the Loomio use case, and more likely to scale up to the numbers of users active on a Loomio server at any one time.

Chat modules (or apps containing them) for evaluation

  • Name | Demo | Source Code | License | Language(s)/ Framework(s) | Standard(s)/ Protocol(s) used | Web-based/ Server-client/ P2P
  • Etherpad | Demo | [Source Apache 2.0 | JavaScript, Node.js | ? | web-based
  • GNU Ring | ? | GPLv3+ | Source | SIP/DHT | C, C++, Java | IP | P2P
  • Jitsi Meet/ VideoBridge | Demo | Source | Apache 2.0 | Java, Javascript | WebRTC | web-based
  • MatterMost | Demo? | Source | AGPLv3 (server), Apache 2.0 (admin tools) | Go | ? | Web-based
  • MetaMaps | Invite-only Beta | Source | AGPLv3 | Ruby on Rails | ? | web-based
  • Mumble | ? | Source | BSD 3-clause | C++ | VoIP, Mumble protocol | Server-client
  • Palava.tv | Demo | Source | LGPLv3+ | Ruby, Java, Javascript, JSON, coffeescript | WebRTC | Web-based
  • Rocketchat | Demo | Source | MIT | Javascript | Meteor/ SAML, Jitsi VideoBridge | Web-based
  • Riot.im | Demo | Source | Apache 2.0 | Java, Javascript, Objective-c | Matrix | web-based
  • Tox | ? | Source| cross-platform [Clients] in a range of languages; C++, C, Vala, Python, Scala,Objective-c | Tox protocol, DHT | P2P

KaNNoN

videochat?

Pierre-Yves

In my humble opinion, the chat should not be integrated in loomio (at least at this stage; there are many other improvements more important than this). The groups can use a 3rd pary (video)chat if they need so.

Wael Al-Saad

Text Chat like the one at etherpad

Wael Al-Saad

I see .. the idea behind that, tools commons empower the crowd

Balasankar C

I suggest we use XMPP for chat so users can use their existing accounts.

Danyl Strype

I notice that MataMaps have recently added a live chat sidebar with a similarly user experience to the chat sidebar in Etherpad. It can be expanded, or hidden leaving only a button on the side of the screen. Not sure what protocols the MetaMaps chat feature uses (Websockets? WebRTC? Something else?) but it supports voice and video.

AFAIK MetaMaps is fully free code, and MetaMaps uses Ruby on Rails like Loomio does. Perhaps their chat systems could be modularized so it can be used by other free code projects like Loomio to add a chat sidebar?

EDIT: Removed reference to Hylo. What they've added is a direct message system, not a live chat system, and it isn't working for me.

Z. Blace

interesting. agree live chat is much needed feature. if loomio wants to be standalone product it is even urgent.

James Kiesel

I'm fairly sure we won't be working on a chat feature in the near future. I've talked in a couple other places about limiting Loomio's footprint to deliver a really great experience at our core competency, which is decision-making. Loomio was never going to rival Facebook, or Discourse or Basecamp or some of these EAS tools which just do freaking everything under the sun (although we thought it could when we started out)... we do not have the resources to support such an endeavor.

Here's a list of chat apps I can think of off the top of my head: KakaoTalk, Line, Messenger, Slack, Signal, Discord, WhatsApp, RocketChat, Skype, Voxer, Yahoo messenger... I'm probably missing a dozen more.. you probably have at least 3 installed on your phone right now. Users are exceptionally spoiled by their (usually excellent) experiences on these apps, and it's basically just not an area I'm interested in competing in at all. I've actually built a chat module for Discourse a while back; it's a non-trivial endeavor to get right, and it would be really easy to sink a whole bunch of time into a mediocre-to-decent chat that nobody ends up using because there are so many ways to communicate on the internet.

So, I think it's a much better use of our time to position Loomio as a slide-in, lightweight decision-making tool which can be used easily from these other tools... things like 'drop a deep link to a poll into a chat anywhere', or 'make a decision with your slack team without ever leaving the Slack app', rather than 'support short informal discussions in a tool that's designed for relatively formal communication'.. this is the thing that no one else is offering, the 'missing piece of the internet' that we talked about in our crowdfunding videos and elsewhere.

I'm, of course, really open to having my opinions here challenged :)

Danyl Strype

This bit I want to challenge is this:

"it would be really easy to sink a whole bunch of time into a mediocre-to-decent chat that nobody ends up using because there are so many ways to communicate on the internet."

This assumes that Loomio would build a brand new chat system from scratch, and that it would therefore be a mammoth effort. But you don't need to roll your own (and maintain it). Free code for web-based chat systems already exists, as I pointed out with the example of MetaMaps. You could build on this work by making a chat module a dependency of the Loomio codebase itself, or creating a chat API that allows the admins of each Loomio server to hook it into the chat back-end of their choice.

That would require you to come up with some evaluation criteria, evaluate what exists (Kalashnikov principle), make a choice, and figure out how to integrate it neatly and intuitively into your UX. Loomio core devs don't need to do all of this work either. It seems like there are at least a few of us in the wider Loomio community who want this. If we can work up a list of criteria here, or at least the information needed about each candidate (language/ framework/ protocols/ license etc), the community can help with testing stuff (from user and/or admin POV) and adding all the info for each candidate to a list in the description box. I'll start with MetaMaps to demonstrate what I mean.

Bob Haugen

As someone who wants to embed Loomio proposals and decision protocols in other systems, adding chat seems like the wrong direction. I'm happy to see @gdpelican 's opinion upthread that Loomio devs want to focus on decision-making.

Relatedly, what happened to the mythical Open Apps Ecosystem ideas of flocks of apps working together?

James Kiesel

Too much talk, not enough action. It was a shame to see Sandstorm go the way of the 'community supported project', and they got waaay further than OpenApps ever did. Interop is hard and usually doesn't make anyone any money unless it's designed and executed really well (and even then you have to have a core value prop that's actually worth something too, and have apps on there that people actually want to use together, and they have to work together in the right way... the complexity compounds real quickly)

It's the type of thing that businesses or organizations can discuss at a high level for years (oh God it is soo satisfying for people to imagine a world with better interop), but never grasp quite well enough conceptually to turn it into a real thing.

I hope not to come off as too negative in this post. But I have to admit to rolling my eyes a little whenever interop comes up in a business context, while simultaneously working furiously at making it a reality in my own work for years. We're still not there yet (although at this point the mountains are more like 'Write some really high quality documentation', rather than 'rejigger our whole codebase to account for other apps', and at this point we'll need to be focusing 100% on sustaining ourselves as a business, which means doing the thing that produces the most user value the quickest... which is a very specific subset of interop (like talking to Facebook, Slack, and Google). And, sorry to say, it's not chat. <3

As ever, the caveat applies that an interested and talented developer may come along and make it happen. I would love to see this, and am more than willing to support anyone in such an endeavor.

Bob Haugen

Totally agree about Sandstorm. I think Open Apps continues in Root Systems. And yes interop is hard, and needs to be focused on immediate benefits, but is happening all over the place. That's a lot of what makes Slack and the other black holes you mentioned such attractors, and why you want to interop with them.

Before that, it happened in big supply chains (e.g. Walmart, Apple, Toyota, etc).

Bob Haugen

This is an addition to my previous reply. Thought about it more during our morning walk.

From a software business viewpoint (which is a really difficult viewpoint for me to adopt anymore, but I worked in software businesses for lotta years, so I can still force my head to go there), how many interops you got is part of the sales pitch of several of today's star apps: Slack and Trello, for example.

But in the longer software business run, you got platforms and features. Slack and Trello are features trying to be platforms. They will fail as platforms, although they may cash out as features (as Trello has already done).

Decision-making is a feature, so it makes sense to interop with platforms. Even temporary wannabe platforms like Slack...

Doesn't make sense (to me, anyway) for Loomio to try to become a platform.

Danyl Strype

At risk of drifting off-topic here, but I have to say...

which means doing the thing that produces the most user value the quickest... which is a very specific subset of interop (like talking to Facebook, Slack, and Google).

Doesn't prioritizing interop with The Stacks (and wannabe Stacks like Slack) run counter to your basic values as a social enterprise? Equivalent to running like a trad start-up and aiming for acquisition or IPO? Wasn't the whole idea of the CTA that smooth interop between free code apps would allow you to collectively become a replacement for The Stacks?

Danyl Strype

As someone who wants to embed Loomio proposals and decision protocols in other systems, adding chat seems like the wrong direction.

Maybe for your specific use case, but some of us use Loomio as the HQ of our collaborative workflow. Being able to move into ephemeral text chat (or even better launch a voice/video conference) from within a Loomio group would help prevent the flooding of asynchronous threads with realtime back-and-forth, which makes it harder for other participants to keep up with the thread.

Maybe the simplest way to address this need would be a feature that allows a user spin up a temporary subgroup? I've described how this could work in a new thread called Brainstorms.

Danyl Strype

Doesn't make sense (to me, anyway) for Loomio to try to become a platform.

I think we need to distinguish here between Loomio (the codebase), and Loomio.org (the website). I agree with what you say here when it comes to Loomio the codebase. But Loomio.org is a platform (as is any other instance), and whatever features can be added to Loomio.org can be added to any other Loomio platform. At the moment that's being done by tying Loomio.org into The Stacks.

I think it would be better for a constellation of reasons (both technical and ethical) to achieve the same goals by tying Loomio.org into existing free code apps. I've said, there are plenty of server-side chat packages that could be pressed into service for this. The API added to Diaspora to allow an XMPP server to be the back-end for Diaspora's chat feature is another example of this in practice.

Bob Haugen

Hmmm.

some of us use Loomio as the HQ of our collaborative workflow.

Ok, sorry, I have not encountered that situation before. Every org I've worked with has a lot of systems in use and Loomio is an adjunct, often just for decisions, but sometimes also for discussions. So those orgs would prefer Loomio as a plugin. I can see if Loomio is your HQ, it's all different.

[edit:] I wonder what the spread is between Loomio as your HQ vs Loomio as one app among maybe many?

Danyl Strype

@bobhaugen Do you mind if I reply to your comments about platforms on this thread, where it might be more on-topic, and avoid hi-jacking this thread about chat?

Bob Haugen

Ok with me. But I think the comments about Loomio's role in its user base is on-topic for this thread, too. Adding chat might make sense if Loomio is your HQ, but not if Loomio is one of many tools that you use that you would like to work together more. Then it just gets in the way, because you already have a chat tool.

James Kiesel

This is essentially what I'm saying. It is easier to build, easier to support and grow, and thus more practical for us to make something which does one thing very well, rather than a tool which does everything you could ever want to do in a community.

I am excited to integrate with FLOSS tools, but as a co-owner and co-op member it's my primary responsibility at the moment to allow Loomio to pay its members a sustainable wage so that we can continue to provide this useful thing to you without killing ourselves. We have already lost tons of talented people as members because we've been unable to build a sustainable business out of this thing yet. I'm not going to work on anything which I don't think will move us in that direction.

That said, Loomio is open source. If someone feels strongly about this, they can design and resource it, and make it happen.

Danyl Strype

This is waaaaay off-topic but...

"It was a shame to see Sandstorm go the way of the 'community supported project'"

Having read the Sandstorm project blog post about this, I totally disagree. Sandstorm have abandoned their "open core" business model, taken down their paywall, and liberated all their code. I think this is a great thing for the project, and for the world.

Sandstorm realised that they couldn't build a commons-based business by selling stuff to "enterprise" (corporations). Even Enspiral are sometimes willing to use proprietary freeware (GITHub, Slack, Google Docs, Trello) rather than self-hosting libre replacements, despite the clash of values involved. Why would profit-centred companies spend money on a (partially) free code service when they can outsourcing their computing to The Stacks, and get a proprietary service gratis? The "open core" business model is the worst of both worlds, and it's not the future of funding free code development.

Sandstorm would be better off looking at paying for dev costs by collecting regular, small contributions for sysadmins running their software, and the end users. There are now a number of libre platforms for managing this, including Gratipay, LiberaPay, OpenCollective, and Salt (a BountrySource service).

Bob Haugen

Let's find a place where it is on topic. I'd like to learn how the Sandstorm project is doing since the founders abandoned their business plan.

Likewise the small-contribution plans: who's making a living from them?

Wael Al-Saad

I can't agree more.Those who wants loomio-chat can imagine more its need and function. You won't always need to create chat groups on traditional chats and ask people for their phone numbers or need to be part of these privency murders and exploiters.
You would see easily if any group member is online and have contact with, etc.

Z. Blace

That is a good distinction Bob. Thank you for clarifications and insights James.

I would love to be able to use Loomio in seamless and intuitive way with other FLOSS apps, platforms and services/features, but until this happens it is pain in the ass to get non-technical people to join and very technical people to embrace it as one more system to use for single functionality :-/

Danyl Strype

So, for those looking for free code chat software, there's a table taking shape, with a number of chat apps and some basic info about them. It would be great if people could share their experiences with any of these, good or bad, recently or a while ago, from an end user perspective or a sysadmin/ developer perspective. If anyone is up to join and organised testing team that has a regular online chat using different chat systems, please get in touch.

To avoid posting a bit wall of text here, I've recorded some of my experiences with the various apps in the table in a blog post. Tl;DR I think the Etherpad and MetaMaps chat systems would be the first things to experiment with, and more complex integrations with Jitsi and Mumble might be good for more ambitious long-term solutions.

Danyl Strype

Wire is another fully free code chat app, with end-to-end encryption. It supports text chat and voice and video calls, although so far I've only tested the text chat. You can use the standard Wire server (with some limitations), or run your own.