You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When hosting dapps on *.bzz.link, given the nature of the load-balancing / fanning proxy in front of the bee nodes fetching the actual data, inconsistencies become evident, very quickly.
These inconsistencies and status of the underlying node / gateway would be very handy to know when it comes to debugging applications that depend on gateways (or for the gateway's resilience to be increased). Problems that I'm currently running into is that of "random" 404 errors, which I can only assume is that the serving node is in a neighborhood causing issues / a segregated part of the network.
Additionally, I understand that the underlying nodes may be restarted, and with 20 min warm-up times, this is not insignificant. When debugging hosted dapps, this information would be very handy to know.
Therefore, I'd suggest perhaps some optional headers in the response would be very handy, including:
Neighborhood that the serving no presides in.
Uptime of the serving node.
I understand that the above issues may cause some discussion around privacy, and censorship resistance. I think there's a balance to be struck here. The gateway is in itself a form of centralisation, and one that is certainly needed prior to the Swarm client being easy to embed in native client applications. This debug data would give a better understanding from a developer's experience, giving visibility to how different bee clients are interacting with Swarm.
The text was updated successfully, but these errors were encountered:
When hosting dapps on
*.bzz.link
, given the nature of the load-balancing / fanning proxy in front of thebee
nodes fetching the actual data, inconsistencies become evident, very quickly.These inconsistencies and status of the underlying node / gateway would be very handy to know when it comes to debugging applications that depend on gateways (or for the gateway's resilience to be increased). Problems that I'm currently running into is that of "random" 404 errors, which I can only assume is that the serving node is in a neighborhood causing issues / a segregated part of the network.
Additionally, I understand that the underlying nodes may be restarted, and with 20 min warm-up times, this is not insignificant. When debugging hosted dapps, this information would be very handy to know.
Therefore, I'd suggest perhaps some optional headers in the response would be very handy, including:
I understand that the above issues may cause some discussion around privacy, and censorship resistance. I think there's a balance to be struck here. The gateway is in itself a form of centralisation, and one that is certainly needed prior to the Swarm client being easy to embed in native client applications. This debug data would give a better understanding from a developer's experience, giving visibility to how different
bee
clients are interacting with Swarm.The text was updated successfully, but these errors were encountered: