8 ms·

That would hold true if IPFS would be a specific application. But it is a protocol. I would not expect that the protocol specifies that a complient client sha

by TekMol 3y ago

That would hold true if IPFS would be a specific application. But it is a protocol. I would not expect that the protocol specifies that a complient client shares what it downloaded. That sounds more like a choice the client developers make on their own. But I'm happy to be corrected if someone has a link to the protocol definition and it says different.

nightpool 3y ago
By default, what the GP says is true. If you can point to specific popular clients that do not have that behavior by default then I think that would be more convincing than saying "Well technically there's no requirement" when it's impossible to avoid in practice without writing your own custom implementation from scratch
- wuiheerfoj 3y ago
  Afaiu, [Lassie](https://github.com/filecoin-project/lassie/ https://github.com/filecoin-project/lassie/) is the latest and greatest of IPFS clients and it does not store/provide any data that you access
  - rahimnathwani 3y ago
    AIUI Lassie uses indexers to locate content instead of using a distributed hash table (DHT). So a content identifier (CID) might be present on IPFS (and downloadable by a regular IPFS client), yet 'invisible' to Lassie. If my understanding is correct, it can't be considered a complete IPFS client. https://docs.filecoin.io/storage-provider/architecture/network-indexer/ https://docs.filecoin.io/storage-provider/architecture/netwo... https://en.wikipedia.org/wiki/Kademlia https://en.wikipedia.org/wiki/Kademlia
    - wuiheerfoj 3y ago
      I think it uses indexer and saturn (which ought to fall back to the DHT if it hasn’t cached the content of a CID already). That said they have a GitHub issue tracking CIDs that are retrievable via Kubo (fka go-ipfs) that aren’t yet retrievable via Lassie - it suggests to your point that there must be some difference; it also suggests they intend for retrievability parity though, so fingers crossed!!
      - rahimnathwani 3y ago
        This issue, right? https://github.com/filecoin-project/lassie/issues/136 https://github.com/filecoin-project/lassie/issues/136

by TekMol 3y ago

nightpool 3y ago

By default, what the GP says is true. If you can point to specific popular clients that do not have that behavior by default then I think that would be more convincing than saying "Well technically there's no requirement" when it's impossible to avoid in practice without writing your own custom implementation from scratch

wuiheerfoj 3y ago
Afaiu, [Lassie](https://github.com/filecoin-project/lassie/ https://github.com/filecoin-project/lassie/) is the latest and greatest of IPFS clients and it does not store/provide any data that you access
- rahimnathwani 3y ago
  AIUI Lassie uses indexers to locate content instead of using a distributed hash table (DHT). So a content identifier (CID) might be present on IPFS (and downloadable by a regular IPFS client), yet 'invisible' to Lassie. If my understanding is correct, it can't be considered a complete IPFS client. https://docs.filecoin.io/storage-provider/architecture/network-indexer/ https://docs.filecoin.io/storage-provider/architecture/netwo... https://en.wikipedia.org/wiki/Kademlia https://en.wikipedia.org/wiki/Kademlia
  - wuiheerfoj 3y ago
    I think it uses indexer and saturn (which ought to fall back to the DHT if it hasn’t cached the content of a CID already). That said they have a GitHub issue tracking CIDs that are retrievable via Kubo (fka go-ipfs) that aren’t yet retrievable via Lassie - it suggests to your point that there must be some difference; it also suggests they intend for retrievability parity though, so fingers crossed!!
    - rahimnathwani 3y ago
      This issue, right? https://github.com/filecoin-project/lassie/issues/136 https://github.com/filecoin-project/lassie/issues/136