[Blocks-development] Content caching and replication...and deniability

[Michael S. Jr. <m...@ms...>]

On #blocks in EFnet we were talking about what happens when a file is routed
across another node -- it seems once all of the blocks pass through an
intermediate server, that intermediate server then knows it has a copy of
the file, and advertises that copy as well.

The only problem with this is...if I search for * and find questionable
content in my own cache, legally it should be my responsibility to leave and
rejoin the network to remove that content from my server, since I can
directly see that my own cache is providing the content.

The rest of the network already has file advertisements saying that the file
is available through one or more hops past myself.  Wouldn't it be better to
leave the encrypted blocks unassociated with a file on my own intermediate
server, but to let the associations already made by the existing file
adverts still have people get content through me?

Or for an example...let's say I have a leaf node connected to me, and that
leaf node offers a file.  Someone on the other side of me downloads the
file -- that file's blocks must pass directly through me.

When the leaf node offered the file, my client broadcast the file and a
routing entry...let's say the leaf node was my connection F...the file being
offered might have routing entry AF in your search results.

When you download the file, the file's data must pass through me to get to
you.  As your machine downloads the blocks, they get cached on my server
also.

In the present system, once my client sees that it has all of the blocks the
leaf node was offering, my client also makes a file advert for that file --
so if you search you get the file with routing entry AF and another copy of
the file with routing entry A.

In the change I'm proposing...suppose my client keeps the blocks cached, but
doesn't advertise the completed file.  Once the download is complete, other
clients only see search results with routing entries AF, but the data comes
directly from me.  Suppose the leaf node disconnects...now routing entry F
on my client is invalid.  However, the file is still known to the rest of
the network as on AF (for example).  If a client again tries to download AF,
ideally instead of returning that the route is no-longer valid, my client
should return the cached blocks, not revealing the fact that my node F has
disconnected.

Wait a minute...there seems to be a hole in my logic somewhere.  Can someone
help me find it?

--Michael Spencer
bl...@ms...