I'm working on Pocketdata - a personal, private AI data plane.
The idea is to take boring components: PostgreSQL, Bifrost (LLM gateway), Open WebUI, LanceDB, Agentgateway (MCP and OpenAPI gateway) and deploy them in Fly.io. One Fly.io "org" per user. The closest equivalent is blaxel.ai, but it caters for AI SaaS startups, not individual customers.
The combination of the fact that Fly secrets are visible only from within the apps, distroless containers, and transparent data encryption for PostgreSQL assures that the service (Pocketdata) provider cannot access their data, only the infrastructure provider (Fly.io) theoretically can, but practically speaking, this gives an extremely high degree of privacy assurance.
Hey! Your project looks very similar, from a conceptual point of view, to what I'm doing with https://github.com/superegodev/superego. Would you like to have a chat about it? Email in my profile, if you're interested.
> It seems like a web version of claude code + skills + marketplace, but with an encrypted database, and permissions that let you feel safe using yolo mode. I’m going to try it.
Architecture TLDR: In Fly.io, org-per user, manage keys in Fly secrets. A Postgres db with transparent data encryption (TDE), the master key is stored on user's computer in the keychain or in the password manager. Thus the nobody can read the data at rest. All containers are distroless so nobody can ssh onto them. Postgres is backed up via pgBackRest to Wasabi object storage with customer-provided encryption keys that are injected into the containers via Fly secrets.
Apart from the database for record-like things (chats, emails, tables), vectors for larger things (such as web pages) are stored in serverless LanceDB on Wasabi, too.
Agents/apps themselves (Open WebUI, Zero Mail, etc.) are separate Fly apps, and have their separate schemas and users in Postgres. They also cannot go to public internet directly (prohibited via https://community.fly.io/t/new-feature-network-policies/1917...), only to Postgres, Bifrost, and Agentgateway.
Postgres, pgBackRest, pgBouncer and another Go sidecar for pg (a la Pocketbase, but with Postgres backend), live in a single container managed by Horust. Bifrost and Agentgateway live in separate containers, but the same Fly machine. This machine might be 1.5gb, 4 vCPUs. LanceDB is on a separate machine because it needs burstable memory and may be infrequently used.
All machines (core, lance, and all individual app/agent machines) are suspendable, so they almost don't cost anything when not in use.
It's not super easy to port a library with domain-specific ML/DS algorithms built around Pandas, such as accepting Pandas dataframes as arguments to its functions and class constructors.
I don't buy this "object storage + Iceberg is all you need for OLAP" hype. If the application has sustained query load, it makes sense to provision servers rather than go pure serverless. If there are already provisioned servers, it makes sense to cache data on them (either in their memory or SSDs) to avoid round-trips to object storage. This is the architecture of the latest breed of OLAP databases such as Databend and Firebolt, as well as the latest iterations of Redshift's and Snowflake's architecture. Also, this is the approach of the newest breed of vector databases, such as Turbopuffer.
For OLAP use cases with real-time data ingestion requirements, object-storage-only approach also leads to write amplification. Therefore, I don't think that architectures like Apache Pinot, Apache Paimon, and Apache Druid are going anywhere.
Another problem with "open table formats" like Iceberg, Hudi, and Delta Lake is their slow innovation speed.
I buy into some of the hype. but only for majority use cases, not for edge case specialisation.
As ever, at FANGMA-whatever scale/use cases, yeah I’d agree with you. But the majority of cases are not FANGMA-whatever scale/use cases.
Basically, it’s good enough for most people. Plus it takes away a bunch of complexity for them.
> If the application has sustained query load
Analytical queries in majority cases are not causing sustained load.
It’s a few dashboards a handful of managers/teams check a couple of times through the day.
Or a few people crunching some ad hoc queries (and hopefully writing the intermediate results somewhere so they don’t have to keep making the same query — I.e. no sustained load problem).
> real-time data ingestion requirements
Most of the time a nightly batch job is good enough. Most Businesses still work on day by day or week by week, and that’s at the high frequency end of things.
> slow innovation speed
Most people don’t want bleeding edge innovative change. They want stability.
Data engineers have enough problems with teams changing source database fields without telling us. We don’t need the tool we’re storing the data with to constantly break too.
Every once in a while, before falling asleep I enter a "mellow" state in which I can conjure mental images dramatically more vividly than normally. I would say that normally it varies between 10-50% of vividness (also depends on the state of mind, the day, whether I'm under the influence of different chemicals), and in this state of mind it's 90%+ vivid.
And I don't confuse this state of mind with lucid dreaming: I had spontaneous lucid dreams a few times. They were not very vivid, just as my normal dreams (I dream in images, and they are maybe around 50% vivid).
So, there is definitely a way to experience variation of vividness of mental imagery, by a single observer.
I have this too, especially when I’m really tired. It’s such a surreal yet refreshing experience. I can hear the most beautiful melodies my ears have ever heard, even though I don’t have a musical bone in my body. And I jump in and out of various vague visual scenes (like staring into deep space) during this.
It always makes me question if I’m dreaming or not - and often, it’s the last thought I remember before I actually drift off to sleep. All of this seems to happen during the span of 60 seconds max (judging from my heartbeats), but this has categorically been debunked when my wife once told me I was actually snoring for a couple of minutes.
The melody thing I assume I have not suddenly become a master composer, rather the part of my mind capable of judging whether the music is any good has become impaired.
> This one seems theoretically more interesting than some others but practically less useful.
Are there other factors why you think AutoBNN is not practically useful, apart from being based on the wrong foundation (which was a mistaken belief of yours)?
The big question is whether we really want more centralised cloud applications of this sort in the AI future, with its potentially exacerbated risks of data breaches, identity theft, spam, etc.
Having a "Rama" for local-first, truly distributed (Solid Project style), self-sovereign-identity based apps would be differentially better probably.
The idea is to take boring components: PostgreSQL, Bifrost (LLM gateway), Open WebUI, LanceDB, Agentgateway (MCP and OpenAPI gateway) and deploy them in Fly.io. One Fly.io "org" per user. The closest equivalent is blaxel.ai, but it caters for AI SaaS startups, not individual customers.
The combination of the fact that Fly secrets are visible only from within the apps, distroless containers, and transparent data encryption for PostgreSQL assures that the service (Pocketdata) provider cannot access their data, only the infrastructure provider (Fly.io) theoretically can, but practically speaking, this gives an extremely high degree of privacy assurance.
The latest update on the project: https://engineeringideas.substack.com/p/tasklet-is-the-o1-mo...