Pin LS: Direct pins should override indirect pins

[aschmahmann]

We have 3 pin types recursive, direct, indirect. In my eyes the type associated with a pin should follow the priority order recursive/direct then indirect since it seems reasonable that a user should be able to pass the results of pin ls filtered by the types recursive and direct into pin rm and clear their repo.

Currently js-ipfs prioritizes indirect > direct and recusive > indirect

js-ipfs/src/core/components/pin.js

Lines 226 to 227 in eefb10f

	// if something is pinned both directly and indirectly,
	// report the indirect entry

js-ipfs/src/core/components/pin/pin-manager.js

Line 95 in eefb10f

// recursive pins pre-empt indirect pins

go-ipfs is currently a bit broken ipfs/kubo#6527, but used to follow (and in the CoreAPI does follow) the same pattern as js-ipfs. In addition to fixing #6527 we're considering moving to recursive/direct > indirect.

Is there a reason why this decision was made, or any objections to having everyone move to recursive/direct > indirect?

@Stebalien @daviddias @achingbrain

[achingbrain]

The js implementation was modelled after the go implementation so it's probably a bug.

The recursive/direct > indirect order of precedence sounds sensible.

[ef3n9r98]

Hey @SgtPooki, would you be willing to pay a dev to fix this issue?

[SgtPooki]

Hey @SgtPooki, would you be willing to pay a dev to fix this issue?

That's a great question, thanks for offering! Before the plan to rewrite the js implementation of ipfs, that answer may have been a yes, but now i think the answer is no.

Either way, i'd defer to @achingbrain and @tinytb for this one :)

[achingbrain]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

This issue has been fixed in Helia since it pins by depth rather than having separate recursive, direct, etc.