We're using electric in building uxo.ai. How do you envision electric being used in this case? We're using it to build the UIs for controlling and interacting with uxo, but a really powerful use will be to pull all the extracted data to a knowledge base whose interface is built with electric (the knowledge base would be similar to some ideas I outlined here https://github.com/subspace-ai/subspace). So you can build simple ad hoc interfaces on top of your knowledge base from simple electric functions, and the knowledge base can easily ingest data from the Web and desktop apps via uxo.

We're also open to collaborators, particularly people who have used electric and are into AI 😊

> How do you envision electric being used in this case? Sidecar AI agent with you at all times connected over socket. And, soon, multimodal language models means you can talk and it will talk back.

composable differentiable UI elements=components will be choice. Tracking global state in an elegant way will be key.

let me take a look at your github and see what i can offer if anything 😅

the github repo doesn't have much, but the readme outlines an idea for a PKM+REPL+RAG app, into which I could see http://uxo.ai ingesting data from the web and other desktop apps. which is the kind of interface i'd like to have for an AI agent

Yeah what is a sh0rtcut is it a jupyter notebook style integration that fetches data and runs code a'new? is it a buncha mini baby lektrik kompilers that live inside the mothership Compiler?

(or what are some potential ways you envision it)

@U05095F2K out of curiosity have you made this yet 😄

didn't quite understand what you mean, but let me explain a bit more i envision sth like subspace-ai (as described in the readme) which is your roam-like PKM. inside the PKM, you can have (1) regular text nodes (like in roam), (2) code nodes, which you can execute manually like in a REPL or a Jupyter cell (where the output could be an e/fn that gets rendered), and (3) code nodes that execute an e/fn and continuously render some UI element, possibly based on the data that is in the PKM or any other data source. I would use this PKM+REPL in and of itself like i use roam + some things i currently run from the terminal, e.g. triggering some ML training job etc, and would build custom dashboards with info that is relevant to me, nothing more now, in addition to that there is http://uxo.ai, which is a separate product (that https://www.linkedin.com/in/mattias-arro-b63a9110/ and my https://www.zafstojano.com/ are working on). Currently we are not much focused on integrating with or building out subspace-ai, but i could see a useful integration where from subspace-ai I call into uxo-ai to either fetch data from the web, or interact with some web or desktop UI and parse/visualise the results from subspace-ai we are also looking for people who know electric to join uxo, so if this general topic seems interesting we could have a chat

Roam is super cool and, new info for me. Let me have a closer looksie. And also, sounds cool! I need to step away and think about all this for a sec.

of course 🙂 there are interesting alterntives to Roam Research, particularly tana.inc, which also has some ai features but is more focused on the less technical user who doesn't need as much control as us programmers would want

The idea behind uxo where I could scrape and also create new interfaces for the data is mind blowing.

Truly composable data sources as interfaces

to quote one of my favorite songs, that shi cray.

I was thinking about how I can pre-load an AI agent, connect them over socket, talk to them like I would talk to a normal user, but then have my user also able to talk with them. I mainly want ai agent over socket, but integrating a mini ai agent as an operative function would be clutch.

for example, with the uxo use-case • GPT3.5 or haiku scrapes the data, • assembles some sort of reusable data form[at] • creates some electric components with source and css revealed in browser frames • tell the component to be "live" or "static / wait for clicks"

I suppose hitting the api is just-as-good-as having a live agent to query, at this moment in time. What's the process of scraping or subscribing to data? (question i have) and also what is the ideal output (RSS for example, was a new standard that was adopted joyfully by many). Would it be better to issue a new electric internet standard for live querying differential updates

@U055PQH9R4M Currently you can use uxo locally on macos. It comes with an Electr*on* app that just renders an Electr*ic* UI that is a Jupyter-like interface to run simple web automation code snippets. But it also exposes an nrepl port. The code snippets control a Chromium browser and can scrape, autonomously navigate and perform basic actions on the web. The key is these automation scripts have an AI layer built in, which allows you to define what data structures get extracted (using a Pydantic-like schema library) and then return these extracted data structures or use them to further drive your automation script. The AI layer makes the automations generic enough that they can work across a broad range of websites, usually. You would use this desktop app to develop / debug some automations you need to run, or run personal automations which e.g. require your login and need a human-in-the-loop workflow. For example, one such automation might go to a url, navigate to the page that has articles, go through each article and fetch+returns titles and full text of articles as json. Such automations can be auto-generated based on plain English prompt of what's needed. Below is Python, but Clojure will also be available probably since the core is written in clj.

class NewsStoryShort(BaseModel):
    title: Optional[TextNode] = Field("The title of the news story")
    text_short: Optional[TextNode] = Field("A short introduction of the news story")
    time: Optional[TextNode] = Field("The time of the news story")
    full_link: Optional[List[LinkNode]] = Field("The link leading to the full news story")
    download_link: Optional[List[LinkNode]] = Field("The download link of the news story")

class NewsStoryFull(BaseModel):
    title: Optional[TextNode] = Field("The title of the news story")
    text_full: Optional[TextNode] = Field("Full text of the news story")
    time: Optional[TextNode] = Field("The time of the news story")

class ArticlesPage(BaseModel):
    news_story_short: Optional[List[NewsStoryShort]] = Field(
        "A container element for a news story article."
    )

def scrape_articles(src_url):
    uxo.page.navigate(src_url) # set url on location bar
    uxo.ai.navigate_to( # use AI-driven navigation
        "page with a list of articles",
        example_hrefs=[
            "/articles",
            "/stories",
            "/investor-relations",
            "/about",
        ],
        max_num_pages=5,
    )

    ret = []
    for ret in uxo.ai.page_extract(ArticlesPage):
        for article in ret.short_articles:
            article.full_link.click()
            
            article = uxo.ai.page_extract(NewsStoryFull)
            ret.append(article.to_dict())
            uxo.page.back()

    return ret

@U09D96P9B I saw their docs mention "agents" but the demo video is just about interacting with different LLM APIs. Do you know if they have sth ready?

Cool. I have a question: is there a way or a roadmap way to restrict agent access to data to very very specific parts? I'm thinking about how to incorporate AI agents generally into an application that has lots of not-shareable customer data and it would be catastrophic to have a front-end-facing AI-agent introspect the data and reveal it. so, how to : have front-end facing AI agent and also, not share all the data

Currently there is no such feature, but this seems like a sensible thing to add, shouldn't be too difficult. There could be two types of restrictions: • URL regex, which the agent would never navigate to (or if it did due to some JS redirect, it would terminate) • configurable CSS selectors, which contain sensitive info; the agent would mask these selectors out in the image/html input to the model. if you control the html of the app, just add class="sensitive" and we can filter it out Such heuristic restrictions are the only ones that can provide real guarantees, but in this case it seems a reasonable approach. Perhaps we should set up a call to discuss your use case?