<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite">This early knugget spec looks very interesting. I'm curious about provisions for:<br><br>- HTTPS with minimum cipher specification in URL</blockquote><div><br class="webkit-block-placeholder"></div>So, since the only thing a Factory is publishing is something that is to be indexed and available in a public search engine, I can't justify any need for HTTPS. If I try to think about using it as a private search engine, well, I just have a hard time understanding about how a Factory would have your private data and be sharing/trusting it with a Collector/Broker... it just doesn't seem like something that is worth it or even hinting at encouraging.</div><div><br><blockquote type="cite">- signed nuggets (with signature block included in digest)</blockquote><div><br class="webkit-block-placeholder"></div>Very much overkill IMO, the digest plus the fact you retrieve it from the Factory, is aplenty for "trusting" the source. If a Factory is compromised such that they've lost DNS or their servers, their private key is just as questionable :)</div><div><br><blockquote type="cite">- use as elemental bits in a system such as <a href="http://freenetproject.org/">http://freenetproject.org/</a></blockquote><div><br class="webkit-block-placeholder"></div>If a knugget finds some use outside of the context of search, cool, but I'm kind of doubting it. It's going to end up pretty specific to the task at hand, moving small chunks of knowledge on a conveyer belt into an index melting pot and later for search result assembly.</div><div><br><blockquote type="cite">Also, some novel networking optimizations, such as Van Jacobson's stuff ( <a href="http://en.wikipedia.org/wiki/Van_Jacobson">http://en.wikipedia.org/wiki/Van_Jacobson </a> ) could be possible using an alternate transport, which could be negotiated based extra info embedded in HTTP headers.</blockquote><div><br class="webkit-block-placeholder"></div>Hacking something like TCP with UDP is quite frowned upon :)</div><div><br class="webkit-block-placeholder"></div><div>Since to get directly between two points both behind NATs our only choice is UDP, I lean more towards just being lossy and dealing with it. If a resource is short on bandwidth and dropping packets, there's bigger problems with that resource than missing knuggets. </div><div><br class="webkit-block-placeholder"></div><div>The design implication here is that any individual knugget should be less than a reasonable MTU (~1.4k) so that it could fit in a single UDP packet, simple optional compression should help some if needed. I don't think this is worth exactly specifying though, as any Factory making knuggets that big is probably doing something wrong, or they will only be serving them via HTTP and can't support a UDP-based transport.</div><div><br class="webkit-block-placeholder"></div><div>Jer</div><div><br></div></body></html>