Currently, playtest tests the last state of the graph.

To test: Make a new graph with a hello world. Try playtest, should return nothing. Try playtest again, should return input.

This was probably always a bug, actually, but we didn't notice because process graph was being called on every action. As we are not processing every action, we'll need to call the process graph before playtesting.

super-reality#44

• Make a new editor in Thoth (like Ent Manager)
• Add a file uploader, that will let you upload an HLS video
• Send the video file through a web request (axios)

Right now, when I press update it spins up a new entity, so I have multiple responders instead of replacing the old one. This happens on Discord, XREngine, etc.

Click the link below to watch the video:
https://www.awesomescreenshot.com/video/8705534?key=ceacf0577072402a3a0b5f9aaf856cbb

super-reality#3

Create a Calendar Editor (like Ent Manager or Event Manager).
Include a visual calendar, it will fetch data (just make temp/static data for now) that will fill the calendar, be able to add events there and remove events
https://www.npmjs.com/package/react-calendar

Actions:

• Look At player
• Wave player

Right now we are directly using Axios to call other endpoints in many of our new Agent components... this is not an ideal pattern.

We should replace these with a typed interface and handle them the way other stuff is handled... @michaelsharpe has some thoughts on this, I'm sure.

We are storing conversation, facts etc in the events table, keyed by entity. We'd like to be able to view all events in the table, filter by entity, filter by who the entity is speaking two, and sort by date. We want to be able to CRUD individual entries into the event table so we can manipulate, test and debug conversation etc.

Test video: https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8

We don't want a whole table for a feature that is not first class. We want to remove the wikipedia model and instead use the events model to store the JSON for individual wikipedia entries. This way it can be used in event memory easily. If eventtype is wikipedia, main event data is the wikipedia response json, and we use one of the other fields to key the name of the wikipedia article so it's easy to find later... something like that...

Right now whenever anything changes (entity is marked dirty) we are attempting to destroy the entity and rebuild it... this is not happening cleanly though.

If the exact spell used by the entity is changed, we should destroy the old instance, create a new instance and attach it to the client. Ideally we don't need to destroy the client, but that might be easier. In either case we need to make sure that we aren't leaking memory or holding on to old references.

If the API key etc is changed, we'll need to completely destroy and restart that client. We want to keep the entity itself alive, but, for example, if we update Discord, we should destroy discord client and restart.

These services are meant to be long-running, so we should make sure they are starting and destroying properly and be meticulous about this.

super-reality#57

Right now we are using a purpose-built "Input Desctructure" component to get data from the agent and break it up without needing to define a lot of inputs per graph. This is not ideal. Since we end up using all of the agent data in lots of places, it makes out graph have a lot more sockets and nodes. We want to define a new agent type that passes all of this data in a single socket.

The agent destructure can still existing, and should have a corresponding restructure component even, but it should accept a specific socket type.

We might think about templating these nodes so a single structure / destructure can have a dropdown of template i/o or a custom option

Source URL:
https://www.adminium.io/dashboard

Check if the client is bot, if so create a stream from the file and apply the same way with the LipSync script from microphone

Right now, in our server we are searching for spells without keying by user, and so every user can see every spell.

We want every user to only be able to see and interact with our own spells. However, in local development, we will need to figure out how to have this make sense with our login system.

Ideally for local development we will just use the user ID 0, for example, so we don't need to worry about the login system, but we should connect with @michaelsharpe on the best strategy for this.,

Request Data Structure:

payload: [
  {
    client: 'Discord',
    name: 'discord_api_token',
    type: 'string',
    defaultValue: '',
  },
  {
    client: 'twitter',
    name: 'twitterConsumerKey',
    type: 'string',
    defaultValue: '',
  },
]

client value can be removed (?)

I think this could be good, feedback appreciated

Source URL:
https://registry.terraform.io/providers/CastAI/castai/latest/docs

Add in the database Calendar Table and function to add/remove events, table data:
ID, Name, Date, Time, Event Type, More Info

Right now, running spells requires no authentication on the server... okay, that's not good!

We can see that we are using "noAuth" in /server/src/routes/spells/index.ts

We should figure out a proper strategy that is congruous with the Latitude API, or we should think of how Thoth manages it's own needs but can contact external providers for user auth (in which case we provide a default anything-goes provider service to mock Latitude API) along with Latitude model services.

https://github.com/Appen/UHV-OTS-Speech

Check cluster savings potential - found a site that claims to automatically https://console.cast.ai/external-clusters/new?org=f88d5948-7f95-4de7-8eda-3ea345f6f6ed

Source URL:
https://console.cast.ai/external-clusters/new?org=f88d5948-7f95-4de7-8eda-3ea345f6f6ed

Doesn't load

Source URL:
https://52.24.56.77:3001/home

test phillip, and then xr engine please if different :) https://console.cast.ai/dashboard?screen_hint=SIGNUP&org=f88d5948-7f95-4de7-8eda-3ea345f6f6ed

Source URL:
https://console.cast.ai/external-clusters/new?org=f88d5948-7f95-4de7-8eda-3ea345f6f6ed