Idle thoughts III

I was reminded of some of the flaws with current paradigms for sharing user-created content when I tried to find some old warrior movies. There weren't any links on a popular direct-download site; and despite this warrior's popularity there wasn't a single mention of them on the largest torrent site >_< I deleted everything I had from them a long time ago, partly because I didn't like paladin abuse but mostly to save space.

The current phenomenon of torrent collections has two interesting features. Torrent seeders rely on being able to describe the torrent contents to accomplish their goals: a sense of ownership of the files included in the torrent, and spreading their popularity as a torrent seeder or other provider of information such as a website. Some torrent sites offer exceptional ability to describe the contents and status of a torrent, such as a well-formatted description space and torrent classification or even forum threads that accompany torrents; when the source of torrent files does not allow this descriptive information, seeders rely on including text files within the torrent to support this sense of ownership of the files.


When you create an additional like semantic (mangle technical meanings) file layer beneath the torrent, the seeder no longer owns the files. Instead they control the connections between, and groupings of files. At the same time the particular collection that a leecher is constructing may not be the one held by the seeds they are leeching from, due to the 'JIGDO' concept from working at the file level. So once again it becomes the responsibility of the torrent site to provide this association between seeds and ownership.

There's no way around having an entirely new bittorrent client implementation, due to the requirements:

• Download a torrent for the single file you are interested in, but leech off of collections of many files that include this one file
  
• Create a new collection out of files previously downloaded, that is receptive to requests from other collections and single-file torrents
• Seed a new collection by partly using old ones, to avoid dead torrents from losing seeds
• Associate files with certain names in one torrent, with the same files in another torrent that are named differently

This last one in particular means you can't just transparently include several torrents in one, that would seed independently but show up as the sum of unique peers in torrent UI; because the current bittorrent protocol has torrent names, as well as file names as unique and part of the way to identify that torrent. Multiple seeders with different file names could not connect to the same torrent unless some or all single-file torrents within torrent collections were corrected to the same filename, but this is contrary to the idea of torrents being independent of any single website to be able to work. Seeders that could not connect to a torrent database would not be able to construct valid collections that linked to other torrents.

Anyway so I was wondering if you couldn't create linked torrents using DHT on a per-file basis because of seeder ownership requirements and you would instead have to just show very well all the torrents that contained a particular file you wanted; but this would prevent you from doing the first item in the above list, downloading the torrent for a single file. If you did want to seed after downloading, you would have to continue to manage single torrents and this leads to torrent clutter.

So that's why change is necessary. You can either keep trackers pretty much the same as they are, and rely on clients to create standardized hash things for pieces and files and then use DHT to find files in torrents on other peers; or you can do that AND also change trackers work on the file level by treating every major file as its own torrent without regard for its name, so peers can find seeders with the file by tracker as well as DHT.


This only works for files you'd want to include in multiple collections... and I still don't know what impact it would have for large numbers of files >_< it's possible that streamlining things would end up reducing the total number of things tracked by the tracker; but some torrents have a lot of files. Maybe best if trackers in this implementation only tracked pre-registered files, for which it had a verified/official hash and so on. It might still be possible to search for other files via DHT, especially if using a smart algorithm which assumes that a seeder with one file from a large torrent may have many other files from it too; and in the case with a non-registered anonymous/generic tracker.




Torrent collection tracking could get complex. Again, the idea is that even when files have their own separate pages and the torrent collection seeder is neither required nor allowed to provide an in-depth description of the torrent contents (or advertisement for their website...), other details about a torrent can have a significant effect on someone's decision whether to use that torrent or another one. It would be possible to have an implementation where users could explore the torrent-space entirely within the torrent application, by showing which torrents you leech from and letting you select for download all files within that torrent, then branching these off into more primary torrents for you to explore or even provide feedback or discussion via a statically-linked website; but this would remove what little remains of seeder ownership under a file-descriptive system and would also lock implementation users to a specific torrent website o.0 So that's why any torrent UI feedback would just be informative, not supposed to lead to new torrents; this exploration would be done on any central site which describes the files themselves, as well as providing this information about torrent collections which I still haven't described. omg.


If I had more experience with open source project development maybe I could describe this better >_< Any particular collection of files may importantly be linked to previous collections. It may be a branch from a main collection by a different seeder than the creator of the original collection, it may also be a compilation of various sources or the evolutionary development of a collection that seeks to include a certain number, quality, or focus of files. This may show prospective leechers how a collection was derived and possibly what it led to, contributing to the feeling of ownership even if a different individual branches off a collection to create a more popular torrent that still leeches off the original seeders using the jigdo method.

The files contained in the torrent should also be referenced, this is possible when standardized hashes lets the files be uniquely identified regardless of whether they were renamed. This lets users see descriptions of the contents of the torrent, regardless of who created the collection or how much detail they used to describe its contents (if a description apart from the name is allowed at all)!



mm will say a bit about games. Could even have multiple worlds to live in. Some of these might not allow unique advancement, such as leveling or gaining experience; some might have different rules, such as 'infamy' for killing weak players of a different faction vs becoming a 'murderer' for killing same-faction players in a weakly free-for-all player vs player ruleset, allowing conflicting attitudes to exist in the same game. Or a world that emphasizes group combat and ambushing, lying in wait for convoys to pass by o_O somewhat mutually exclusive with an emphasis on solo PvP as reinforced by ruleset and the activities and progressions given in a game. This also increases the chance that an open source development model could be leveraged to provide more game content and options, using the OpenID authentication model. However, art style and consistency is a major concern and may be one reason for centralization of certain development resources.

Maybe I did, or didn't have anything interesting to say about items, but I need to go... it's late here.

MY SMILEY FACES MESS WITH HTML PARSER UPON EDIT