hyperblobs: init at 2.8.0

[Axler1]

• Addition of Hyperblobs: Blob Store for Hypercore
• To fix hyperblobs: NGIpkgs -> Nixpkgs ngi-nix/ngipkgs#980

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[eljamm]

How will users use it? If it's only accessible through API calls, it shouldn't be packaged.

Perhaps it would be more appropriate to package this as a node package then, since it's a node library.

[Axler1]

@emaryn, @eljamm thanks for the feedback! I chose pkgs/by-name/h/hyperblobs following the current nixpkgs packaging conventions, which recommend placing new packages under pkgs/by-name/, including Node.js libraries. Happy to adjust if there's consensus otherwise!

[eljamm]

How will users use it? If it's only accessible through API calls, it shouldn't be packaged.

Perhaps it would be more appropriate to package this as a node package then, since it's a node library.

I checked the documentation, again, and apparently:

As a rule of thumb, the package set should only provide end user software packages, such as command-line utilities. Libraries should only be added to the package set if there is a non-npm package that requires it.

So I guess adding this to nodePackages isn't really viable.

I chose pkgs/by-name/h/hyperblobs following the current nixpkgs packaging conventions, which recommend placing new packages under pkgs/by-name/, including Node.js libraries

I wanted to see if there was any better place for this, but I think the best place is indeed pkgs/by-name

[eljamm]

I still don't know why it was packaged?

This package is part of the Hypercore protocol and was previously packaged for the Hypermachines NLnet project. Now, it's being migrated from the NGIpkgs repo to Nixpkgs with the goal of using it to package Hypermachines in the future.

My opinion is that this is neither a package that can be used independently nor is it better than installing it with npm

From what I've read, node_modules can still be useful by themselves, so we can technically use this when composing Hypermachines.

Also, from what I've seen, having libraries packaged by themselves isn't that new or odd of a pattern in nixpkgs:

• jellyfin-web -> jellyfin-media-player
• polonium
• factoriolab
• textlint-rule-terminology

That said, if it turns out that we don't really need this in the future, it wouldn't be a big deal to remove it as this likely won't break any user workflow, but for the meantime this package (as well as the other Hypermachines components) will be maintained and hopefully composed into a better shape.

[eljamm]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 404422

Logs: https://github.com/eljamm/nixpkgs-review-gha/actions/runs/14924206142

---

x86_64-linux

✅ 1 package built:

• hyperblobs

---

aarch64-linux

✅ 1 package built:

• hyperblobs

---

x86_64-darwin

✅ 1 package built:

• hyperblobs

---

aarch64-darwin

✅ 1 package built:

• hyperblobs