I might think about basing something like this on my FreenetGUI, but I would have to find a way to get it to read ID3 tags and bitrates etc...
--Jeff ----- Original Message ----- From: <[email protected]> To: <freenet-dev at lists.sourceforge.net> Sent: Thursday, July 27, 2000 9:25 AM Subject: Re: [Freenet-dev] An opportunity > > On Thu, 27 Jul 2000 10:03:01 BST, Ian Clarke writes: > > > So, Napster has been shut down. > > > > This is probably bad news from a freenet point-of-view since it means > > that we will probably see a marked increase in downloads as-of Friday, > > despite Freenet still being incomplete. > > > > There is, however, an opportunity for someone here to take advantage of > > this using Freenet. I am not saying it is nescessarily a great idea, > > but if someone is going to do it, I would rather they do it in > > cooperation with us (since, because Freenet is GPL, there is nothing to > > stop someone from doing this without our say-so). > > > > If someone created a simple (initially Windows) piece of software based > > around 0.2 specifically designed for distribution of mp3s (as has been > > discussed in the "LARS" thread), then at least it would serve as an > > effective test of Freenet. We should be cautious, however, to ensure > > that people are encouraged to upgrade it when Freenet 0.3 comes out, > > possibly by making it time-limited to 1st September or something. It > > should, of course, run a server if possible. > > I just got into work, so I hadn't heard about the Napster thing. There's > no way I could hack out anything significant before Friday. I have way > too much else going on in terms of workload and that 'having a life' > thing that keeps cropping up (I promised the kids I'd take them to the > water park this week, and my wife wants me to help clean house). It > looks like I'm out of the picture if the deadline is Friday. Sorry. > > History calls, dudes. If you don't mind some occasional press questions, > and a possible nasty lawsuit, it's time to step up to the plate. All I > had to offer was the idea that you can really simplify things by assuming > that everyone already knows the exact file name of what they want to > request. Use non-Freenet techniques to announce & list what files are > available. Do *not* use this for sharing programs, since it's trivial > for someone to insert a rogue file under a known name -- virus city! > Keep in mind that it's a temporary stopgap only. > > Oh, one more point. The file format I quickly offered earlier is not > well-thought-out. Consider it more carefully before you commit to > something, since the file name will in effect be your most critical > piece of user-interface data. For example, I now realize that you'd be > better off adding an extra field or two in the file name to show the > file size (in bytes) and perhaps a hash/crc value. Keeping that as a > separate data item is too dangerous and complicated for a quick ugly > hack like this. The user could just look at the file name & file size > to see if they match. In rare cases they could run a separate program > to generate a matching hash/crc value to see if it matched the one in the > file name, but I doubt if that will be used much in the real world. > > Oh, and you could dump the field for album name. For the most part, > "albums" are a historical artifact related to the manufacturing costs > of the distrubution medium. No need to prop it up. Most people just > wanted a particular song, not a particular album. They can search Google > or something if they really want to find out what songs were in an album. > > So, one posible format would be: > > - field for some kind of tag to identify the rest of the format > - field for artist/group > - field for song name > - field for encoding (just something to differentiate different > attempts to encode the same song or song segment). > - field for a hash/crc/whatever value of some kind > - field for the last 8 digits of the file size (in bytes) > - field at the end for ".mp3" or ".mp4" or whatever. It may be a good > idea to force it to only a few value types, to discourage people from > downloading any sort of program this way. Those who are smart enough > to safely share programs this way should be smart enough to change the > code that disallows executable exensions. Long term, this last field > & the restrictions on it are pretty dumb; but it might actually help > for the quick-hack purpose here. > > > Ack. 'Gotta get back to my real job. Have fun... > > > --Will > (Not speaking in any way for my employers, who probably will think I've > gone insane if they ever read this.) > willdye at freedom.net > > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev > _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
