That danger exists no matter how many hops are used, it's just different probability. But yes, it's possible, although I'm hoping the high fan-out factor will make sure the isolated islands are "big enough" :)

Btw I just released 0.5.8. Important new features are:


https://github.com/zlatinb/muwire/wi...e-Certificates
https://github.com/zlatinb/muwire/wiki/Search-Phrases


also I removed the forced update check on startup, although that will take effect only after the second restart.

I only downloaded a single macupdate with 0.5.8. That's an improvement. Though a restart reiterated the download after a few minutes of sitting on connecting. I cancelled this one. Another restart and it appears the reiteration has stopped.

The program appeared to shutdown very fast compared to usual. Another shutdown was also very fast.

I noticed once with 0.5.6 or 0.5.7 and again with restart of 0.5.8 there was no osx firewall popup. I'm always a little nervous when it's inconsistent and whether the exception is still working. A second restart and same thing. Not sure of the relevance.
Such interactivity would be handy if added to the Library as a whole. Similar to LW in a way.

Just discovered after I changed id3 tags of some files they were removed from shares upon next startup. So I see what you mean about MW is a little fussy toward hash changes.

But that's only if you download a file and share it right? Not for files you are adding to the share pool. I'm not sure of the relevance for your own unique shares.

edit: What does that mean in layman terms (re: 32kb)?

Implemented "show in library" option and a popup menu in the uploads table in git. Will be available with 0.5.9 (probably tomorrow)



You can issue certificates for files you're adding to the shared pool. Then when someone browses you or you return a search result, they can choose to import those certificates. It's true that your own certificates are of little use to yourself, but they help other verify the origin of the file. This way you can establish reputation.


32kb is a couple of pages of text I think.

I just released 0.5.10. Features a new search result display option - you can group by file instead of by sender. Also a right-click option on shared files that shows exactly who has searched for your files and who has downloaded them. Hope you like that!

Search result display shows helpful information.

I am finding the search results are somewhat more inclusive now or perhaps it's just the search terms. Keeping the searches simple appears to bring in more search results.

I'm starting to wonder if there is a problem at my end because I appear to have skipped 0.5.9; I am yet to see an update message.

After the update I noticed search hits and upload counts reset. Thus instead of overall I guess it's now a per session which is more appropriate.

I noticed Advanced Sharing - Watched Directories with 0.5.8, something I had not noticed previously. I apparently have ten directories watched for file changes.

Negative Tree (Files which are explicitly not shared): I notice there's directories listed that I'm also supposedly sharing. At least two of them only have one kind of file so there was no reason not to share anything from those folders and makes me wonder why they should be listed in the negative tree.

If certificates have been produced and you wish to adjust the name of the file, how difficult is it to make changes without polluting (creating a mismatch with) the certificate or removing and replacing the certificate? AFAIK changing the file name (not id tag name) of a file should not change the hash of a file, but the certificate is a different kettle of fish.

Unless you changed the default update check interval from every 24 hours you would have missed 0.5.9 because it lasted less than that lol.

I had to change the format of the search hits to show who has performed the search, that's why they reset. They are still persisted across sessions. The upload counters should not have reset though.


The negative tree lists files which are not shared but are inside a watched directory. If you see a directory there it just means the directory is shared, only if you see a file inside such a directory it means that specific file has been explicitly unshared. The negative tree display is more for debugging purposes as you can't really do anything with the tree, it's read-only.

It's impossible; the point of certificates is that they are a snapshot of the file at a specific time. If you want, you can delete the certificate file from the ~/Library/Application Support/MuWire/filecert directory but as the warning says someone may have already gotten it from you. There is no problem issuing a second certificate though, just click "Certify" again.

No wonder. Mine's set to 48 hrs but I don't recall manually changing it.
Will the certificate upload show in the upload window? If yes I'm safe on this occasion.

The certificates folder is a little confusing when you have many. Since I certified all simultaneously there was no time/date indicator either to give a hint. I was not enthusiastic about opening up over 1k of certificates to find several dozen. So I started them from scratch. Unless a file has been changed I presume the certificate would be identical to the original in any case (with exception of date and time listed within.)