buremba

I don't get how of the personal assistant can be useful without having to see my conversational data so this is great.

Do you know if running Whatsapp in Cloud risks your account to be banned?

I'm working on a similar tool, connecting all that data to build your context graph that knows all the people and conversations and expose it via MCP. https://lobu.ai/for/personal/

My approach is requiring you to have a home device where you keep your accounts open in a browser and observing the data from there. The same applies to Linkedin, Instagram, X etc. even reading my timeline to summarize what I need to know without me doomscrolling.

Use bun when it's drop in replacement of npm, never use Bun API itself.

being opinionated doesn't mean you can attack people you compete or don't like every other week

Hi HN! I believe agents running on markdowns was the first step but instead of making the filesystem forkable/clonable I believe event sourcing on a real database is a better concept for agents to understand all the work that has been done, learn from its mistakes and self-improve. Happy to answer questions!

No it doesn't and it's simply useless. They have been trying to enable publishers to charge scrapers so that's why they're pushing this path hard.

I love the concept to use different harness frameworks in qm but a true multiplayer harness needs to support other agents and any MCP clients, including Cowork.

Making agents multiplayer is mostly a context problem. You could be using ChatGPT or a Slack bot, or a web interface and the agent needs to know you, your conversations in Cowork etc. so it can enable multi channel collaboration with your agents and your colleagues. We're working on it at https://lobu.ai

What's the rust based tui that has same capability as opencode?

Not really because you're not building a database or GUI app where using native elements & data structures help a lot with memory pressure.

TUI renderer is the one using the memory heavily so your terminal takes the heavy lifing. If you're managing the buffers and out-of-screen context good enough, Typescript can be pretty efficient.

I tried twice and ran into bugs that prevented me to trust it

Opencode gives you better defaults and a Mac/Windows app for free but pi is much more extensible and portable.

For TUIs, Rust/Go vs Typescript doesn't really makes a huge performance difference and you lose the 50x bigger community advantage of Typescript.

I would recommend using https://pi.dev/ over Grok Build with your xAI subscription at this point

I'm not sure why I'm being downvoted but I didn't mean it in a negative way.

For such announcement, I would expect them to give me clues on when I should use this model and in which cases it's the best one.

The benchmarks that they share doesn't indicate that it's cheaper to run than other models, or can fit in my local machine, or excels in a specific vertical.

After reading the comments here and X, I can see it being the top-3 multi-modal open-source model though.

Then why are they publishing the benchmarks which makes them look worse than GLM 5.2?

We use Pi harness, same agent that powers Flue

We also tried to use OpenClaw for teams but unfortunately OpenClaw gateway is not designed as multi-tenant. Peter also confirms it: https://x.com/steipete/status/2026820269050855757

That's why we built https://lobu.ai which is a multi-tenant implementation for proactive agents like OpenClaw. It has entity based memory for building the org context layer and every channel/user gets its isolated container.

It feels like somebody prompted an AI agent at CF "why Meerkat is better than Raft" when drafting this blog post.

Filesystem is best when there is a single writer and many readers.

If you have bunch of files and don't have any structure, yes filesystem is great but the moment when you need consistency & performance (which you need sooner rather than later) use databases.

Investing early doesn't hurt when you build a product that you know will have many writers.

It's not built on OpenClaw, it uses Pi the harness that powers OpenClaw. We were using the GTM for multi-tenant OpenClaw when there was hype but quickly moved away from it as OpenClaw is a nightmare in terms of security.

It's interesting to hear that 60% of PRs at Anthropic is created by the Slack bot. While building a Slack bot is easy, making it look like an AI teammate is pretty hard. This is exactly the gap we’re working on with Lobu.ai — disclosure: I’m the founder.

The hard problem is giving a shared agent durable organizational memory and a real isolated environment where it can safely access company systems and perform work. The agents need a durable log of what everybody at the company is doing, prevent data leaks with proper access control and isolate the runtime to give everybody both private & shared space.

It’s also not tied to Claude or Slack. We see Slack as one interface and the models as part of the harness. It's usually better to combine multiple providers to review the work.

https://lobu.ai https://github.com/lobu-ai/lobu

Most SaaS stacks are a collection of vertical tools that each own one piece of the business but don’t really share memory or context with each other.

I wrote a post arguing that agent loops are becoming the better model. The thing is, a lot of “agent + cron job” setups today are basically doing what traditional SaaS already does — reacting to one event without much broader context. The loop approach only really starts to pull ahead when memory is persistent and shared across different parts of the business.

Materialized tables are useful for time-series or sharding-like use-cases. You essentially offload the work to INSERT time to locate the data into relevant buckets/sub-tables that you can DROP later.

We use materialized views for append-only timeseries data for https://lobu.ai and the retention policies define how we DROP the tables so we don't DELETE/UPDATE any rows in the tables.

The long term storage is Iceberg on S3 that's ingested via Postgresql replication, suitable for OLAP use-cases. Postgresql only stores the dimensional OLTP data the users can update and the hot append-only event data.

Looks interesting! It reminds me of pg_lake, which we evaluated for our startup https://lobu.ai but it's missing a lot of pushdown capabilities which made OLAP queries expensive.

I also tried DuckLake but that required us to move away from PG-first approach. I was thinking of using Debezium to create Iceberg on S3 for our append-only PG tables and use DuckDB. I will try Streambed out as well!

Thanks for correcting me, I was wondering why I got downvoted. :)

Clickhouse is also great for OLAP for sure

Ahh, sorry about that. It should be fixed in an hour, looks like we mixed the permissions. I just tried and confirmed other login methods work if you would like to try out.

The native extensions are fine but I don't have good experience with any third party extensions, so far tried Timescale, pg_lake, citus, and pgvectorscale. They look very appealing but it's usually a trap as you can't get the value without using the vendor's cloud offerings.

I think if you grow enough to look for these extensions, it's usually better to bet on purpose-specific tooling. For example, I use DuckDB/Iceberg combination extensively for columnar data and connect DuckDB to PG when I need it.

Yeah I have logs in Sentry, which also uses Postgresql.

All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for https://lobu.ai

The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, you can eventually migrate to a purpose specific tool to scale out.To be honest, LISTEN/NOTIFY in my opinion is the most fragile part of PG but it's fine as start until you scale out.

I don't usually like my cursor to be hijacked but man, I like this one.

Yes that's it. I actually just ask codex/claude code to look up the session id when I want to resume sessions cross harness, it's just jsonl files locally so it can access the full conversation history when needed.