all comments

[]x0x7 -0 points

The best thing is that it is extensible just by editing one function. You don't even need to fork a whole project.

You just right the new version of the function in your global and add your username to build.

This is similar to how in Doom WADs you can replace media items through a system of layered WADs. But now it's actual software.

[]Chungus -0 points

[] -0 points

[]x0x7 -0 points

The downside is that I have a server running in a tab to support the chat. Had I coded the particular app a different way that wouldn't have been needed but I just wanted to launch something. And I'm too excited not to share it.

Anyway if it doesn't work try launching the server. Use Firefox Multi-Account Containers to sign into the server and run it.

user: chat-server
pass: chat-server

I've backed up the code into another user in case someone fucks with it.

Next I need to make it easier to browse other user's code, because that's kind of the idea.

[]x0x7 -0 points

It would be entirely possible to build the chat client to let you pick a user to be the server but I haven't done that yet. Part of me wants to leave problems in place for others to solve because it's all front end and communal.

Also it would be best to merge the server code and client code into one system so when a server signs out another user can take over being the server. A list of common users could be attacked to the code to act as seeds. Users could exchange lists with new users and when a user signs out a consensus could be formed about who the new leader is.

A persistence system is already available in the form of a private key value store per user. So that can also be used to remember peers from session to session.

So basically if it sucks it's only because of how I coded it now.

If you want to play with the key value store it's /skey/set/{key} and /skey/get/{key}

The set uses post data.

To play with webRTC you can import peer.js from and then register the id you get from them with /peer/register/{id} and get other user's id with /peer/getid/{user}.

Then you can use that information to try to make a connection with them.

Also the global file only accepts named function declarations. That's intended to make people code more flat so that people can extend your code with another named function. If that seems to restrictive to code something useful, just remember that linux is built in c with a single namespace, and it's plenty complex and capable.

You can code closures inside of named functions still and the init file can do anything and is meant to function like a bootloader.. launching some entry point, or points, in some big library of named functions.

It is encouraged for you to break your code into pieces and to use names that seem kind of application specific.