Here, I explain how a chat, forum, and wiki system could be composed of the same very simple set of features. I think if we made this, it would be the most healthy online social environment to exist for some time to come.
I've whittled off most of the major design ambiguities, here. It looks like this would be relatively simple to make. So, shall we do it?
Conceptually, there are basically only two things you can do in neschat, you can find or create an object and make it a reply to another object, and you can subscribe to an object to be notified of its new replies. Those two core interactions are basically enough to create a combined wiki, forum, realtime chat and content sharing system out of the same stuff, interleaved.
(Technically, making that work is a a bit more complicated and involves a couple of other features, but that's the core concept.)
neschat consists of a forest of trees of objects.
Most objects are comments, but some are polls, some are configs, and some are user profiles.
When an object is inserted into another object, it can be seen under it, like a reply.
Every object has the following permission groups:
Read: The people who can look at this object and its replies
Edit: People who can change the content of the object, for instance, if it's a comment, who can change the text.
Reply: People who can add objects as replies to this object. This will usually be a very broad group.
Prune: The people who can remove replies, and who can change the recommended sort algorithm on the replies.
Own: The people who can change the permission groups or what the object's primary parent is. Usually it will just be one person.
Implicitly has the other permissions as well.
It's easy to imagine being much more fine-grained than this, by having every individual permission group have a pair of permission groups saying who can add or remove people from it. This would produce an infinite regress of outer permission groups over permission groups, and I really don't want to have to figure out how to program that until we're sure we need it.
This very simple version, though, has an issue where anyone in the Own set can coup everyone else in the Own set at any time, taking sole control over it, however, this is a common situation in online communities and I've never actually heard of it happening.
Maybe there should be an Admin set, which lets people change anything except the Own group, and if there's an Admin coup the Owner can just come in and reverse it (thereby dis-incentivizing the Admin coup and preventing it from occurring in the first place).
A sole owner can remove themselves from the Own set, leaving it irrecoverably empty, and making the object ungovernable. This is an advanced move that should not be attempted by beginners.
(there is no Delete permission group because there is no deletion. neschat is designed in anticipation of being ported to decentralized systems, where deletion is not really possible. In a system where users have control over the data on their device, once you've shared a piece of data with them, they have that data. It's on their computer. You don't have control over their computer, so you can't delete the object any more.)
Any of these can be set to
inherit from their primary parent.
A Way describes a way of using some part of neschat object tree.
Having this is crucial, for the same reason Vim would be a pretty terrible program if configuration files couldn't be downloaded from experienced users. There are so many different ways you could use neschat, the choices are overwhelming. The Way recommended to you will give you focus and clarity.
Ways are kept as objects. Users can choose to install a Way when they find it.
I've made them out to be something pretty abstract, but in the first version, installing a way just puts some links in your sidebar!
Generally, these links open feeds that are defined over the replies to particular key objects, which are usually Owned by the same person who owns the Way (The Way can be edited and updated). For instance, say there's a global boating community called "sailing". This community's Way might have a feed called "part recommendations", that shows the newest replies to the "part recommendation" object that can be found under the main community "sailing" object. Object nesting provides a way of organizing and navigating the community's information.
A Way's description of a feed basically just says
which object it's following
whether it should show a number next to the link saying how many new replies there are
whether you should be sent a notification when there's a new reply
how it should display the replies when you click the link.
Often it will be newest first, sometimes oldest, sometimes manually ordered by curators, and later we can add more complicated stuff like vote sorting.
For the first version, we could implement Way objects as a blob of text defining an s-expression that specifies the Way. But they should probably at least have a type field communicating that they are a way (rather than just a comment), so that neschat can include a button that says "install this Way".
Later on we could consider doing a much nicer UI for building them, they're strongly typed enough that an intuitive form-filling editing workflow is possible.
There's an issue that comes up here, though, and it'll come up again: These need to be able to refer to objects. Objects will not have simple names. They'll have UUIDs. UUIDs aren't typable. So a plain text representation would end up with a lot of
6b619796176f0884758068ea61c3fdf0s in it. Should eventually look for a web editor that can at least abbreviate them (maybe represent them with little deterministically generated sigils), or try to use any given friendly name they have, but in those cases a plain text editor wont entirely do. They'll be special tokens.
From these few systems, much is possible:
Wiki: A wiki is just a forum where some of the posts can be edited by a broad community instead of just their original author.
Chat: This wont really be in it initially, but it should be implemented as a view you can enter through any comment that... roughly speaking, picks a reply chain and sort of flattens it. It's pretty much just:
a way of representing the discussion tree that doesn't constantly drift to the right
This is all a subset of the planned functionality of my project tasteweb, AND I'm pretty sure it's going to be a subset of whatever roamresearch is going to evolve into (which, well, might also be a superset of tasteweb), but who knows how long it'll take those projects to get to this point. We can implement this set of functionality now, so maybe we should? (EDIT: I just looked in on Athens and it seems like they're very quickly heading in a direction where they'll be ready to do all of this. It seems like they may have managed to develop an abstraction that will save them from the complexity snowballing that may kill roam and did kill google wave. I should probably think about joining with Athens.)
Permacomputing ethos. It's important for the purposes of a piece of communication software that it be simple, reliable, maintainable, and open source. It is for everyone, forever.
But we are going to ask users firmly for donations. And I guess I might apply for some grants if it turns out we need that and if I can make a case for that what we're doing is materially important (I believe it is, but I don't know if I'll be able to convince funders of that, unless we get a little bit more ambitious).
If you'd be interested in helping to build this, lodge a reply to this thread on mastodon HERE. (EDIT: we probably shouldn't just do it ourselves. We should probably contribute to Athens.)