Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2024 Poal.co

911

So I've flip flopped so many times on what this software actually does and that's because it can do a lot of things. One way to think about it is as a serverless environment for front-end apps that has a backbone behind it to be social.

One downsite that previously existed is that someone would have to configure their build and init files correctly to run your app. Possibly wrecking what they already had there and possibly making it difficult for users that just want to run an app to figure it out.

Well now a url of the form "/app/{appname}" run that app. If a new user signs up on such a url it will automatically configure them to run that app by default. This gives them a config they can then tweak if they want. Plus they can then rerun the app just be revisiting the domain and they don't need your link.

So for example:

https://js.lifelist.pw/app/chat
https://js.lifelist.pw/app/notebook

Still if a user goes to the domain directly "/" as their first signin they will end up configured to run the chat.

So this is a lot like Codepen or Jsfiddle except they have a data store for each person that runs your fiddle which can be used for subsequent runs and they have a peer discovery system for finding other people running your app so they can do social things.

If you need to know how to configure an app to be the default you can go to "/u/{appname}". For example https://js.lifelist.pw/u/notebook. Then just copy the build and init.

That's also a really good way to learn how to build things in it too.

So I've flip flopped so many times on what this software actually does and that's because it can do a lot of things. One way to think about it is as a serverless environment for front-end apps that has a backbone behind it to be social. One downsite that previously existed is that someone would have to configure their build and init files correctly to run your app. Possibly wrecking what they already had there and possibly making it difficult for users that just want to run an app to figure it out. Well now a url of the form "/app/{appname}" run that app. If a new user signs up on such a url it will automatically configure them to run that app by default. This gives them a config they can then tweak if they want. Plus they can then rerun the app just be revisiting the domain and they don't need your link. So for example: https://js.lifelist.pw/app/chat https://js.lifelist.pw/app/notebook Still if a user goes to the domain directly "/" as their first signin they will end up configured to run the chat. So this is a lot like Codepen or Jsfiddle except they have a data store for each person that runs your fiddle which can be used for subsequent runs and they have a peer discovery system for finding other people running your app so they can do social things. If you need to know how to configure an app to be the default you can go to "/u/{appname}". For example https://js.lifelist.pw/u/notebook. Then just copy the build and init. That's also a really good way to learn how to build things in it too.

(post is archived)

You are currently inside a comment thread.
Click here to see all the comments (7).
[–] • 0 pt

With webrtc for the peer to peer. There is what's called half a server.

So there is this new development concept called serverless. There really is a server but the idea is that there is no application specific code running on the server. So you can get aws to host your application. You code everything on the front end and aws gives you some really generic/abstract functionality on the back end. But that means they can run the same tiny/optimized/micro-service for every customer.

This is a similar concept but instead of the application being isolated it's social. Part of the backbone is seeing usernames of other people who've chosen to announce they are running the same app. Seeing a webrtc contactable address to reach out to them if they've chosen to announce that. Having each user have their own private key-value store. Giving them a public key-value store so people can know things about them.

The other aspect is that forking works different. You replace individual functions and set the preference for import in build. Of course just one person can figure that out and publish it as an app.

So in "global" you put just named function declarations so they can be easily overwritten. Then anyone can "#import" inside of their code (not a typical javascript thing) from other users. So there are all kinds of users that just offer functionality through imports. There is a peers user, a keys user, and monaco user (provides a professional html IDE text editor).

[–] • 0 pt (edited )

More ideas to help users communicate on the same app that aren't done are opening a websockets connection to the "server" for each running app and then they can issue communications to each other that will pop out on the other user's websocket.

Also a basic mail system like what voat/poal/reddit/phuks/email has where you can post a message and they will get it when their app looks at the inbox. That way you can communicate from your app to theirs even if they aren't logged in.

Those aren't implemented but the idea is to provide anything and everything you could think you could use.

My goal is to think of what app couldn't be developed on it and then think about the tools I would have to give it to make it so it could be developed.

But soon I also plan to make a "peerexchange" user that would let people '#import' some resources to make swarms easily. It would just use the already existing "location" service which is just announcing which app you are on and the webrtc provided by the "#import peers" user. The users would find the last 25 people who said they are using they app, confirm that they can be talked to with webrtc, maintain a list of who is still live, and exchange with other peers.

And all your app would need is '#import peerexchange'; function () { peerexchange(getpeers=>{ //getpeers() will always tell us who the peers are.
});
}

[–] • 0 pt

All I heard is "Everything as DevOps"(not really I'm just joking)

See I'm one of those guys who pushes against this whole everything as devops and treating servers as cattle instead of pets. I might just be old fashioned but I think there is still some value in sticking with old ways of doing things.

[–] • 0 pt

I use zero devops. Touching kubernetes for every little thing you do is just a way of excluding people from your projects, increasing your personal workload, and making more money. It's bullshit. At least the way it's used.