I've been thinking of altering Freebase's RSS feed so a gnutella client can subscribe, and can queue up a new file as soon as it becomes available (it probably wouldn't be a good idea to do it fully automatically, but just displaying new files in adialog with a description and an option to start a download would be nice). But sadly no client supports that yet. Some BT clients exist that can do that, though (but with torrents, not magnets). I think a feature like that would make file distribution more efficient too (lots of people would be downloading the same file simultaneously).

Someone's writing an rss plugin for Shareaza, but i don't think it's going to be finished soon. Ofcourse, it's pretty trivial to start generating a magma-list and a collection too, in php, but I'd prefer rss, because that's designed for pushing content. (magma lists and collections are more 'pull': the user downloads the file, parses it, and looks at what he wants. With rss, the user only sees the new files, and can choose to download a file as soon as it becomes available).

And using RSS would save me from confusing users with too many choices. They can open the rss file with any reader, and if that reader happens to be a gnutella client, the client can take care of downloading the files as soon as they're available.

Do you mean alt sources or http sources?
If you mean alt sources, it would break the cache, as I'd have no way to track the people that click the magnet (unless I add the cache as a source too).

If you mean http sources: I'm not really sure about which one would be best. I'd like to be able to send the http sources selectively, because if I just send them with every download, you might aswell just do http downloads. The gnutella client will barely download anything from gnutella. I'd just send a http source if there are no or few alt sources available for that file. And if people copy the magnet to their own site, I can update the http source without breaking the copied magnet.

A drawback would be that it'd tie the cache more to the website. http sources will have to be stored in another table, and that would be the table where all the files on freebase are stored. With adding http sources to the magnet, I wouldn't have that problem (but the http sources would be there every time, making every download essestially a http download).

edit: i tried sending a http source through the cache, but Phex doesn't accept it. (probably a protection so http sources don't end up in the alt source mesh). In fact, I think I tried doing it before with Shareaza, and I removed it again when it didn't work. So I guess I'll have to add sources directly into the magnet then.

I'd also like to know where exactly Phex stores its debug log (on Linux).

Hi Jonne,

Phex can in fact interpret and output RSS-Feeds, they just aren't included in the subscriptions, because I was a bit vary about writing code which would interpret every xml-file. I fully trust my codings skills to write something which allows a malicious xml-file to do quite nasty things, so I kept my fingers away from making xml-readouts automatic.

But if you include magnets as <link>-tag, phex can already get the magnets from them.

Besides: With magma-subscriptions, it is "push" too: The user subscribes, and Phex gets him/her every new file automatically (I hope we'll have a file-selection dialog someday, but I gave up the try this weekend after several hours). Files which are already in the share should not be downloaded again.

I'd like it very much to have rss-feeds with magnets (though I still prefer Magma-lists, maybe because I wrote the specs ;) ... I have some neat ideas, how they could be used in the future, but I don't know if someone will take up that idea, or if I will be able to code well enough to realize it in due time).

About additional sources: I thought about http-downloads, sorry for the braintypo...

Using http-sources, you can still have the clients mainly use Gnutella, and you can use slow webspace to jumpstart the magnets. I get around 300kB/s for popular files via Gnutella without http-source, and since my line can't deliver more juice, a http-source would be mostly insignificant as soon as the download mesh starts to kick in (and if the clients are programmed correctly, they won't even touch the http-source, when they have enough altlocs and get the full speed from them).

Gnutella can definitely outperform http, at least if you don't have a highspeed webpage and serve popular files. And even if 50% of the file come from the http-server, that's 50% saved bandwidth. For a managed server you could also simply reduce the speed it gives users for the files, and Gnutella takes the lead again.

bummer,
I already use the <link> tag for the link to the page that contains the magnet (and ed2k) links. Any chance in adding support for the <magnet> tag (or any other tag, <magnet> seems most logical to me)?

That way other readers can keep handling the feed the way they currently do, while gnutella clients can look for the <magnet> tag. (and ed2k clients for the <ed2k> tag, etc.).

I already added a <magnet> tag to my feed, in case you want to play with it. (the &'s are encoded as &amp;'s, because otherwise it wouldn't be valid xml, btw).

Taking the obvious route certainly has some advantages: The rss-feeds work with Phex out of the box!

(I added readout for magnet-tags, just in case, when I dabbled with the magma-reader to also do rss ;) )

Time to add RSS-subscriptions into the next Version of Phex.

Yay!

Time's up :)

The SVN Version of Phex now integrates rss-download and rss-subscription.
I tested it with your page, and it works. *happy*

Still missing is recognition of your sha1 (which is lowercase and longer than the one Phex reads out; what's the difference between the two ways of encoding the sha1? The one I know from magents is uppercase... ).

actually, the lowercase is completely wrong. I changed it to lowercase because it takes up less room (horizontally), and looks nicer, because i thought it didn't matter (Shareaza converts them to uppercase internally or something). But apparently the case matters in hashes, so I'll have to fix it. (give me a few minutes ;) ).

edit: sha1 and bitprint are uppercase now.

great!

Base32 is explicitely case-insensitive. That's a feature, not a bug. Emitting uppercase only is a good practice but you have to handle them in either case.

Relevant wikipedia article

Although I'll try to make sure all sha1/tth hashes are uppercase on freebase, just to avoid problems with clients that haven't implemented it 'correctly'. If you see any that are still lowercase, let me know.

ok