Be careful. If you have California customers you need to worry about California’s Invasion of Privacy Act, California Penal Code section 630, et seq. (“CIPA”).
It's not clear that it applies to the web! But predatory lawyers will come after you for it, if you are big enough and don't have a cookie banner.
I just looked into SSB and I really like the concept. It seems much more elegant than Mastodon. Why is Mastodon/the Fediverse so much more popular (or is it?)? What are the advantages of federation over total decentralization? I suppose one disadvantage of total decentralization is the need for ‘fat clients’, as another commenter pointed out.
It's a non-issue he's addressed many times. What happens after you collide a single hash, you need to have a useful commit that isn't going to destroy the ability of the code to run AND do something useful to you, etc etc? Also what happens after the next commit, where all the hashes recalculate? It's possible to be an issue, but highly improbable. More likely your creds are hacked or the fact that no one signs their commits finally bites us on a wide scale.
The practice of dependencies’ dependencies being specified using SemVer version constraints to auto-accept minor or patch changes is the difference compared to Go, and why lockfiles will not always save you in the npm ecosystem. That said, approaches like Yarn zero-install can make very explicit the versions installed because they are distributed with the source. Similarly, the default of using npm install is bad because it will update lockfiles, you have to use npm ci or npm install —ci both of which are less well-known.
So it’s not impossible to fix, just a bad choice of defaults for an ecosystem of packages that has security implications about the same as updating your Go (or JS) dependencies automatically and not checking the changes first as part of code review. Blindly following SemVer to update dependencies is bad, from a security perspective, regardless of why or how you’re doing it.
> The difference is the npm ecosystem actively encourages automatically following SemVer because by default it uses a ^ to prefix the version number.
So does Go. In fact, Go only supports the equivalent of ^, there is no way to specify a dependency as '=1.2.3'. That is, whenever you have two different dependencies which use the same dependency at different (semver compatible) versions, go mod will always download the newer of the two, effectively assuming that the one depending on an older version will also work with the newer.
The only difference in this respect compared to NPM (and perhaps also Cargo or NuGet? I don't know) is that Go will never download a version that is not explicitly specified in some go.mod file - which is indeed a much better policy.
