ipfs blockservice is incompatible with sessions

[Jorropo]

nopfs/ipfs/blockservice.go

Lines 62 to 70 in 5edc09a

	// Blockstore returns the underlying Blockstore.
	func (nbs *BlockService) Blockstore() blockstore.Blockstore {
	return nbs.bs.Blockstore()
	}
	// Exchange returns the underlying Exchange.
	func (nbs *BlockService) Exchange() exchange.Interface {
	return nbs.bs.Exchange()
	}

See how the code does not apply any blocking on sessions.
Theses are used by boxo/blockservice.NewSession when a session is used.

This also cause issues with new ContextWithSession feature because it's not possible to unwrap a nopfs blockservice and access the real one underneath (so the context value key becomes the nopfs blockservice which isn't what we want because nopfs doesn't do session redirection based on context).

We should do blocking on the blockstore.Blockstore and exchange.Exchange API arguments before they are passed to the blockservice.

[hsanjuan]

We should do blocking on the blockstore.Blockstore and exchange.Exchange API arguments before they are passed to the blockservice.

What if it returns a blocking Exchange and blocking Blockstore when those methods are called ?

[Jorropo]

This would be incompatible with this new boxo patch:

ipfs/boxo@22fa8b1#diff-c3167a605aeb6a2f9430f5730ee6508f88e15022a746998ff6ec8ba013d0d6dc

The problem is that in the wrapping code I use the incoming blockservice as context key:
ipfs/boxo@22fa8b1#diff-c3167a605aeb6a2f9430f5730ee6508f88e15022a746998ff6ec8ba013d0d6dcR494-R497

So github.com/ipfs-shipyard/nopfs/ipfs.(*Blockservice) is used when wrapping the context.
But unwrapping is implemented in github.com/ipfs/boxo/blockservice.(*blockservice) which use it's receiver as key into the context. So the two don't match and it does not work.

github.com/ipfs/boxo/blockservice.(*blockservice).GetBlock has this check:

	block, err := blockstore.Get(ctx, c)
	switch {
	case err == nil:
		return block, nil
	case ipld.IsNotFound(err):
		break
	default:
		return nil, err
	}

Which would allows us to do filtering only in the blockstore and have it also filter the exchange thx to:

	default:
		return nil, err

I'll fix that in GetBlocks and then nopfs can implement a wrapping filtering blockstore instead of blockservice while having the same effects.

Other solutions exists but I think it's the least bad one.

[hsanjuan]

That sounds like relying on an implementation detail that causes exchange-blocking by chance (only because blockstore is checked first?) so I'm not very sold... better to wrap both.

I think conceptually BlockService is the right layer... it feels weird that we have to work around the fact that implementation for a BlockService session bypasses the layer and uses underlying exchange/blockstore directly. Can't we wrap sessions with blocking code directly by making NewSession part of the BlockService interface, and making sure we pass the underlying blockservice to the Blockservice.NewSession so that grabSessionFromContext works?

[Jorropo]

That sounds like relying on an implementation detail that causes exchange-blocking by chance (only because blockstore is checked first?) so I'm not very sold... better to wrap both.

Fair.

Can't we wrap sessions with blocking code directly by making NewSession part of the BlockService interface, and making sure we pass the underlying blockservice to the Blockservice.NewSession so that grabSessionFromContext works?

That would work but that require breaking the interface and I don't know if anyone else has custom blockservice implementation.

Else we could have something like:

func WithContentFilter(b func(cid.Cid) error) Option {/* ... */}

In boxo/blockservice this is already what we are doing with verifcid.

This also means nops only needs to provide 1 small function instead of many plumbing methods.

[hsanjuan]

What about a new SessionBlockstore interface that has NewSession ?

[Jorropo]

I think #35 is cleaner.
It replace ~80 slocs with:

func ToBlockServiceBlocker(blocker *nopfs.Blocker) blockservice.Blocker {
	return func(c cid.Cid) error {
		err := blocker.IsCidBlocked(c).ToError()
		if err != nil {
			logger.Warnf("blocked blocks for blockservice: (%s) %s", c, err)
		}
		return err
	}
}

While not adding as much complexity in boxo/blockservice.

What about a new SessionBlockstore interface that has NewSession ?

I don't get how this would work.
Today you can't wrap Session.
So NewSession is called, it checks if nopfs implements SessionBlockstore.
It does.
Then in nopfs.Blockservice.NewSession it call boxo/blockservice.NewSession on the underlying blockservice, at this point we have a true boxo blockservice session.
But you can't wrap this session since session isn't an interface (which might be an issue in itself). So I don't see where the filtering would happen.

[hsanjuan]

I think #35 is cleaner.

It is, but relies on the fact that a specific blockservice implementation exists that provides content-blocking capabilities.

But you can't wrap this session since session isn't an interface (which might be an issue in itself)

Session should be an interface (or a blockservice itself) and we wrap it... similar to merkledag.NewSession which returns an ipld.NodeGetter?

Sorry for resisting here a bit, just aiming to keep the conceptual layer model based on interfaces so that nopfs stays as purely plug-in (I think is nice that things can be like this). If we have a content-blocking BlockService, we should also think of doing the same in Namesys and Resolver and removing wrapping for general consistency.

[hacdias]

@Jorropo how much work would it be to make session an interface?

I did look at (ipfs/boxo#556) and it seems to do what it says it does, but I'd like us to have a consensus here on what to do next.

That would work but that require breaking the interface and I don't know if anyone else has custom blockservice implementation.

Maybe breaking the interface isn't the worst idea if the outcome is better and cleaner. We can always provide with a changelog that explains clearly what needs to be updated in someone else's blockservices. What do you think @Jorropo @hsanjuan?