Add brew installation notice to the README

[luisschwab]

Floresta is now available as a brew formula.

Changelog

- Add a notice to `README.md` that Floresta is available on brew

[luisschwab]

ping @Davidson-Souza

[Davidson-Souza]

ACK edaefc1

[moisesPompilio]

ACK edaefc1

[jaoleal]

Sorry but i dont think install instructions should be on README like that, it should be on doc/installing.md or in a proper doc/installing-macos.md... Strange that doc/installing.md is actually a tutorial to install on debian based dists but appears to be a generic thing

[luisschwab]

We need to pretty much overhaul all documentation.

This should be on the main page so people can go to the repo and immediately see how to install it using a package manager. It's succinct, so no need to have that there.

[jaoleal]

We need to pretty much overhaul all documentation.

That could be discussed in a proper PR or issue for that, the current design for documentation follows a parity with how bitcoin core document things, the current structure was already achieved by an "overhaul" not so long time ago.

This should be on the main page so people can go to the repo and immediately see how to install it using a package manager. It's succinct, so no need to have that there.

I agree with you in the point where this should be clearly exposed but we have a structure to follow here in what concerns documentation, changing things on the go will not provide us any stability or any structure to stick with.

[jaoleal]

This is simply not true, installing it trough cargo is broken but you can install it following doc/installing.md using the install script and even using nix too (The way i use it on my setup)...

[luisschwab]

Does cargo install floresta work? There's no usable published package on crates.io yet. I don't consider cargo install --git <$FLORESTA_REPO> as installing through a package manager.

[jaoleal]

#991 (comment)

[jaoleal]

Pushing back firmly here, because I think the "only way to install" framing is procedurally indefensible and I want the case on the record before the PR moves forward.

Every line of code in this project goes through team review and acknowledgment. Install instructions should not be the exception. The Homebrew formula was written, reviewed, and merged outside this organisation, by people we did not nominate neither have control to. That is not a comment on whoever opened this PR or wrote the brew formula — I trust @luisschwab intent, assuming he was the one to upstream the formula to homebrew.

Structurally, the formula is owned by Floresta's Team. floresta.rb lives in Homebrew/homebrew-core, not in this repository. Per Homebrew's own Maintainer Guide, "only one maintainer is necessary to approve and merge the addition of a new or updated formula which passes CI" — with no upstream involvement required. We cannot patch it on a CVE timeline. We cannot stop it from drifting versions — it is pinned at v0.9.0 right now; if we cut 0.10 tomorrow, brew users keep getting 0.9.0 until someone (possibly not us) files a bump PR. And per Homebrew's Acceptable Formulae policy, "Homebrew reserves the right to add or remove formulae based on how it affects the wider Homebrew ecosystem." The formula could be removed tomorrow and we would have no recourse. I want to point this trough an ownership point of view, we do not own the formula, the repository and only by that we should not assume it as a canonical way of getting floresta neither the unique.

An acceptable way for this would be adding it as a community maintained install method as it is done is numerous open source project and even like that i think its unsafe to do so.

This also matches owr reference, Bitcoin Core's official download page, which lists only signed binaries from their own infrastructure, source code, and reproducible builds — no Homebrew, no apt, no third-party package managers. If the reference implementation of the network doesn't elevate third-party install paths to canonical, neither should we.

A canonical install path — one we do not explicitly flag as community-maintained — should be ownable by this organisation and modifiable only by it. Brew gives us neither. Anyone with a GitHub account can open a PR to homebrew-core to change floresta.rb, with no requirement to be affiliated with us. And even if Homebrew offered some org-exclusivity guarantee on a formula, that guarantee would itself be Homebrew policy — revocable at their discretion, under their domain, with zero leverage on our side.

This project already maintains several in-org install paths, all of which we control and review:

• contrib/install.sh — GPG-verified release tarball install with systemd service setup
• just install — cargo-based install via the project's justfile
• The in-repo flake.nix, plus the dedicated floresta-nix flake
• floresta-makepkg for Arch Linux
• The in-repo Dockerfile / docker-compose.yml

If anything in this ecosystem has a claim to "canonical," it is one of these — not a third-party formula we have no ownership. Documenting brew install floresta as canonical and unique while ignoring the install paths the team actually maintains inverts the trust hierarchy completely.

On cargo install --git not counting as "installing through a package manager": that's a personal definition, not a technical one. Cargo is a package manager, and cargo install --git <repo> is a first-class install path across the Rust ecosystem. Dismissing it narrows "packaging" to mean "whatever someone else does for me," which is exactly the dependency I'm objecting to.

I'm not arguing brew should be removed from the docs. I'm arguing it should be one option among others — alongside the in-org paths above — not elevated to "the way to install Floresta."