zlatinb / muwire

MuWire file sharing client for I2P
GNU General Public License v3.0
191 stars 27 forks source link

[Feature Request] Option to not list search results from your own instance #72

Closed Searinox closed 2 years ago

Searinox commented 2 years ago

As a continuation of the discussion on #68 I am opening an issue here regarding the merits of hiding one's own results from searches.

The distinction here is being made between finding files from other users that you also happen to be sharing and results from yourself.

Currently an option exists "Exclude local files from search results". By logic this option automatically also excludes your own shared files, serving that purpose. However because some files(such as DLLs, empty files, etc.) may be common among multiple projects, there is use for not excluding the files you already have locally from search results, while still excluding results from your own instance.

I am thinking of two possibilities here:

-A new UI option dedicated to strictly hiding your own results from searches.

-A possibility to hide search results from users marked as Distrusted. In addition to this being useful on its own merits, it can be co-opted for this purpose, as one would be able to add their own MuWire user ID to Contacts and mark it Distrusted, achieving the same effect.

zlatinb commented 2 years ago

I can see the value in having such option. I could add it as a checkbox which is only enabled if "exclude local files" is not checked, because "exclude local files" is more strict than "do not list results from self".

Search results from Distrusted users cannot reach the node because Distrusted users are cut off at network level. Marking yourself as Distrusted is probably a bad idea, I haven't tried it but it could break quite a few things.

Searinox commented 2 years ago

At the time of creating this issue, if you had a generic file - like a DLL - common across multiple sources, you lacked context of where it is but with the current changes it will now be possible to tell in-folder what it is part of, distinguishing the projects they are in. Furthermore the ability to correctly copy your own file into a download if you also happen to be sharing it has brought value to having the distinction of knowing you're also sharing it.

I believe these changes have made this issue redundant. I could probably make a case for having an icon or something in the listing to immediately identify if one of the results is also a file you have but that's less important than the confusion that previous behavior was causing.

As far as I'm concerned this made the value of such a feature significantly diminish. I am leaving it open at your discretion as maybe there's other use cases you're aware of that I can't think about. If not, feel free to close this.

zlatinb commented 2 years ago

I like the idea of having an icon that shows whether the file is available locally. It can definitely be done for the tree views, not so sure about the table views, but I'll investigate.

zlatinb commented 2 years ago

Implemented in https://muwire.com/downloads/MuWire-0.8.9-GitHub72.zip

I know the checkmark icon probably isn't the best in every theme but the logic works.

Searinox commented 2 years ago

Wanted to ask you if you had something a little brighter than the dark blue because it looks okay on the System and Metal themes, but is quite hard to make out on Dracula. But then I looked at the rest of the icons and they all have the same issue. Look at the Mail icon in the lower right on Dracula theme and you'll know what I mean. That may well be its own issue.

That said, the icon is showing up correctly where it's supposed to. I don't see any problems with it. Trying it out for a bit, it does indeed do a lot to the searching experience.

zlatinb commented 2 years ago

Yeah, I just copied the icons over from the java i2p router. Ideally there should be a different set of icons for each theme, but that's a non-trivial amount of work. Or I could try and come up with something that looks okay-ish on all 3 themes.

Closing this issue for the time being.