Kaylee

Here's a comparison https://jsperf.com/blob-to-arraybuffer

[I made a little demo to help explain asyncIterators](https://flems.io/#0=N4IgtglgJlA2CmIBcBWAHAOhQFgDQgGMB7AOwGciFlDLYBDABzPihHzIICdbkBtABlwBGfvwC6+AGYQEZPqBJ0wiJCAwALAC5hYbGiU3wD1EAF9cCpSrUArOfmIGjm6mDoQSACgCUAHUVkAJ4kBAAEkgCuIZoQpKFuHqE+ocD+oaEA9Bmhmpx05JJEnGChZLnwSmmhdEEh4VEEMXEAVDlEAApEANbwYHGe0ADK5UreKVXphZzVAO7umkmOZaHQoUSSK1DDnBVgY6kk6UeZ2ZLwmgTqOerwoQzdvXHr1xBkm+HcJZo3d919h4wIBMjksFjsyPdyLcALyzebhc6XTwAAy0miYSCy9x6gIwxAygIyADcAEwZbGPEgZAAkwGgpmRfkOx1CgQg8FgUDhEDB8AhpGYGDspB8wNMVXFJCqWVKRAinAItzKOyUaw2eRIUCIJQ8hgA5vBOG9JJ9QvxQgBaUJoACcaCqNWCYUi0Vih1aGq1YAAkk4DZxtrskvtgTN1DJbp5chF4CHmccZSQiDFFUlEktKLHQuoiDNQiQImAAEaGt50HZrEiwQKs9mclihMNGfPwFgN+BE5vfOV6q48gDkZcOHmkJB5SpGYAA-MD0jLvnRNIPQiWCHQIsxqrUCABxIyGxdFMsVhgRWCwFc1Fi4WUtvOXKJdY+3UjV0JcCqGLmkVPfeA18tbhqHouSmDBZxOdJvleFY3jDRd4joUdNCIMgrmUfIFiLACVwiSQzk4DBQgATTlfsuXUOhOzaXD8MNUIIgYd91EfN4IJldIIA2QI5UbTDrl6GiS3fFUvxXeApluP8AJPM8EC5KMiFCABHGMYwEkpGNvaT+wrFUoBrTgIF7BY6DmQImRZd8BUzDBYCIPVPH7NkOSgBtPW1fNCxLTh+0slkILM+F+zXAE5h5O5PlePkVgBbdQgNEgDxQo1+wglzOVCABZRd1AwbgoigTwcu+fL8i9ZJWltNB-PSSU6v8aVslyfIyCmEoPJ9P1DUDVUUOqUpJzVX4en+JIimss8uRsDcFi1ASEQuPtDj-cT7LzKYLSCnl-NBEbKV6kpYRQzpRpFTrfX1HrJx8Jkmsi3Uy32saZh5K5OtCNz6BrAAeUIRDIKopm5BZPD2ikxueCHSEOuNjgzBA7IczxoZIDBFGUWrPqIAhC2cDAiyIAyMA8JLOAACQAFSygAZUIAGpYWRH6oAgIkAD4fogMA9VKBVoV8EBaVRjAISMwwyAwE1SE0AB9NzJHXWBNHFEAMnZ4WHn+dGrFMH6MlZjnkWBbaFiSvN2ii5hPHBShqOhdnSnOSnufgOVNBtvk7fgG8SryzrKv+81WhEURvH8yVJT0ZgEEaN05FUABmEkkDQfgzAsEAMesPEyHsfRDGMVQzDEUwgA)

### EDIT: See below for a better simplified version. We could use other members of the swarm to forward signalling data. # Added list Each peer in the added list...

Yeah it's not necessary you're right. I thought that ut_pex exchanged peers received from other PEX messages without connecting to them, but it doesn't.   So the only changes would...

> Are we reusing the PEX message and changing it only over WebRTC? easiest and most compatible way would be a whole new extension, so separate message that lists peer_ids...

https://github.com/webtorrent/webtorrent/pull/1350 fixes this I think (even though that wasn't the intention of the PR) Instead of waiting for the entire store to be verified, requests for a piece are cancelled...

Here's a PR for immediate-chunk-store https://github.com/feross/immediate-chunk-store/pull/9 (merged) BTW, this problem goes away when async functions are used instead of callbacks

I don't believe that BEP40 has anything to do with geographic location. Here's a good article about why it exists https://blog.libtorrent.org/2012/12/swarm-connectivity/ For WebRTC peers, I think this would have to...

I implemented this in a branch of idbkv-chunk-store if anyone wants to experiment. (check the readme for usage) https://github.com/KayleePop/idbkv-chunk-store/tree/blobs It looks like you're right about indexedDB returning a pointer.

you pass an option to get() to return it as a blob. ```js chunkStore.get(0, {returnBlob: true}, (err, blob) => console.log(blob instanceof Blob)) // outputs true ``` It also means that...