977 karma · joined May 19, 2020
I personally never use the short names and have really come to like your solution. I host my own registry and I can glance at a build or compose file and immediately know if I’m depending on any external resources that I shouldn’t be.
I originally disliked it, but it’s been my favorite namespace solution for a long time now.
The intriguing part is that I think it works against scaling. The incremental cost for me to use the 500GB of free space on my disk is $0, but someone scaling a bot farm has to buy all their space.
Real people tend to have a lot more idle capacity than optimized, scaled businesses, so any kind of proof of idle capacity seems like it would disadvantage bot farms.
I’ve also thought that proof of collateral spending would be a good system. For example, you buy groceries and the store gives you a token saying you spent $X of real world money. Those tokens help show you're not a bot. Keeping that system honest and equitable would be extremely difficult though.
Maybe schools could give kids tokens for attendance. It sounds kind of dumb, but who knows.
TLDR; You need a "how to use it" section that explains how to get information in and out of the context. That's assuming I'm not completely misunderstanding the purpose.
I started using Claude Code about a week ago, but my goal is to get something running locally that can help me get things accomplished. I'm skeptical of the claims that AI can do the work for us, but I'm interested in the idea that we can offload a bunch of cognitive load onto it freeing up brain space for the actual problems we're trying to solve. Some kind of memory system is the starting point IMO.
So here's my feedback. I skimmed the repo. You explain what it does and how it does it, but I have no idea what it does or how it does it. I think your explanations are too technical for people to understand why they'd want something like this and the example makes it look like a simple search engine. I think you need more of an explain-it-like-I'm-five approach. I might know enough to be the 5 year old in the conversation, so I'll explain a few issues I've been having and maybe you can tell me if / how your tool helps.
Most of this is in the context of using Claude Code.
I noticed the amnesia problem immediately, but expected it. I figured I'd need to take a couple of days to configure the system to remember things and adhere to my preferences, but now I realize that was wildly optimistic. Regardless, I started making a very naive system that uses markdown files with the goal of getting a better understanding of managing memory and context together. It tries to limit the current context, but it's naive. It walks a hierarchy and dumps things into the context. It's just for me to learn. I'll be happy if it helps me understand enough to pick a good tool that already exists.
The first big problem I hit was that I want what you describe as compounds, mainly chat exports, especially as I'm starting out and just want to "dump" information somewhere. I want all my chat history as I'm learning something. I had a big ah-ha moment when I asked Claude to write our conversation to a markdown file and it told me it couldn't, but offered to output a summary. I'm losing information in real time as I chat. I don't know if it's valuable or not because I don't know enough to know what I don't know.
I've been getting the most value from chatting with the AI to learn and plan things. That involves a lot of ideas, right or wrong, and I want to be able to save and retrieve those chats verbatim so I can get back to the exact same context in the future. I don't know if that's a good or bad idea, but I figure that, if I can retrieve the original context, I can always have the AI summarize it or have it help me create something more well structured once I understand the topic a bit better. I also think there's probably some value in having a future model re-evaluate that old context. For example, in the future I can start it with the current refined context (how I implemented things) and have it walk through all that old context to see if there are any novel ideas that might help to solve existing issues.
I'm assuming your spec documents are followed by the AI when working on the project. Is that right? If so, I wonder if you're underselling that by not giving an ELI5 example of how that works. For me, that's a hard problem to solve. I want a semantic search for rules the model needs to apply but I don't really want it to be semantic because they're rules that must be applied. I need to be able to ask "why isn't the tool following my docker compose spec" and need a deterministic way to answer that. I think your project does that.
Maybe I'm simply lacking knowledge and should be able to understand why I need this kind of tool and, more importantly, how it maps to context management (assuming that's what it does).
I'll give you an analogy, at least that applies to me. Your "how it works" section is like going to driver training and having the instructor start explaining how the car's engine and transmission are built. People like me need it dumbed down; "Push the gas and turn the wheel. It's faster than your bicycle."
Maybe I'm not the target audience yet, but maybe I am. I'm already convinced that AI with good memory management is useful. I'm also unwilling to build that memory using a commercial system like Claude or ChatGPT. It's vendor lock-in on the level of getting a lobotomy if you lose access to that system and I don't think people are doing a good job of assessing that risk.
I'm going to finish building my own crappy memory system and then yours is going to be the first real system I try. Thanks for sharing it.
It's good at non-critical things like logging or brute force debugging where I can roll back after I figure out what's going on. If it's something I know well, I can coax a reasonable solution out of it. If it's something I don't know, it's easy to get it hallucinating.
It really goes off the rails once the context gets some incorrect information and, for things that I don't understand thoroughly, I always find myself poisoning the context by asking questions about how things work. Tools like the /ask mode in Aider help and I suspect it's a matter of learning how to use the tooling, so I keep trying.
I'd like to know if AI is writing code their best developers couldn't write on their own or if it's only writing code they could write on their own because that has a huge impact on efficiency gains, right? If it can accelerate my work, that's great, but there's still a limit to the throughput which isn't what the AI companies are selling.
I do believe there are gains in efficiency, especially if we can have huge contexts the AI can recall and explain to us, but I'm extremely skeptical of who's going to own that context and how badly they're going to exploit it. There are significant risks.
If someone can do the work of 10 people with access to the lifetime context of everyone that's worked on a project / system, what happens if that context / AI memory gets taken away? In my opinion, there needs to be a significant conversation about context ownership before blindly adopting all these AI systems.
In the context of Spotify in this article, who owns the productivity increase? Is it Spotify, Anthropic, or the developers? Who has the most leverage to capture the gains from increasing productivity?
Imagine having 20 years of context / memories and relying on them. Wouldn't you want to own that? I can't imagine pay-per-query for my real memories and I think that allowing that for AI assisted memory is a mistake. A person's lifetime context will be irreplaceable if high quality interfaces / tools let us find and load context from any conversation / session we've ever had with an LLM.
On the flip side of that, something like a software project should own the context of every conversation / session used during development, right? Ideally, both parties get a copy of the context. I get a copy for my personal "lifetime context" and the project or business gets a copy for the project. However, I can't imagine businesses agreeing to that.
If LLMs become a useful tool for assisting memory recall there's going to be fighting over who owns the context / memories and I worry that normal people will lose out to businesses. Imagine changing jobs and they wipe a bunch of your memory before you leave.
We may even see LLM context ownership rules in employment agreements. It'll be the future version of a non-compete.
I always include an archived link whenever I reference something in documentation. That's my main use at the moment.
However, I also feel like I've gotten a lot of really good value when trying to learn a new development topic. Whenever I find something that looks like it might be useful, I archive it and, because everything is searchable, I end up with a searchable index of really high quality content once I actually know what I'm doing.
I find it hard to rediscover content via web search these days and there's so much churn that having a personal archive of useful content is going to increase in value, at least in my opinion.
It sounds like you think I’m being deceptive. Do you know about any registry premium domains where someone has a contractually guaranteed price?
Also, based on my own anecdotal experience, ICANN doesn’t interpret 2.10c broadly and they allow the registries to push the boundaries as much as they want.
Barely. The NTIA gave up all their leverage over .com in 2018. The only thing the US can do at this point is let the cooperative agreement auto-renew to limit price increases.
I wouldn't be surprised if the US withdrew from the agreement altogether at this point. Then .com would fall under the joint control of ICANN and Verisign.
So ICANN has a non-trivial choice to make. Either they maintain the position that switching costs are bearable and let .io disappear, or they admit that TLD switching is impossible and save .io, which will make it hard to argue the threat of (registrants) TLD switching keeps the industry competitive.
That's not completely accurate. Section 2.10c of the base registry agreement says the following in relation to the uniform pricing obligations:
> The foregoing requirements of this Section 2.10(c) shall not apply for (i) purposes of determining Renewal Pricing if the registrar has provided Registry Operator with documentation that demonstrates that the applicable registrant expressly agreed in its registration agreement with registrar to higher Renewal Pricing at the time of the initial registration
Most registrars have blanket statements in their registration agreement that say premium domains may be subject to higher renewal pricing. For registry premium domains, there are no contractual limits on pricing or price discrimination. AFAIK, the registries can price premium domains however they want.
That's also why domain verification systems need to have continuous re-validation with more frequent re-validation for new identities. For example, if '@goog1e.com' is a new identity, it should be re-validated after 1h, 4h, 8h, 16h (up to a maximum). Additionally, you could let other validated users with aged accounts trigger a re-validation (with shared rate limits for a target domain).
The great thing about domains is that those of us that are good faith participants can build a ton of value on them and that value can be used as a signal for trustworthiness. The hard part is conveying that value to regular users in a way that's simple to understand.
We could also have systems that use some type of collateral attestation. For example, if I donate $1000 to the EFF, maybe I could attribute that donation to my domain 'example.com' and the EFF could attest to the fact that I've spent $1000 in the name of 'example.com'.
You probably have to gate that though some type of authority, but I can imagine a system where domain registrars could do that. I would love to buy reputation from my registrar by donating money to charity.
For now, I think wider adoption of things like DomainConnect [1] would make a difference. It works really well to set up an MS365 account with DNS hosted at Cloudflare, but it would need a workflow that supports sending requests to your DNS admin rather than assuming everyone is a DNS admin.
> A lot of people do not want to look at and understand domain names, instead they want to see a name and a check mark. They want a central authority to tell them who is trustworthy and who is not.
I think 'trustworthy' is a key word there and would add that I think a lot of regular people conflate identity verification with moderation. It's important to keep those separate because as soon as an identity system becomes a moderation system, it's worthless.
That's what makes domains so great for identity, especially with the way the AT protocol works. It helps to create a clear separation between identity verification and moderation. Moderation is much harder than identity verification, so having a clear line between the two should make it easier to develop technical systems that perform identity verification.
For pure identity verification, I think BIMI [2] is sitting on a solution they don't even realize they have. They're too tunnel visioned on email verification, but the system they've built with VMC (verified mark certificates) works as a decentralized system of logo verification. For example, I can tell you this logo [3] is trademarked and owned by 'cnn.com' and I can do it via technical means starting with the domain name:
dig default._bimi.cnn.com TXT
Also, the VMCs are only good for high value brands because CNN is paying DigiCert $1600 / year for the certificate, but, since it's just PKI, it allows anyone to put up that logo with a verified badge on the @cnn.com identity. A more accurate badge would be the registered trademark symbol [4].
Even though that only works for high value brands that own a logomark, it works extremely well and would be a great start to a system that's easier for the average person to understand because logos are a simpler concept than something abstract like domains and no one is spending the time and effort needed to get a fake VMC (if it's even possible).
The Bluesky implementation for domain verification has a long way to go though. It's very naive at the moment and doesn't even do a proper job of dealing with changes in domain ownership. In fact, almost everyone doing domain validation is doing it wrong because very few implementation do re-validation from what I've seen.
1. https://www.domainconnect.org/
3. https://amplify.valimail.com/bimi/time-warner/I0vDrJpkRnB-ca...
4. https://en.wikipedia.org/wiki/Registered_trademark_symbol
Domains provide a globally unique namespace and ownership can be verified automatically with domain validation. Bluesky did an ok job of it, but they didn't do anything to account for domain ownership changes and re-validation is non-existent, which is disappointing to see from the first big adopter since the oversight will eventually invite criticism.
I've wanted domain validated namespaces for 5+ years. Here's a comment I made about using domain validated namespaces in package managers a couple of years ago [1]:
---
I think one possible solution to that would be to assume namespaces can have their ownership changed and build something that works with that assumption.
Think along the lines of having 'pypi.org/example.com' be a redirect to an immutable organization; 'pypi.org/abcd1234'. If a new domain owner wants to take over the namespace they won't have access to the existing account and re-validating to take ownership would force them to use a different immutable organization; 'pypi.org/ef567890'.
If you have a package locking system (like NPM), it would lock to the immutable organization and any updates that resolve to a new organization could throw a warning and require explicit approval. If you think of it like an organization lock:
v1:
pypi.org/example.com --> pypi.org/abcd1234
v2:
pypi.org/example.com --> pypi.org/ef123456
Losing control of a domain would be recoverable because existing artifacts wouldn't be impacted and you could use the immutable organization to publish the change since that's technically the source of truth for the artifacts. Put another way, the immutable organization has a pointer back the current domain validated namespace:
v1:
pypi.org/abcd1234 --> example.com
v2:
pypi.org/abcd1234 --> example.net
---
I don't understand how it gets there though. How does it "know" that's the right thing to suggest when the majority of the online documentation all gets it wrong?
I know how I do it. I read the Docker docs, I see that I don't think publishing that port is needed, I spin up a test, and I verify my theory. AFAIK, ChatGPT isn't testing to verify assumptions like that, so I wonder how it determines correct from incorrect.
I think there's a huge difference because individuals can be reasoned with, convinced they're wrong, and have the ability to verify they're wrong and change their position. If I can convince one person they're wrong about something, they convince others. It has an exponential effect and it's a good way of eliminating common errors.
I don't understand how LLMs will do that. If everyone stops learning and starts relying on LLMs to tell them how to do everything, who will discover the mistakes?
Here's a specific example. I'll pick on LinuxServer since they're big [1], but almost every 'docker-compose.yml' stack you see online will have a database service defined like this:
services:
app:
# ...
environment:
- 'DB_HOST=mysql:3306'
# ...
mariadb:
image: linuxserver/mariadb
container_name: mariadb
environment:
- PUID=1000
- PGID=1000
- MYSQL_ROOT_PASSWORD=ROOT_ACCESS_PASSWORD
- TZ=Europe/London
volumes:
- /home/user/appdata/mariadb:/config
ports:
- 3306:3306
restart: unless-stopped
Another Docker related example would be a Dockerfile using 'apt[-get]' without the '--error-on=any' switch. Pay attention to Docker build files and you'll realize almost no one uses that switch. Failing to do so allows silent failures of the 'update' command and it's possible to build containers with stale package versions if you have a transient error that affects the 'update' command, but succeeds on a subsequent 'install' command.
There are tons of misunderstandings like that which end up being so common that no one realizes they're doing things wrong. For people, I can do something as simple as posting on HN and others can see my suggestion, verify it's correct, and repeat the solution. Eventually, the misconception is corrected and those paying attention know to ignore the mistakes in all of the old internet posts that will never be updated.
How do you convince ChatGPT the above is correct and that it's a million posts on the internet that are wrong?
1. https://docs.linuxserver.io/general/docker-compose/#multiple...
If you go from a standard registration price of $12 / year to a first year premium of $132, you double the 10 year carrying cost of a domain. That, naively, means domain investors can only speculate on half as many domains.
By having a first year premium price and then dropping domains back into the 'standard' tier, you also leave registrants with a semblance of price protections via section 2.10c of the registry agreement. As-is, premium domains have zero guarantees when it comes to premium renewal pricing.
There's a lot of room between squeezing domain investors and asking registrants to pay $100-1000+ per year for premium domains.
You can build reputation and trust using a handle, even if it's not associated with your real world identity. For example, I know that if 'ryao' replies to a question about ZFS, the response can be considered trustworthy. I don't know who that is or even what country they live in, but I know they're a contributor that isn't speculating or guessing when they reply and that's all that matters to me.
Domains can be used as verifiable, globally unique handles which simplifies things for the average user because it makes it easier to help users avoid impersonation and confusion if you can point them to something simple and verifiable. For example, look at Bluesky [1].
I've been wanting domain based namespaces and handles for a solid 5 years because it just makes sense. Here's my oldest mention of it (asking why package managers don't use domain verified namespacing) I have on HN [2]:
> It seems like a waste to me when I'm required to register a new identity for every package manager when I already have a globally unique, extremely valuable (to me), highly brandable identity that costs $8 / year to maintain.
You can tell it's old because .com domains only costed $8 back then. IMHO, domain based handles are the #1 reason to use Bluesky over X/Twitter. People used to spend $10-15k buying "noteworthiness" via fake articles, etc. to get verified on Twitter. I can't find any links because search results are saturated with talk of X wanting $1000 per month for organization validation (aka a gold check mark). Domain validation is just as good as that kind of organization validation, at least for well known individuals and organizations.
Given that, I think there would be a bigger market for domains if domain validated identities catch on. It could even spawn specialty gTLDs that do extra identity or notoriety checks (if that's allowed) or maybe attestations would become a big thing if there were an easy way to do them against a domain verified handle.
1. https://bsky.social/about/blog/3-6-2023-domain-names-as-hand...
This is where I think the new gTLDs registries could do better. Using your domain as a handle on Bluesky is a perfect example of something they could push for to grow the industry, but they seem to think the status quo with a sprinkle of price discrimination is the winning formula.
Most of the new gTLDs work great as domain verified social media handles, but no one is going to use them for that if all the good keywords are classified as premium with $100+ annual renewal fees. However, if you make them too cheap and they get popularized, domain investors will register everything good and try to flip them.
I think first year premium pricing strikes a good balance that doesn't limit novel, non revenue generating use cases too much. Charging $100-200 for the first year causes a very large increase in the amount of capital domain flippers need to invest to acquire a large portfolio of good names.
If Bluesky catches on I think we could hit a point where non-technical people are suddenly shocked when the see someone "using their social media handle for a website." Getting back to having people understand there's more than just Facebook and Twitter would be a step in the right direction IMO, so it would be nice to see Bluesky continue to gain popularity.
1. https://domainnamewire.com/2024/08/28/radix-sets-record-for-...
I’m a big fan of this style [1] of building base containers and think that keeping the container where you’ve stacked 4 layers (up to resources) makes sense. Call it a build container and keep it forever.
That's what I think will happen.
> And maybe that's a good thing? I'm not against security, and supply chain attacks are real.
The problem is the attestation is only for part of the supply chain. You can say "this artifact was built with GitHub Actions" and that's it.
If I'm using Gitea and Drone or self-hosted GitLab, I'm not going to get trusted publisher attestations even though I stick to best practices everywhere.
Contrast that with someone that runs as admin on the same PC they use for pirating software, has a passwordless GPG key that signs all their commits, and pushes to GitHub (Actions) for builds and deployments. That person will have more "verified" badges than me and, because of that, would out-compete me if we had similar looking projects.
The point being that knowing how part of the supply chain works isn't sufficient. Security considerations need to start the second your finger touches the power button on your PC. The build tool at the end of the development process is the tip of the iceberg and shouldn't be relied on as a primary indicator of trust. It can definitely be part of it, but only a small part IMO.
The only way a trusted publisher (aka platform) can reliably attest to the security of the supply chain is if they have complete control over your development environment which would include a boot-locked PC without admin rights, forced MFA with a trustworthy (aka their) authenticator, and development happening 100% on their cloud platform or with tools that come off a safe-list.
Even if everyone gets onboard with that idea it's not going to stop bad actors. It'll be exactly the same as bad actors setting up companies and buying EV code signing certificates. Anyone with enough money to buy into the platform will immediately be viewed with a baseline of trust that isn't justified.
As a package consumer, I agree with what you've said. I would have a preference for packages that are built by a large, trusted provider. However, if I'm a package developer, the idea worries me a bit. I think the concerns others are raising are pragmatic because once a majority of developers start taking the easy path by choosing (ex) GitHub Actions, that becomes the de-facto standard and your options as a developer are to participate or be left out.
The problem for me is that I've seen the same scenario play out many times. No one is "forced" to use the options controlled by corporate interests, but that's where all the development effort is allocated and, as time goes on, the open source and independent options will simply disappear due the waning popularity that's caused by being more complex than the easier, corporate backed options.
At that point, you're picking platform winners because distribution by any other means becomes untenable or, even worse, forbidden if you decide that only attested packages are trustworthy and drop support for other means of publishing. Those platforms will end up with enormous control over what type of development is allowed. We have good examples of how it's bad for both developers and consumers too. Apple's App Store is the obvious one, but uBlock Origin is even better. In my opinion, Google changed their platform (Chrome) to break ad blockers.
I worry that future maintainers aren't guaranteed to share your ideals. How open is Open Solaris these days? MySQL? OpenOffice?
I think the development community would end up in a much stronger position if all of these systems started with an option for self-hosted, domain based attestations. What's more trustworthy in your mind; 1) this package was built and published by ublockorigin.com or 2) this package was built and published by GitHub Actions?
Can an impersonator gain trust by publishing via GitHub actions? What do the uninformed masses trust more? 1) an un-attested package from gorhill/uBlock, which is a user without a verified URL, etc. or 2) an attested package from ublockofficial/ublockofficial, which could be set up as an organization with ublockofficial.com as a verified URL?
I know uBlock Origin has nothing to do with PyPI, but it's the best example to make my point. The point being that attesting to a build tool-chain that happens to be run by a non-verifying identity provider doesn't solve all the problems related to identity, impersonation, etc.. At worst, it provides a false sense of trust because an attested package sounds like it's trustworthy, but it doesn't do anything to verify the trustworthiness of the source, does it?
I guess I think the term "Trusted Publisher" is wrong. Who's the publisher of uBlock Origin? Is it GitHub Actions or gorhill or Raymond Hill or ublockorigin.com? As a user, I would prefer to see an attestation from ublockorigin.com if I'm concerned about trustworthiness and only get to see one attestation. I know who that is, I trust them, and I don't care as much about the technology they're using behind the scenes to deliver the product because they have a proven track record of being trustworthy.
That said, I do agree with your point about gaining popularity and compromises that developers without an existing reputation may need to make. In those cases, I like the idea of having the option of getting a platform attestation since it adds some trustworthiness to the supply chain, but I don't think it should be labelled as more than that and I think it works better as one of many attestations where additional attestations could be used to provide better guarantees around identity.
Skimming the provenance link [1] in the docs, it says:
> It’s the verifiable information about software artifacts describing where, when and how something was produced.
Isn't who is responsible for an artifact the most important thing? Bad actors can use the same platforms and tooling as everyone else, so, while I agree that platform attestations are useful, I don't understand how they're much more than a verified (ex) "Built using GitHub" stamp.
To be clear, I think it's useful, but I hope it doesn't get mistakenly used as a way of automatically assuming project owners are trustworthy. It's also possible I've completely misunderstood the goals since I usually do better at evaluating things if I can try them and I don't publish anything to PyPI.
I use Drone, but instead of using the Docker plugin I start a detached (background) Caddy server to work as a proxy to DOCKER_HOST. That lets me proxy to the local Docker socket to take advantage of caching, etc. while I'm iterating, but gives the option of spinning up docker-in-docker to get a clean environment, without any caching, and running a slower build that virtually identical to what happens on the CI server.
I find that having the daemon available solves a ton of issues that most of the CI provided builder plugins have. For example, with the builder plugins I'd always end up with a step like build-and-tag-and-push which didn't work very well for me. Now I can run discreet build steps like build, test, tag, push and it feels far more intuitive, at least to me.
That’s my favorite feature in Bluesky. I don’t need to worry about a handle since I can just use my domain.
ICANN provides some protection for standard gTLD domains, but it's minimal. You're guaranteed identical pricing to all other standard domain registrants on the gTLD, so they can only raise your price by raising the price of everyone else at the same time. That hasn't stopped some registries from 10x price increases though. The only thing it does is ensure they can't single you out and massively hike your renewal fee.
However, that does not apply to registry premium gTLD domains. When you register a registry premium domain you waive those protections and the registries can technically do anything they want.
If you register a ccTLD domain, you're at the mercy of that country's registry. If you register a 3rd level domain you're at the mercy of the 2nd level domain owner and they're regulated by either ICANN or a country based registry.
It's actually somewhat complex when you get into it.