Feature Requests

The MuWire file sharing application
User avatar
zlatinb
Posts: 103
Joined: 24 May 2018 17:14

Re: Feature Requests

Post by zlatinb »

zlatinb wrote:
30 Mar 2020 11:52
B0B wrote:
29 Mar 2020 16:00
Have an issue with MuWire after an i2p service restart.

When manually stopping and starting the service (on Windows: sc stop i2p / sc start i2p) everything get reconnected perfectly. All tunnels are working, MuWire/status page shows connections and uploads are resumed. But... "Status" on the main page shows "Connections: Down" so doing a "Search" is not possible. ("Not initialized" error message).

Need to manually stop the plugin from the i2p console, wait about 20 seconds, and start it again. Only then it starts to show connections, making "Search" work again.
question: was a browser tab open on the search page while the router was restarted? If yes, can you try closing all browser tabs which are open with MuWire, then restarting the i2p service?
Also pls try b58, should solve the problem even if there is an open browser tab across i2p restarts
GPG: https://keybase.io/zlatinb
blog: http://zab.i2p
mail: [email protected]
MuWire: https://muwire.com
MuCats: http://mucats.i2p
User avatar
B0B
Posts: 46
Joined: 18 Mar 2020 11:48
Location: NL

Re: Feature Requests

Post by B0B »

zlatinb wrote:
30 Mar 2020 11:52
question: was a browser tab open on the search page while the router was restarted? If yes, can you try closing all browser tabs which are open with MuWire, then restarting the i2p service?
afaik, No open MuWire windows at restart. Just the i2p console.
Maybe it's worth mentioning: I use TorBrowser, so, no history-tracking and no cookies. Well, it does keep something in memory because I can "go back" a page and undo a closed tab.

To be sure I'll check once again (build 52) and...
zlatinb wrote:
30 Mar 2020 11:52
Also pls try b58, should solve the problem even if there is an open browser tab across i2p restarts
...will update afterwards.


edit: On build52: Restarted i2p service and MuWire (with open search window) reconnected without any problem. The issue doesn't seem to be consistent, at least on my system. (not updated to build 58 yet)
User avatar
B0B
Posts: 46
Joined: 18 Mar 2020 11:48
Location: NL

Re: Feature Requests

Post by B0B »

I'm still here. Just too busy with work.

On my system, it looks like the combo java13 + i2p (i2speed) + MuWire has some kind of memory "leak". After about 30 hours memory usage goes up, up to the point the i2p service just shuts down. Chances are it's the garbage collection.

I scheduled it to restart every 17 hours so it doesn't show that behavior anymore.
arowana
Posts: 25
Joined: 05 Sep 2018 20:55

Re: Feature Requests

Post by arowana »

Feature ideas
  • Periodically scan for, and automatically download files. Subscribe, but for files instead of hosts.
  • Increase speed by automatically download parts of popular files, naming them so that you can't tell what they are, and not downloading enough to combine to a whole file. Assuming it's possible.
  • Encrypt pieces on disk as they are downloaded, with obscured name. Only assemble when prompted. Possibly password protect.
Feel free to use or discard as you see fit.
User avatar
zlatinb
Posts: 103
Joined: 24 May 2018 17:14

Re: Feature Requests

Post by zlatinb »

Thanks for the suggestions!
arowana wrote:
06 Jun 2020 14:36
Periodically scan for, and automatically download files. Subscribe, but for files instead of hosts.
That is doable, if you know the hash of the file. But to learn the hash you need to have seen the file in a search result at least once, or seen it on a MuCats site, or another side channel. After that it's easy to automate the process of searching for the file and downloading.
arowana wrote:
06 Jun 2020 14:36
Increase speed by automatically download parts of popular files, naming them so that you can't tell what they are, and not downloading enough to combine to a whole file. Assuming it's possible.
There is no way to tell which files are "popular" on MuWire; this is more like Freenet works. I'm very wary of automatically downloading anything without explicit action from the user though.
arowana wrote:
06 Jun 2020 14:36
Encrypt pieces on disk as they are downloaded, with obscured name. Only assemble when prompted. Possibly password protect.
While this is possible, I can't quite think of what's the use case of such encryption. It would also break swarming as you can't upload back while you're downloading. Can you elaborate more on what use case you see of partial file encryption?
GPG: https://keybase.io/zlatinb
blog: http://zab.i2p
mail: [email protected]
MuWire: https://muwire.com
MuCats: http://mucats.i2p
arowana
Posts: 25
Joined: 05 Sep 2018 20:55

