▢

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

  • (replies can have their own separate read permissions, which can sometimes make the child visible while the parent is invisible, but in these cases, the reply relation linking them wont be visible. For a reply relation to be visible, both objects must be visible.)

• Edit: People who can change the content of the object, for instance, if it's a comment, who can change the text.

  • (Edit history is kept. Edits can be reverted.)

• Reply: People who can add objects as replies to this object. This will usually be a very broad group.

  • The project maintains a "bigtent" userset, a group of groups of people we can sorta mostly tell are usually respectful and wont vandalize anything. It's generally safe and beneficial to allow replies from bigtent.

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

  • Again, there's a way we can make this much more user friendly that we definitely wont bother coding in the first version. It would be... a browser-local storage that remembers the names and a tiny bit of the text content of last hundred or so objects you've looked at or interacted with recently. Those can then be searched over when you prompt the editor to grab an object ref. Roamresearch already does something like this, and it works great.

From these few systems, much is possible:

• Forum

• 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

  • realtime updating

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

How I would like to go about this

• Every page should render properly without javascript.

• Typescript is a pretty good language with a very good type analyzer. It also lets us use the same code back and front, and everyone knows JS, so everyone can use TS. Its compilation target, javascript, will always have ubiquitous runtimes that people know how to program for. It makes it easy to use any web API through TS because of the JS compatibility.

  • style guide: No semicolons (typescript's type checking removes the few situations in JS where not using semicolons can get you in trouble)

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

  • Ultimately should move towards being federated, or p2p?

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