ldeffenb

> these peers have a radius != 9 and zero neighbors, notice their reachability [bad-peers.txt](https://github.com/ethersphere/bee/files/12477056/bad-peers.txt) Is the low storage radius and reserve because they are unreachable? Or is their low...

I see this a LOT on my massively pinning (1+TB) upload node. The pullsync cursorHandler consume copious amounts of CPU per instance and all new peers hit the newly started...

What, really? This would be a breaking change for existing upload tools?

Or are you talking about only the gateway and not the API?

My OSM uploader uploads the individual files and captures their references. It then externally builds the mantaray manifest referencing those file references. If the /bytes API defaults to encryption, then...

Of course, it only requires the uploading tools to set the encryption header to false, but changing defaults like this needs to be well publicized.

It would be interesting to see a histogram of the /stamps/{batchID}/buckets values for these 4 tests. https://docs.ethswarm.org/debug-api/#tag/Postage-Stamps/paths/~1stamps~1%7Bbatch_id%7D~1buckets/get

> * (changes the size). I presume you mean the size of the produced references since they'll now include the decryption key? That'll take a bit to get used to...

I use swarm-cli (https://github.com/ethersphere/swarm-cli) to maintain my OSM dataset manifest feed reference: swarm-cli feed update -r ac28eaf69a6415a243d564ea69765ed8ee81faefc8b2e0b775fc54dbc32d8fa9 --bee-debug-api-url http://:1635 -T "OSM Map" --bee-api-url http://:1633 --curl -v The --curl simply shows...

Are you doing direct or deferred uploads? What exact upload errors are you seeing?