Grow ideas rooted in conversation.
The idea is for Rivulet to be a tool for having public discussion threads over the Internet where people work to share their ideas with a small group of people in order to summarize those ideas for the larger group.
Consider any situation where we find ourselves facing an online discussion where enough other people are interested in participating that the idea of contributing ideas in the discussion seems potentially daunting, overwhelming, or frustrating. The strategy that Rivulet uses is essentially to partition the event participants into branch groups (like "breakout rooms") of limited size. (I imagine a group size of something like 5 to 11 people.) In each of these branches, the goal is to have a conversation about a topic of mutual interest, to arrive at a synthesis, summary, or consensus of the perspectives of the members of the group, and to agree on one of the members who can represent this summary. These representatives would themselves meet in subsequent branches, and the process could continue until there were as few remaining summaries as the group wanted, possibly even a single final summary from a single central branch (trunk?).
I imagine that two key operating principles within the branch groups will be empathy and encouraging everyone to contribute; I'm excited by the idea of having those groups be small enough so that everyone can have a chance to share their perspective and so that participants—even if they are strangers—can still learn about each other. I also imagine that engaging with this process would entail recognizing that a particular conversation is never necessarily finalized, that new voices or information could inject new life into a previously quiescent conversation. People currently unengaged with a particular conversation could still watch the summaries being produced by that conversation, and could then choose to engage with it if it piqued their interest. The goal for sending representatives to middle branches is to share ideas across branch groups.
Everything here is subject to discussion and modification. Currently this document and these ideas are solely being generated by the project initiator; if others get involved, I will move my ideas into an individual space.
- Check out/clone the project repository into a working directory of your choice, then change into that working directory.
- Use npm to install the project dependencies:
npm i. - Change into the client directory and build the client:
cd client && ../node_modules/.bin/vue-cli-service build. - Change back to the top-level directory:
cd ... - Run the server with preferences:
SESSION_SECRET=<secret> DEBUG=rivulet:* node server/init.js.
- space
A particular instance of Rivulet, which provides all of its users with a list of all the discussion topics available in that instance.
- branch
A group of users discussing a topic. In Rivulet, the number of users in a branch is intentionally constrained, but a topic can have an unlimited number of branches in a cluster, and branches can meet.
- watershed
The set of branches associated with a particular topic.
- Node.js
JavaScript (server) runtime
- Express
Web framework
I spent some time learning about and considering Feathers and Cycle.js, but decided to stick with Express to start with. I'm particularly interested in Cycle.js, and I might use one of these two frameworks for a future version of Rivulet.
I've also been reading a lot of Douglas Crockford lately, so I'm curious about whether I can easily use Parseq instead of async/await and Promises. Mainly, studying Parseq and Crockford's work has inspired me to focus on callback-style APIs when they are available.
- Vue.js
Web interface, extended with BalmUI Material Design components
- Socket.io
Realtime stuff that you'd expect from a chat application
- Supporting libraries
- Immutable.js
- HTTP requests with superagent
- Testing with Jest
- Express testing support from Supertest
- Runtime configuration with Node-config
- Database access with better-sqlite3 and Slonik, respectively. I originally considered Knex, but I pivoted after learning more about Knex and reading "Stop using Knex.js". I'm currently focused on SQLite support; eventually I want to add support for PostgreSQL.
- Templating with mustache templates mediated in Express by hjs
I want Rivulet to be open source and easy to deploy so it can be as democratic, free, and easy to use as possible.
I imagine that a Rivulet branch will function something like the following. A user wants to discuss a topic, and so accesses (possibly by creating) the watershed for that topic. For this discussion, let us say that the capacity of branches in this watershed is 5 (i.e. each branch can have 5 users). The user is then placed in a branch, which has up to 4 other users present. They can collectively decide to proceed with their conversation, or decide to proceed only once their branch fills up. They can see information about the whole watershed, such as how many branches are currently discussing the topic, and what results have been accomplished so far.
They have a conversation, which has the technical qualities of other Internet chat spaces but with only 5 (or fewer) people involved. Perhaps some of them need to leave and return to the branch later. At some point (hopefully) they grow satisfied with the branch conversation, and they choose someone to represent them to the larger group. That person can then go on to participate in a confluence branch (with the same capacity), and the process of discussion continues.
I've been wrestling with "controlling" access to Rivulet watersheds. I want there to be an "anonymous" participation option, primarily to eliminate barriers to participation. (I put "anonymous" in quotes because I expect that within a particular branch, all participants will introduce themselves to each other to a certain degree, thus anonymous here refers only to identification and authentication to a Rivulet space.) When accessing a watershed without logging in first, I imagine that Rivulet would provide a token that would allow the user to return to the branch, if the conversation involves multiple sessions.
Part of the challenge of accessing a branch is continuing the conversation if someone departs, particularly if that person is anonymous within the space. When can the other people on the branch choose to stop waiting on a participant who has departed? One strategy that I am considering is to associate a visible time period with a user session such that when the time period lapses, the other participants in the branch may make branch decisions without the absent participant.
I imagine that Rivulet will also provide an option for identification and authentication. This will at least be useful for watershed creators, administrators, and facilitators, and it could allow any user to build up a reputation and a history within a particular space.
- Notifications for new messages
- Multi-line text input for watershed descriptions
- Dynamic display of watersheds by level of activity
- Searching through available watersheds
- Better distinction between new and old messages in the chat client
- Smoother user session interaction