Nextty: a radically collaborative computing environment
I want to build a community computing platform. It's remote-friendly, but synchronous. It's orders of magnitude more immersive and cooperative than screen sharing. You could call it a chat app where you also write code... or a futuristic repl with your buddies. It's a computational space where you solve problems together. As people start working in this kind of environment, the lines between programming and other communication blur. Everyone in the community ends up writing, or at least invoking, little programs all the time, even if they're not "software engineers."
There's a transition that's just begun in computing that makes this idea suddenly and increasingly viable. The cost of expressing computational thought has begun an exponential decline (just like solar energy, light, and transistors) due to recent innovations in generative AI. The population of people capable of performing computational tasks is going to explode, but not in today's computing environments.
One of the defining characteristics of communities is that they inhabit spaces. Communities can be made up of one or more spaces that are visually and functionally distinct and evolve over time. User interface elements can be built to represent common computational objects. Objects can be manipulated in multiple ways. Someone with more of a computing background might choose to manipulate an object in a lower-level way. But other users might manipulate the same object through a more traditional user interface.
No one's ever said "I love what you've done with the place" about a slack channel or a zoom call. If you've ever worked in a science lab with a healthy culture, you know that people do say that about each others lab benches. People pin things on the walls that reflect their personality. People draw doodles on each others' whiteboards while they're out at lunch. People are social. People personalize the form and function of spaces if you let them. Remember MySpace?
So what would a specific room, or channel look like? Well it would be a folder on a computer somewhere.
./example-channel
├── access.toml
├── agents
│ ├── decision-summarizer.md
│ └── visualization-helper.md
├── channel.sqlite
├── channel.toml
├── community.toml
├── profile.ts
├── readme.md
└── views
├── cover.html
└── task-bar.html
access.tomlwould specify who can read/write/evaluate/search/mention/react/etcagentswould be a directory for LLM-backed bots. There would be some configuration specified in front-matter. You could also write non-LLM agents too. Communities can install plugins that make certain LLM providers or open source libraries available to every channel in the community so you don't need to set it upprofile.tsis a set of code that runs every time the channel node boots up. It's for configuring common commands (think.bashprofile)readme.mdopens in the sidebar of the UI by default. It's a cover page to orient onlookerschannel.tomlspecifies some basic configuration and rulescommunity.tomlis autogenerated and has details about how the channel connects to the community server.- The
viewsdirectory contains html files (I think?). You can overwrite system partials and customize UI here. Very much TBD.
Not every channel would need to be on the same hardware. Some communities would run all on one box, but in other cases, you might want to have a channel running on your own laptop. That way, when you're working in "your office" it's really fast. Plus, you can use it on an airplane. The software itself isn't prescriptive about how this is done.
If you're having trouble imagining this applying to a chat-repl, that's OK. It's hard to imagine. It's different from any computing environment you've ever been in. It's social and vibrant. It's a place to gather, learn and teach. It's a breeze to pick up but extraordinarily deep and rich. You can get lost in it.
OK, let's try a thought exercise. Out of all the digital communities you've been a part of, what was the best one? Now imagine what that community would be capable of if instead of passing around links to various vendor-backed web apps on slack, people could exchange references to computational objects in the digital co-working space. There would be common abstractions for querying and visualizing data across all kinds of objects. There would also be batteries-included tools for what we'd conventionally call "telemetry." The entire computing environment would be highly observable and visible. The entire organization would share a common set of tools for seeing change over time.
Everything would default to open. If you're working in a science lab, you can see what's on your coworkers desk. In this community, you can also see what's on your coworkers desk. In certain situations, that kind of openness doesn't make sense. Not every room has the same permission structure. There are locks and keys. Some people are read-only in some spaces. Some people can execute commands. Some people don't even know the room exists. But that's not the norm. The norm is open.
For some communities, security and access control would be quite important. And while it's true there's a security burden on the community, today's conventionally run organizations have enormous security liabilities as well, they're just just somewhat obscured by vendors. Instead of your data being in one place where you can control it and monitor it, it's in who-knows how many organizations hands.
While this type of computing is decidedly expensive, the software behind it would have to be free and open source. The community software platform offers tremendous value to organizations, and surely that value can be captured by people offering to help build these organizations. But, in order to make computational spaces available to all kinds of people and organizations, the foundational software would have to be free like water. It would have to be something that you could set up on a VM in 5 minutes and get started with. But it would have to have enough complexity to allow communities to grow and evolve over time into elaborate spaces that suit various needs.
Note: this isn't a hyperscale idea. We don't need the software to scale gazillions of users because no community will be that big. Because this software is run by the organization, even if they pay someone to help, the software platform only needs to accommodate the largest types of communities. This smaller scale has implications about the platform. More will be done with flat files. If there's a need for a database, SQLite will get used and it's baked into the platform.
Other note: if you're thinking "well this would never work at ___" you might be right. I can't imagine the security team at my day job ever saying yes to this. But not all computational communities look like your workplace. And I think over time as the software matures, it might support more and more types of organization and you might find yourself surprised who starts using it.
So what's next? well... I think I need to start by getting an MVP together. Once I get some of the essential pieces in place, I hope to start developing on the platform. If the code is on github, it'll be a side effect. To get a sense for how this feels, I'm already using a chat app to jot down ideas and to see how things feel (it feels good!). If you want to get involved give me a shout out on the dead bird app. I'm gonna migrate somewhere else soon, but haven't yet.