Fosforescent came from the goals of making truly decentralized organizations an everyday reality, and allowing people to more easily pool resources and efforts to execute tasks, and redistribute the resulting gains. It is meant to be a proving ground for decentralized decision-making processes.
But that’s in the abstract. In order to be a proving ground, people need a reason and a way to use it in everyday life. That means they need to be able to use it to make money or get things done. And so, the practical application of all these features will be as a task market which allows people to work together to get revenue through projects, and distribute that revenue according to the individuals’ contributions. Once this kind of task market exists, users can get paid for helping to build it, as well as vote on which features to implement, etc.
How does this work?
The general idea for the collaborative process is to support decentralized profit-sharing organizations by providing tools for users to directly propose and accept edits, as well as engage in voting, and other collaborative activities.
An organization is largely a combination of a few things: its people and their goals, it's projects, or organizational goals, its policies/procedures, its assets, etc. Procedures are ultimately just tasks that will get assigned to people (or other agents) under certain conditions. Goals, like projects are also essentially just very broad tasks. (e.g. “Todo: get healthy”). So an organization is essentially made up of a set of tasks that people (or other agents) make, either as individuals or through committees, plus tasks that are assigned as per established procedures.
This is where Fosforescent comes in. The basis of Fosforescent is a runtime for both human and computer tasks. Human tasks can be described very simply as a set of tasks and their subtasks, or dependencies. E.g. when you make a website, you also may have to create a design, register a domain, choose a website builder or code it yourself and host it. Or you may just pay someone to do that. You can look at the task from a “zoomed out” level, or “zoom in” to the details.
Being able to zoom as far out or into a task as necessary, and updating any subtasks on the fly is critical to maintaining the flexibility needed for dealing with tasks that involve humans. However the structure inherent in this set of tasks and subtasks is a tree or graph.
And with that graph you can implement a term graph rewriting system, and use it as the basis for a programming language runtime. Then, you can implement a programming language which treats both human and computer tasks as first class citizens.
Not only does this allow you to intertwine human and computer tasks, but also it allows you to do things like:
use variables in those typed human (or computer) tasks — for instance run a procedure with a server name repeated dozens of times throughout many steps
use filter/map/reduce operations on repeated tasks — for instance if you have a guest list to an event, execute procedures over that whole list
have typed human tasks — for instance a todo which requires you to enter your name, submit a document, etc.
compose those typed tasks — for instance let’s say we’re trying to execute a procedure that requires a document. Instead of entering the document, we can enter a procedure for producing that document, and execute the result as a larger overarching procedure.
Where is it now?
Currently a prototype implementation of the runtime in typescript is in progress. Multiple proofs of concept have been produced regarding the generation of subtasks with LLM’s, including the generation of alternative subtasks, as well as time estimates.
The design of visual language in react/typescript is largely fleshed out. Many pieces of it have been implemented which will need to get re-integrated with some recent updates.