Janoš Guljaš

> > Did you consider go-ethereum v1.14.3 for upgrade? > > Did not, should we? Since the upgrade is happening, it may be good to have the latest minor release,...

> I do not know how to interepet the above yet but it's a start That is indeed a nice start, especially as there are not so many reported for...

> @janos for the first reference, it seems the option here is not related to bee itself but to the HTTP transport used during tests. See https://github.com/ethersphere/bee/blob/master/pkg/api/api_test.go#L268 > > That's...

> > LGTM. > > I must say that having one api to serve both business, infrastructure and observability information creates a risk that some of endpoints can be exposed...

I would even say that any automatic funds (BZZ) spending from the wallet is dangerous without very strong notification sistem that will inform a user about the intention to top-up,...

As an opt-in feature, I support it. The downside of the opt-in approach is that the data that is received may be biased by the sources that in general wishes...

Just to mention another tool for the job https://opentelemetry.io/.

I would like to add a short feedback from the contracts usage/integration, particularly in the bee node implementation. Given that there are a few contracts that are used in the...

> > I would actually suggest to follow a _registry_ pattern instead. This would work something like: > > 1. Contracts are deployed. > 2. A 'registry' contract is deployed....

That argument is strong. At least, now, the user can validate all the changes before the node upgrade. The assumption if users are actually doing that is not relevant if...