I absolutely love this mod. I like a simple sorting system with a main chest for the main ingredients I use for crafting. I typically have Actually Additions which offers the Storage crate, a very large inventory.
I'd like to have this mod support upgrading a crate into a sorting crate, so that I can use the Inventory Matching option. Currently only wood chests and iron+ chests have the inventory matching option.

An alternative approach that is more extensible is to add Inventory matching to the Filter Hopper.
This would require the hopper to look at the inventory it is attached to, cache the list items, and use the custom item filtering you currently have. Obviously you'd want to periodically refresh the list of items in the inventory.
This would allow it to work with other inventories quite easily.

Filtered hoppers in particular can't just return its target IItemHandler because that would make any otherwise received items (e.g. via a pipe) go through the hopper without any filtering.

The filtered hopper isn't meant to be used for merging unsupported inventories into the sorting network, a seperate block is planned for that (on top of native support for common mods).

From this commit in the past 83ff407
It seems like you had the SameItemFilter only require the ITEM_HANDLER_CAPABILITY implying that at some point the FilteredHopper was able to handle it. You didn't list a reason for changing it to requiring the more strict SORTING_INVENTORY. Perhaps it may have been due to the fact that the FastHopper happens to implement the ITEM_HANDLER_CAPABILITY: https://github.com/blay09/RefinedRelocation2/blob/afbf21475d7dfe1932f97bdec1ece6e2baed724b/src/main/java/net/blay09/mods/refinedrelocation/tile/TileFastHopper.java#L149
But this would not work as intended as the items in the hopper are not the ones you want to match, but rather the items in the inventory that the hopper is pointing at.

I propose that the Filtered Hopper have the ITEM_HANDLER_CAPABILITY and return the IItemHandler of the thing it is pointing at when asked for the capability.
We would then revert the change you did to SameItemFilter.java so that it only relies on the weaker ITEM_HANDLER_CAPABILITY, enabling it to work on both Filtered Hoppers and Fast Hoppers.
Filtered hoppers would reflect the pointed to inventory, and the fast hopper would restrict itself to its internal inventory of 5 slots.

Here is the new getCapabilty of the FilteredHopper
`
@OverRide

@SuppressWarnings("unchecked")

public <T> T getCapability(Capability<T> capability, @Nullable EnumFacing facing) {

	if(capability == CapabilityItemHandler.ITEM_HANDLER_CAPABILITY) {

		EnumFacing myFacing = world.getBlockState(getPos()).getValue(BlockMod.DIRECTION);

		EnumFacing opposite = myFacing.getOpposite();

		TileEntity facingTile = world.getTileEntity(pos.offset(myFacing));

		IItemHandler targetItemHandler = facingTile != null ? facingTile.getCapability(CapabilityItemHandler.ITEM_HANDLER_CAPABILITY, opposite) : null;

		return (T) targetItemHandler;

	}

	else if(capability == CapabilityRootFilter.CAPABILITY || capability == CapabilitySimpleFilter.CAPABILITY) {

		return (T) rootFilter;

	}

	return super.getCapability(capability, facing);

}

`

If you feel this new item would allow for me to apply the same item filter to something like the Actually Additions crate then I feel this solves the core idea of this bug.

The next version is going to include the Sorting Interface which can be used to connect inventories from mods that aren't natively supported.

I don't think I will be adding native support for Actually Additions' crates since the GUI is already so huge, there's no good spot for the filter button (and every natively supported mod means a lot more maintenance). However, the Sorting Interface will work on them (but due to it having to scan the rather large inventory for changes, it may not always be instant when inserting items into the crate).