chat
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
James Kiesel Thu 1 Jun 2017 12:30PM
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 Thu 1 Jun 2017 1:05PM
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 Thu 1 Jun 2017 3:28PM
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 Fri 2 Jun 2017 3:25AM
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 Fri 2 Jun 2017 3:45AM
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 Fri 2 Jun 2017 3:56AM
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 Fri 2 Jun 2017 9:45AM
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 Fri 2 Jun 2017 11:23AM
@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 Fri 2 Jun 2017 12:15PM
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 Fri 2 Jun 2017 10:43PM
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 Sat 3 Jun 2017 9:57AM
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 Sat 3 Jun 2017 10:09AM
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?

Danyl Strype Sat 3 Jun 2017 10:21AM
I've opened a thread for a discussion about Sandstorm and small-contribution plans on CommonsTransition.

Danyl Strype Sat 3 Jun 2017 12:45PM
For anyone who's interested, I've start a new thread to talk about the relationship between apps and platforms, so this thread can remain focused on the topic of the request for a chat feature in Loomio.
Wael Al-Saad Thu 1 Jun 2017 1:58PM
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 Thu 1 Jun 2017 5:13PM
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 Sun 4 Jun 2017 5:31AM
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 Fri 7 Sep 2018 5:18AM
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.
Bob Haugen · Thu 1 Jun 2017 11:34AM
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?