pscanf

They're incredibly slow (via official API or openrouter), but most of all they seem not to understand the instructions that I give them. I'm sure I'm _holding them wrong_, in the sense that I'm not tailoring my prompt for them, but most other models don't have problem with the exact same prompt.

Does anybody else have a similar experience?

On the other hand, I can understand leaving it as the last thing to do, after the foundation has set. Also, the TypeScript team has really done an amazing job all these years with backward compatibility, so that is extremely reassuring.

Maybe my uneasiness is just impatience to get to use the sped-up version in my app as well! :)

I'm particularly impressed by the bookmark "trick" to install it on a page. Despite having spent 15 years developing for the browser, I had somehow missed that feature of the bookmarks bar. But awesome UX for people to try out the tool. Congrats!

You mention GDPR, which also "applies" to me, though I wonder if what they're doing is actually illegal. I mean, after all, I'm putting my email on GitHub precisely to give people a way to contact me.

Of course, I do that naïvely, assuming good faith, not expecting _companies_ to use it to spam me. So definitely what they're doing is, at the very least, in poor taste.

I completely agree, though I'm personally sitting out all of these protocols/frameworks/libraries. In 6 months time half of them will have been abandoned, and the other half will have morphed into something very different and incompatible.

For the time being, I just build things from scratch, which–as others have noted¹–is actually not that difficult, gives you understanding of what goes on under the hood, and doesn't tie you to someone else's innovation pace (whether it's higher or lower).

¹ https://fly.io/blog/everyone-write-an-agent/

I think I do want to solve conflicts. My use case is for a personal database, which simplifies things a bit: sync is between devices of a single person, so it's unlikely for concurrent offline changes to occur.

What I have in mind is a setup like the one from this experiment: https://tonsky.me/blog/crdt-filesync/ . I don't know if it's at all possible in my use case though, or–in case it is possible–if it ends up being practical. As you said, the resulting user experience might be so strange that it's not something users want.

Anyway, thanks again for the info and good luck with DocNode. :)

Reading the "Why another CRDT / OT library?" I like that you seem to have taken a "Pareto approach": going for a simpler solution, even if not theoretically perfect. In the past few months I've been building a local-first app, and I've been a bit overwhelmed by the complexity of CRDTs.

The goal that I have with my app is to allow syncing between devices via Dropbox / Google Drive / iCloud or any another file-syncing server that the user is already using. I don't want to host a sync server for my users, and I don't want my users to need to self-host either.

Do you think it would be possible to use Dropbox as the sync "transport" for DocNode documents? I'm thinking: since a server is needed, one device could be designated as the server, and the others as clients. (Assuming a trusted environment with no rogue clients.)

I didn't explain myself very well, sorry. What I had in mind is: MCP is about putting together workflows using tools from different, independent sources. But since the various tools are not designed to be composed, scenarios occur in which in theory you could string together $TOOL_Y and $TOOL_X, but $TOOL_Y only exposes $DATA_SUBSET (because it doesn't know about $TOOL_X), while $TOOL_X needs $DATA. So the capability would be there if only the tools were designed to be composed.

Of course, that's also the very strength of MCP: it allows you to compose independent tools that were not designed to be composed. So it's a powerful approach, but inherently limited.

> About the TOOL_Z and TOOL_W scenario. It sounds like you're asking about the concept of a distributed unit-of-work which is not considered by MCP.

Yes, distributed transactions / sagas / etc. Which are basically impossible to do with "random" APIs not designed for them.

What if $TOOL_X needs $DATA to be called, but $TOOL_Y only returns $DATA_SUBSET? What happens when $TOOL_Z fails mid-workflow, after $TOOL_W has already executed?

> One big thing: what if you want to support SSR, which I think is a pretty basic requirement these days?

I agree it's a basic requirement for a certain class of apps and websites, but there are tons of apps for which SSR is not relevant and even detrimental (in the sense that it adds complexity that is not offset by the benefits it brings).

Conceptually, however, I prefer to think of my state being at the center of things. I mean, that's where I define (via types) what the state is. The URL is just one serialization of that state that is convenient to use in a web browser (making it work with links, back/forth buttons, etc). Maybe in another environment another serialization would be needed. Or maybe no serialization could be needed at all (making it a memory router).

Call me naïve, but routing in a single page application is just not that hard of a problem. At the core it's about having a piece of state¹ (your active route) which determines which part of the app you want to render–something you can do with a switch statement². On top of that, you want to synchronize that state to the page URL³.

Doing it yourself requires more boilerplate code, no question about it. But it's not that much code tbh (not very complex either), and you get back control over that important piece of state, which otherwise remains opaque and difficult to work with–i.e., its "shape" is pre-determined by the routing library you use. For example, react-router doesn't support parallel routes.

¹ https://github.com/superegodev/superego/blob/main/packages/a...

² https://github.com/superegodev/superego/blob/main/packages/a...

³ https://github.com/superegodev/superego/blob/main/packages/a...

Distinctive points:

- It exposes the "database metaphor": your data is organized in collections of documents, each collection having a well-defined schema.

- It's all local in an app (no server component to self-host).

- It has an AI assistant on top that you can use to explore / create / update.

- It allows you to create small personal apps (e.g., a custom dashboard).

- It allows you to sync data from external sources (Strava, Google Calendar, Google Contacts.)

Cons:

- The database metaphor is quite "technical". A "normal" user is not comfortable with the idea of creating their own collections, defining a schema, etc. In fact, right now I only have developers and techies as a target audience.

- It's not optimized for any one use case. So, for example, as a notes-keeper Notion is obviously much better.

- It's still in early stages (I'm working on it alone), so:

  - There's no mobile app yet.

  - It doesn't yet support syncing between devices.

  - There are just 3 connectors to sync from external sources.

I want to have _that_ data locally. And why are all these companies making it so incredibly difficult for me to get it? It's MY data after all!

But the default approach of every app is:

> We'll manage your data for you, in our cloud! Ah, btw, you'll only have access to it when online, and only for as long as you pay the subscription fee. Also, if we go out of business, sorry, it's gone.

> <fineprint> You _can_ request a copy of it (damn GDPR), but only once every 30 days, it'll take us 48 hours to prepare it, and we'll send (some of) it to you as a badly-formatted CSV carefully crafted to make it as useless as possible. </fineprint>

This is almost exactly what I say on the landing page¹ of the product I'm building (an open-source personal database, with an AI assistant on top).

I want to believe this can be a reality, and I'm trying to make it become one, but there are two significant challenges:

1. AI = cloud. Taking my app as an example, it'll be at least 2 years before consumer hardware will be able to run the smallest model that performs somewhat decently (gpt-oss-20b). And of course in 2 years that model will be beyond obsolete. Would a regular user pay the price of a subpar experience in order to get data ownership and privacy? It's a very hard sell.

2. Apps/services are very jealous of their users' data. As a user I have to jump through incredible hoops just to get a point-in-time copy of my data. If I can get that at all. There is no incentive for apps to allow their users to own their data. On the contrary, it's better if they don't, so they remain locked in the app. Also, regular Joe and Jane users are not really asking to have access to their data, because there's no benefit for them either.

That is, I think, the key to overcome challenge #2: giving regular Joes and Janes an immediate and obvious benefit. If they see that only by owning their data they can do $INCREDIBLY_VALUABLE_THING, then they will themselves start demanding companies access to it, or they will jump through the hoops to get it. (That's the way I'm going about it. I'm nowhere near the end goal, of course, but I see promising results.²)

I have no idea how to overcome challenge #1 yet. Mainly because currently there aren't really any big downsides to using cloud models. Or, at least, we haven't seen them yet. Maybe if OpenAI starts injecting ads in GPT-8 responses, people will reconsider using a "stupider" but local, ad-free model.

¹ https://superego.dev/

² https://pscanf.com/s/350/

An open-source, local database which collects all your personal data, hooks it to an LLM (BYO), and gives you an assistant that can answer any question about your life.

It also allows you to vibe-code (or just code) small apps on top of your data (e.g., your custom dashboard for your expenses).

I have a short demo here: https://www.youtube.com/watch?v=gqAyvENDjSA

I'm using a similar approach in an app I'm building. Seeing how well it works, I now really believe that in the coming years we'll see a lot of "just-in-time generation" for software.

If you haven't already, you should try using qwen-coder on Cerebras (or kimi-k2 on Groq). They are _really_ fast, and they might make the whole thing actually viable in terms of speed.

I then switched to JavaScript / TypeScript, which I found much better overall: it's understandable to basically every developer, and LLMs are very good at it. So now in my app I have a button wherever a TypeScript snippet is required that asks the LLM for its implementation, and even "weak" models one-shot it correctly 99% of the times.

It's definitely more difficult to set up, though, as it requires a sandbox where you can run the code without fears. In my app I use QuickJS, which works very well for my use case, but might not be performant enough in other contexts.

I think the prime number example (if obviously artificial) illustrates well the point I also wanted to make: while it might be technically possible to perfectly represent this function's I/O with the type system, what are the benefits and what are the costs? We seem to broadly agree that, as one approaches type perfection, benefits get smaller while costs grow bigger. A classic engineering tradeoff.

I also really liked how the author highlights the differences between application code and library code, which I hadn't taken much into consideration in my post. For example, I really didn't think about how using a library can be frustrating in many other ways, not only types! But, as he notes, we're accustomed to that, so it goes more unnoticed. And I really like the idea of having features in the language that allow encapsulating types. No clue what they could look like (I don't have strong CS foundations, so I'm out of my depth here), but the idea sounds very appealing.

Intuitively, this feels right to me, but I think that in this case my intuition fails, because I think of this "right" from the perspective of a person. "They made that thing, it's theirs, they have the right to decide what to do with it."

I don't think the same right applies to a company, though. Especially one so big that it has a significant impact on society, and so big that it's entirely driven by the incentives of capitalism (and not, for example, by a founder's ideals).

In this context I see companies as amoral automata whose only goal is maximizing profits, regardless of the wider consequences of their actions. This seems to produce very good results for the societies in which these companies operate, but it also comes with some side effects. By putting constraints on what companies can do, we can reap most of the benefits and avoid most of the side effects.

</couch-economist>

From time to time I get episodes of sudden tachycardia¹. It's a very strange feeling: one second everything is fine, the next my heart jumps in my throat and starts beating at 230 bpm (not a typo). After a while, just as quickly as it came, the tachycardia goes away and I'm back at whatever HR I was before the trigger. If it doesn't go away by itself, breathing in deep and holding my breath typically does the trick. It's like a light switch! A bit scary, but also very fascinating.

Thanks for explaining so well what goes on "under the hood"!

¹ https://en.wikipedia.org/wiki/Paroxysmal_supraventricular_ta..., I believe.