Feature Requests

[zlatinb]

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

[B0B]

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...

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)

[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]

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.

[zlatinb]

Thanks for the suggestions!

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.

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.

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?

[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?

[zlatinb]

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.

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.

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.

[arowana]

Well, 1 out of 3 isn't bad. Thanks for entertaining my ideas.

[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?

[zlatinb]

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.