some improvement suggestions

[okdistribute]

from @pvh

this a valid discovery key (for a hypercore)? -> need checksums to make sure the key is useful, documented example code showing how to handle invalid input. if bad, get a better key / fix typos / give up and move to Belize

is there anyone offering this data? who? -> it should be easy to review the peers you discover, what their network position is (local / DHT / and so on), as well as how much data they claim to have (perhaps the bitfield should be in the discovery traffic?) if not... what do you do? wait -- but how should that be communicated to the user?

am i able to connect to this data source? <----------- this is the most frustrating step to understand but critically the answer should ALWAYS be yes so i view this less as dat-project-level debugging infrastructure rather than user tools

• for local mdns connections we should be able to answer this quickly and decisively
• for dns-sd, it's harder! there are node-specific and peer-specific answers to this question. what's your NAT situation? (hint: it's always terrible, but maybe the peer is better?)
• for dht traffic does this even work

if i CAN connect, how much data am i waiting for? how long is it going to take? with email, you don't see the email until it fully arrives. with the web things stream in. for many dat applications you might want different behaviours but it should be easy and documented how to track download speed / progress.

last we get into liveliness. what's my connectivity to DNS-SD? did a peer drop without sending me all the data i need and now i have an unfillable gap? is someone downloading from me right now so i should give them a moment for that to finish?