4,910 karma · joined May 6, 2008
Socials: - github.com/calpaterson
---
https://calpaterson.com
cal - AT - calpaterson - DOT - com
Git is supported in the spec, though the tool doesn't yet handle it (soon! git is nice as you get a log "for free" which helps agents understand more about the memories).
As for sqlite in git: yes you can gitignore it, you could use git-lfs, you could use an out of band database. It would be great if there were another format more amenable to git to store vectors in. I looked at csv closely, but I was worried about float formatting/representational bugs. There is a gap in the market for a format here.
Just to start with: memoryfields are possible to use in a server/client system. That was a key aim and I do already use them over Amazon S3 (though not always).
I started, like you did, with a personal library of prompts. But the issue is that as your library of little pieces of prompts increases a) you get tired of constantly editing them yourself b) you have no easy way to export and share them with others c) it's frustrating that the agent doesn't "automatically" find your little bit of prompt on X even when clearly it is relevant - hence sem search.
I think a lot of people are still using the "personal library of bits of prompt" model. It is ok. But I wanted to propose an minimal, interchangeable standard for sharing them. So the idea of being an institution and having a shared memoryfield: that's something I want as well!
The spec, feedback greatly welcome:
https://github.com/calpaterson/memoryfield-spec/blob/main/SP...
And I agree: it's not a very special thing. That's why I propose: Markdown + a simple embedding.
Then you trawl through your set of qualified leads :)
I'm sure there are other HN local meetups who could post in this thread - please do if you have a local meetup
https://news.ycombinator.com/pool
But not in this case. It's a slow Sunday afternoon and getting a few upvotes quickly is enough
He's talking about 800mg, and I doubt it. 400mg is well known to be a safe daily level. I doubt by doubling it you will experience massive negative side effects.
Here in Finland (possibly highest caffeine consumption per capita in the world?) there are people who have been drinking well over >1000mg/day for decades and life expectancy and heart health among the population is normal.
But anyway, specific trades are rarely private to one part of the bank for many reasons. For example regulatory: these days you have to notify the regulator about every trade.
The most common first thing to cache is getting the current user, because this ends up being a very hot path for most stateless systems. Because you need to get the current user for almost every request, it's quite easy for getting the current user to be 50% of database load: first you get the user, then you do the thing. tada, user lookup is now half your app by volume
Honestly designing your app to have a "memcache-friedly cache layout" is the same thing as designing it to have a redis-friendly cache layout. The pattern for this kind of application cache is identical: "get, and if not there, calculate and set".
It is basically indistinguishable from sonnet. At this point my own prompts, AGENTS.md, background docs and so on matter a great deal more than the differences between models.
And deepseek v4 flash (the sonnet comparable) costs 3% of what sonnet does.
Frankly, you pay a ransom at your peril. If it turns out it was North Korea you may well go to jail for it.
I use Bookstack for a family wiki. I probably would not have gone with it if it had not be hosted on Github as the visible activity on Github makes it clear that it's a project with momentum (18k stars, lot's of activity) etc.
I can't help but feel that moving will make the project less successful than otherwise...
That is indeed an oversight - I wish I had thought of that idea!