Update the current Eliza UI to the latest version available

[snobbee]

A new version of the client is available, we need to bump the current instance of the Eliza UI we host to this new version that brings some functionality improvements.

elizaOS#2038

Acceptance criteria:

User interface is updated to new Eliza UI.

[snobbee]

A portion of this task involves updating the Eliza UI chat code to automatically retrieve all room messages, rather than only fetching the response to the sent message as it currently does.

The PR #232 was updated to support that functionality. there are some improvement that are still ongoing.

[ArsalonAmini2024]

@snobbee @mihai169 we'd like to have a dev server, test server, and production server. We want to have an instance of the UI on the test server to do End-to-end testing/manual testing with the agent before releasing to production servers.

[snobbee]

@monilpat please review PR #268 thank you

[snobbee]

@snobbee @mihai169 we'd like to have a dev server, test server, and production server. We want to have an instance of the UI on the test server to do End-to-end testing/manual testing with the agent before releasing to production servers.

@ArsalonAmini2024 for the initial deployment and to save time I will update the existing Eliza UI/agent we have with the latest update in sif-dev that way it will include the github integration functionality.

For adding multiple environments of deployment we need to understand what branch need to be deployed where, we also need to add some CI workflows so that those deployments are happening either automatically or with a manual trigger from the github action page to remove human errors with manual deployments from command lines.

Let me know if you are fine with that.

[ArsalonAmini2024]

@snobbee thanks for addressing my comment,

RE - for the initial deployment and to save time I will update the existing Eliza UI/agent we have with the latest update in sif-dev that way it will include the github integration functionality.

Sounds good. Makes sense, we should probably have a secure URL for accessing this UI - this used to be something - http://eliza.sifchain.network:5173/ now it's not working.

Did we buy a domain name? we may want to have it on a URL that makes sense app.realityspiral.com or something.

RE - For adding multiple environments of deployment we need to understand what branch need to be deployed where, we also need to add some CI workflows so that those deployments are happening either automatically or with a manual trigger from the github action page to remove human errors with manual deployments from command lines.

I'm going to break that request out into a separate Issue but yes, we want those items setup ^^.

[jzvikart]

@ArsalonAmini2024 FYI, this was already discussed and started here: #105 (comment)

[jzvikart]

If we need three environments I suggest we just use three diferent folders and parametrize everything by environment name, e.g. /opt/eliza/{dev|test|prod}, including URLs https://eliza-{dev|test|prod}.sifchain.network/ or https://eliza.sifchain.network/{dev|test|prod}, database connections, etc. This way we don't have any extra work.

[snobbee]

here is an update about the Eliza UI deployment:

1. the previous eliza UI that is hosted on the eliza server (OVH) http://eliza.sifchain.network:5173/ was updated to the latest Eliza UI version
2. the new Eliza UI integrates the github client
3. new domains were created and enable SSL and DDOS protection for both the UI and the API: https://eliza-dev.sifchain.network and https://eliza-dev-api.sifchain.network
4. @jzvikart and I attempted to sandbox the eliza backend within a docker but the docker containers ended up eating most of the disk storage available, the disk size seems to be very limited, so the eliza instance is currently running as a standalone process under the sif user on the server. This will change as we found a solution for the sandboxing that works with @jzvikart

here is a screengrab of the github client in action using the new Eliza UI deployed:

Screen.Recording.2025-01-18.at.00.23.39.mov

cc @monilpat @ArsalonAmini2024 @mihai169 @jkbrooks @jzvikart

[monilpat]

Amazing work - we should probably filter based off of the user as I am seeing your messages see:

Screen.Recording.2025-01-17.at.3.45.05.PM.mov

[jzvikart]

I've added more space. I've also cloned the current environment data to test and prod. The environments are deduplicated using btrfs which means they are space efficient (i.e. they don't use any space except for data that is exclusive to them).

IMPORTANT

Since the services are running with publicly accessible ports, we need to secure them. We should assume that whatever is running on this machine can be lost, stolen or compromised at any moment, and that the machine itself can be easily taken control of and potentially used for illegal activities. We should assume that this will eventually happen and that the only question is when.

Some guidelines:

• We should treat the entire system as disposable and use snapshots and scripting to be able to quickly restore it from trusted initial state (or snapshot).
• We should use docker to sandbox and isolate environments from each other and from host OS.
• As much as practically possible we should limit access to running Eliza instances, i.e. by using authentication, random/non-crawlable URLs, SSL client certificates, VPN, and similar approaches.
• We should be selective about who we share access with, and periodically rotate authorization schemes.
• We should use separate API keys and set limits on them, and regularly rotate them.
• We should use Cloudflare as a front-end, enable mandatory origin certificates, disable direct access to origin, enable DDoS protection, and proactive monitor the usage patterns.
• We should set quotas on disk, memory and CPU for running Eliza instances.
• We should add a rate limiting mechanism for requests
• We should make sure to keep the OS up-to-date
• We should regularly monitor the system for suspicious activity in network traffic, usage patterns, system logs, etc.
• We should setup regular, automated backups of any important data.
• Since Eliza itself is the antonym of security, we should assume that the system will eventually be hacked despite all of the above, and prepare contingency scenarios.

cc @jkbrooks @ArsalonAmini2024 @snobbee @monilpat @mihai169

[jkbrooks]

1. I'd like us to have this at https://realityspiral.com rather than https://sifchain.network. Mon is a bank holiday but I may be able to get our Vercel account back on Tue and we can make the transfer then. If we are actually ready for a Mon launch then I'd rather pick a random IP address or other site to use as our default until we have access to the realityspiral.com site. And if we have some way of getting it on the Reality Spiral.com website, then let me know, but I believe Splinty controls that. He is cool, but I just don't know if he would be responsive enough to make sure the launch went smoothly.

2. I don't know if here is the best place or somewhere else. I'm sure that this is getting good visibility from product, but I just want to call out that we should update the documentation link here if we update it to https://realityspiral.com/ then we will probably want to pick a subdirectory that is specific to the documentation for how to use this particular UI instead of broad-based documentation about the entire app. We could even do documentation on a character by character basis at some point.

3. I don't have issues with any of these. I believe these points should be addressed formally in tickets and an easily accessible document that we all agree to follow

cc @jkbrooks @ArsalonAmini2024 @snobbee @monilpat @mihai169