As best I can see, bookstack has not experienced much in the way of concrete issues with Github. And there there are no concrete benefits from migrating to Codeberg. It is his project, his perogative, completely. But the major disbenefit of being on some other forge is that people are less likely to find the software and so less likely to adopt 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...

I can understand that viewpoint. Ultimately though, audience/growth is not a core success metric for me, and the values/points explained in the blog post are more important. Plus there's a factor of wanting to help de-centralise away from GitHub, and help provide momentum to alternatives.

Looking at those who have starred the new Codeberg repo, at least 15 people are new today, and thus form part of a bigger audience on Codeberg.

Fair enough. I didn't say so but - bookstack is great. Thanks so much for it.

On the flip side, had it not migrated, it wouldn't have shown up on HN today and I would never have heard of Bookstack :-)

>Care has been taken to ensure minimal impact to BookStack end users. The original GitHub repository is still staying around, and will essentially act as a mirror of the codebase on Codeberg, so any existing instances fetching updates from GitHub can continue to do so.

Since they are keeping the github as essentially a mirror, doesn't this obviate those concerns?

-edit- although also:

>although eventually we will only create releases on Codeberg so it’s advised to watch/subscribe to them there instead:

I guess someone _else_ could choose to fork and keep up-to-date.

BookStack maintainer here. Just to clarify on that, the GitHub repo will continue to be updated and mirror the Codeberg repo (including release tags/code) for the foreseeable future, it's just that I might stop specifically publishing GitHub release entries (details on the release tag) at some point to avoid the duplication of work.

be the change you want to see

"56k" meant 7 kilobytes per second as a theoretical max. So 4.4 was ok. Everything with networks is done as bits, I think honestly for marketing reasons now

Interesting process. I wonder if he considered doing this with Anki. That would have given him a good SRS algo for free and Anki cards are also HTML+CSS+JS. I probably wouldn't try to put LLM calls onto my cards though

> The only oversight I think in the proposal is staggered distributions so that projects declare a UUID and the distribution queue progressively makes it available rather than all or nothing

That is indeed an oversight - I wish I had thought of that idea!

No worries. Feel free to popularize it. I’m more worried about supply chain security than credit :).

Also rather than a UUID a hash of the package name is probably sufficient for back compat and avoiding people trying to rotate UUIDs to get sooner / later distribution.

Fair, but it is part of a pretty large library system and you can order whatever you want to pickup at Oodi

I have heard of more than a few horror stories including filesystems lost and force pushes done.

These tools have only been in use for a short time and the current harnesses/system prompts are quite limited. Claude code is mostly limited to your codebase where you have version control. Excel is different.

I foresee that once people hand over more power to full agents there will be some nasty surprises. Im sure there will eventually be demand for some kind of limits

And yet I could tell them apart with pretty good confidence. Why?

You got lucky and thought it was skill?

I got 8/9. Been away 2 years. The ones I rarely used or which don't have obvious "tells" that are hardest. For me, Jubilee is the most obvious - very distinctive sound.

Yes, I of course link to this post, which I think is great. But I think actually it understates the case. All three parts of the trifecta (untrusted content, private data and external comms) are not necessary. Really, the key problem is just untrusted content in the context window. Access to private data and the ability to communicate externally are just modalities in which damage can occur.

For example: imagine having just untrusted content and private data (2/3 parts of the trifecta). The untrusted content can use a "Disregard that!" attack to cause the LLM to falsely modify the private data. So I think the whole "trifecta" is not necessary and the key thing is that you simply can't have untrusted stuff in your context window at any point.

Oh yeah. I think simonw has created good vocab to talk about attacks but the trifecta is just one way to attack.

The difecta is:

* LLM can do something you'd rather it not.

* LLM reads untrusted text.

I agree and one of the things that makes it harder to handle "disregard that!" is that many models for LLM deployment involve positioning the agent centrally and giving it admin superpowers.

I mention in the footnotes that I think that it makes more sense for the end-user of the LLM to be the one running it. That meshes with RBAC better (the user's LLM session only has the perms the user is actually entitled to) and doesn't devolve into praying the LLM says on-task.