Re: Feature Requests

Post by arowana »

Hi.

Automatic download: Let me setup a filter and download anything that matches that filter. *linux* would periodically search for and download anything matching that. I'm thinking something similar to couchpota.to since downloads take a while.

Increasing swarm size: Since you can see what files people are searching for, I thought that this could be used to see what people are searching for and download part of those files. Should be opt-in as you pointed out.

Encrypt files: The idea here was to make sure that files downloaded are under my control, if I download sensitive material. Nothing identifiable gets put on disk without my permission. A "high security" option when you install perhaps, together with a larger number of hops?
User avatar
zlatinb
Posts: 103
Joined: 24 May 2018 17:14

Re: Feature Requests

Post by zlatinb »

arowana wrote:
07 Jun 2020 08:52
Automatic download: Let me setup a filter and download anything that matches that filter. *linux* would periodically search for and download anything matching that. I'm thinking something similar to couchpota.to since downloads take a while.
Yes, this is doable. I might add it to the TODO list, it would be an advanced tool.
arowana wrote:
07 Jun 2020 08:52
Increasing swarm size: Since you can see what files people are searching for, I thought that this could be used to see what people are searching for and download part of those files. Should be opt-in as you pointed out.
You can see what others are searching for, but you don't know if they're getting any results, so it's not possible to judge the popularity of a file. Your MuWire node would have to issue an automatic search based on what other searches it has seen in the network; that could have negative consequences for the reputation of your MuWire ID as every search that goes to the network is signed. It gets very complicated very fast, so I'm opposed to this idea.
arowana wrote:
07 Jun 2020 08:52
Encrypt files: The idea here was to make sure that files downloaded are under my control, if I download sensitive material. Nothing identifiable gets put on disk without my permission. A "high security" option when you install perhaps, together with a larger number of hops?
I'm not sure how that is different from just using an encrypted partition for the download locations. If that's the problem you're trying to solve there are better tools out there than what MuWire itself can provide.
GPG: https://keybase.io/zlatinb
blog: http://zab.i2p
mail: [email protected]
MuWire: https://muwire.com
MuCats: http://mucats.i2p
arowana
Posts: 25
Joined: 05 Sep 2018 20:55

Re: Feature Requests

Post by arowana »

Well, 1 out of 3 isn't bad. Thanks for entertaining my ideas.
arowana
Posts: 25
Joined: 05 Sep 2018 20:55

Re: Feature Requests

Post by arowana »

Would it be possible to add some sort of priority to the downloads?
Try hard to download file1.
File 2 & 3 can be downloaded whenever, but I really want file 1.

Also, limit the number of downloads so that it doesn't try to download all 30 files I add to the queue at once?
User avatar
zlatinb
Posts: 103
Joined: 24 May 2018 17:14

Re: Feature Requests

Post by zlatinb »

arowana wrote:
21 Jun 2020 09:29
Would it be possible to add some sort of priority to the downloads?
Try hard to download file1.
File 2 & 3 can be downloaded whenever, but I really want file 1.

Also, limit the number of downloads so that it doesn't try to download all 30 files I add to the queue at once?
The current download queue system is very primitive and I agree it's time for an overhaul. The least that needs to be done is a limit on the number of active downloads. The automatic retrying logic makes that a little difficult though. For example, what happens if a download fails? Does it go back in the queue or does it get retried a couple of times first?

There are a couple of similar questions that need to be answered before the coding can begin.
GPG: https://keybase.io/zlatinb
blog: http://zab.i2p
mail: [email protected]
MuWire: https://muwire.com
MuCats: http://mucats.i2p
Post Reply