[00:05:44] <The_8472> ok, that bug should be fixed in a few hours once people get the update
[00:06:46] <klapaucjusz> Okay, I was doing something stupider.
[00:06:50] <klapaucjusz> I was sending the values list.
[00:07:12] <klapaucjusz> ...but I spliced it into a dictionary instead of putting it into the list.
[00:08:04] <Andrius> yeah, and you were wondering why announce doesn't work...
[00:09:50] <The_8472> nothing serious. just a few 100 nodes sabotaging the DHT ^^
[00:10:34] <Andrius> that's like what, 99% of ipv6 dht?
[00:10:40] <The_8472> yup
[00:12:20] <klapaucjusz> Andrius: no, 100%.
[00:12:36] <klapaucjusz> We both had a similar bug.
[00:12:51] <klapaucjusz> Having independent implementations guarantees robustness.
[00:13:53] <The_8472> well, the last update i rolled out prevented nodes from properly decoding received values
[00:14:12] <The_8472> i mean that fixed the issue which prevented nodes from ...
[00:14:25] 
[00:14:34] <The_8472> this one will hopefull fix the issue that keeps them from SENDING it ^^
[00:14:36] <klapaucjusz> (Two guys as good as us three, there isn't even one)
[00:15:59] <The_8472> klapaucjusz, what are you encoding into your version string?
[00:16:24] <The_8472> ... we should have made version a list. 1 string, 1 integer
[00:16:37] <The_8472> oh well... it's not as if we haven't made the same mistake before
[00:16:45] <JudgeSHAD0W> http://www.sctimes.com/article/20091117/NEWS01/111170004/Sounds-of-silence?-Fees-spur-venues-to-scrap-live-music
[00:17:17] <klapaucjusz> The_8472: TR plus the Subversion revision number
[00:17:25] <klapaucjusz> ...or JC and two binary zeroes
[00:17:43] <The_8472> the number as string or as binary?
[00:18:19] <klapaucjusz> Binary.
[00:18:24] <klapaucjusz> Big-endian.
[00:18:56] <The_8472> ok, we're doing something similar
[00:19:22] <The_8472> AZ + a short in network byte order which is encoded from the concated version number
[00:19:36] <The_8472> so 1.3.2.2 encodes as 1322 in binary
[00:19:59] <The_8472> as does 1.3.22 but who cares ^^
[00:21:41] <Andrius> <The_8472> ... we should have made version a list. 1 string, 1 integer < and it's impossible to change it, because?
[00:22:24] <The_8472> well... we'd have to get others to adopt the scheme too
[00:22:40] <The_8472> running 2 different schemes is even worse than having one that's suboptimal
[00:23:32] <klapaucjusz> You should encode it as 0x13 0x16
[00:23:46] <klapaucjusz> And ignore the teeny version number.
[00:24:49] <Andrius> don't you mean 0D16?
[00:25:05] <The_8472> lol
[00:25:06] <The_8472> see
[00:25:18] <The_8472> that happens when you do some arbitrary binary encoding
[00:25:35] <klapaucjusz> Do you auto-update?
[00:25:45] <klapaucjusz> No, I mean 1316.
[00:26:03] <Andrius> The_8472, it's worse when the results are written to source code :)
[00:26:09] <klapaucjusz> 4 bits for major, 4 bits for minor, 8 bits for teeny, patchlevel ignored.
[00:26:20] <The_8472> klapaucjusz, arbitrary
[00:26:39] <klapaucjusz> Oh, well, let's define a version number in XML.
[00:27:59] <The_8472> we could include a changelog too
[00:29:07] <klapaucjusz> Do you know what revision identifiers look like under Darcs?
[00:29:39] <Andrius> The_8472, don't forget full source code so that users can debug stuff easier
[00:30:30] <The_8472> klapaucjusz, no, i don't
[00:31:56] <JudgeSHAD0W> On the subject of weird bugs...
[00:31:57] <JudgeSHAD0W> http://www.wired.com/gadgetlab/2009/11/verizon-accused-of-remote-controlling-droid-truth-somewhat-stranger/
[00:33:47] <The_8472> "Am I the only one who thinks that if Apple issued an over-the-air iPhone software update ? no notice, no confirmation ? that it would generate a Category 5 shit storm?"
[00:34:00] <The_8472> apple-tards are used to that kind of stuff i'd say
[00:34:13] <klapaucjusz> They contain the full minimal context of the current repository.  Worst case (no patch dependencies), that's the full changelog.
[00:34:54] <The_8472> what's the problem with hashes or incrementing counters?
[00:35:20] <The_8472> well, hashes i guess. counters are non-trivial in a distributed environment
[00:37:42] <klapaucjusz> DHT patches are invariant with respect to the order on which they are applied.
[00:38:10] <klapaucjusz> I.e. base+A+B and base+B+A are identical versions if A and B don't conflict.
[00:44:47] <klapaucjusz> The_8472: could you please run the torrent again?
[00:44:53] <klapaucjusz> With an IPv6-DHT enabled peer?
[00:45:23] *** Andrius has quit IRC
[00:46:22] <The_8472> ok
[00:48:22] <The_8472> should be running
[00:49:12] <klapaucjusz> fe66?
[00:49:17] <The_8472> yes
[00:49:57] <klapaucjusz> Ok, works fine.
[00:58:17] *** andar has quit IRC
[01:00:38] *** andar has joined #bittorrent
[01:01:05] *** JudgeSHAD0W has quit IRC
[01:06:01] *** HandheldPenguin is now known as HandheldPenguin`
[01:09:50] *** stalled has joined #bittorrent
[01:23:25] *** stalled_ has quit IRC
[01:23:51] *** rrr_ has quit IRC
[01:25:26] *** Gudy has joined #bittorrent
[01:26:27] <The_8472> hrmgrl... farking private flag -.-
[01:28:23] *** andar2 has quit IRC
[01:33:25] <klapaucjusz> $ git log | grep 'private flag'
[01:33:25] <klapaucjusz>     Ignore private flag.
[01:33:51] <The_8472> not good enough
[01:34:03] <The_8472> if you're the only one who supports pex/dht for that particular torrent
[01:34:12] <klapaucjusz> Yeah, I know.
[01:34:26] *** chelz has joined #bittorrent
[01:34:34] <klapaucjusz> But image there's two people doing that.  They might think they're gay, and let them go.
[01:34:52] <The_8472> oO
[01:34:53] <klapaucjusz> But imagine there's three people doing that.  They might think it's a conspiracy, and let go all three of them.
[01:34:56] <klapaucjusz> But imagine,
[01:35:09] <klapaucjusz> just image there's fifty thousand people doing that.
[01:35:24] <klapaucjusz> (Apologies to Arlo Guthrie.)
[01:35:44] <The_8472> that reference is lost on me
[01:36:13] <chelz> something in reference to woodstock
[01:36:13] <klapaucjusz> http://www.youtube.com/watch?v=5_7C0QGkiVo
[01:37:06] <chelz> oh god that thing is so long. i tried to listen to it once but dropped out in the secondhalf somewhere.
[01:37:23] * klapaucjusz mutters something about the MTV generation
[01:37:40] <chelz> at least i know about it :P
[01:37:45] *** A9[idle] has quit IRC
[01:39:53] <klapaucjusz> chelz: here's one that's short enough, and is a good example of Arlo's style
[01:39:54] <klapaucjusz> http://www.youtube.com/watch?v=Ysl17A0yFME
[01:40:19] <klapaucjusz> (listen at least until he starts speaking nonsense)
[01:40:41] <chelz> ah thanks
[01:40:41] <chelz> alright
[01:42:52] *** burris has quit IRC
[01:45:32] *** init0 has joined #bittorrent
[01:57:12] *** init0_ has quit IRC
[02:07:12] *** rrr_ has joined #bittorrent
[02:24:39] *** waldorf_ has joined #bittorrent
[02:26:17] <klapaucjusz> Heh.
[02:26:26] <klapaucjusz> There's an estimated 100 nodes in the IPv6 DHT.
[02:26:51] <klapaucjusz> There's an estimated 300 torrents tracked by the IPv6 DHT.
[02:26:59] <klapaucjusz> The estimated number of peers per torrent is 1.
[02:27:12] <klapaucjusz> (Not one-point-something, exactly 1.)
[02:28:06] <The_8472> well, the probability of such a small amount of people sharing the same torrent is rather low
[02:28:27] <The_8472> and i'm seeing the same... 31 stored keys on my node. 31 stored values
[02:29:30] <The_8472> well, and the DHT size estimator reports the same order of magnitude at least ^^
[02:29:46] <The_8472> the noise is waaay too high with that few nodes to build a good average
[02:30:01] <The_8472> i'd probably have to work with medians instead
[02:33:18] <klapaucjusz> You released fixed version?
[02:33:37] <The_8472> i do think so
[02:33:45] <The_8472> takes a while until it's rolled out though
[02:36:04] <klapaucjusz> Okay.
[02:36:33] <klapaucjusz> I've got a few missing features (notably rebinding when the IPv6 address changes), then I think I can start annoying Charles.
[02:39:12] <The_8472> hehe, we already had automatic rebinding because some crappy windows firewalls caused spurious socket closes
[02:39:15] <The_8472> very annoying
[02:48:42] *** waldorf_ has quit IRC
[02:53:00] *** klapaucjusz has quit IRC
[03:12:25] <DHE> well, I'm somewhat surprised to say I'm kinda liking rtorrent...
[03:15:59] *** mxs_ has quit IRC
[03:19:42] *** mxs has joined #bittorrent
[03:45:26] *** gilles_ has joined #bittorrent
[03:46:47] *** gilles has quit IRC
[04:02:44] *** gilles_ has quit IRC
[04:07:07] *** The_8472 has quit IRC
[04:07:28] *** wadim has joined #bittorrent
[04:07:30] *** wadim is now known as The_8472
[04:25:25] *** rrr_ has quit IRC
[04:38:35] *** A9[idle] has joined #bittorrent
[04:41:44] *** A9[idle] has quit IRC
[05:35:23] *** rrr_ has joined #bittorrent
[05:37:31] *** thermal has quit IRC
[06:10:45] *** thermal has joined #bittorrent
[06:14:03] *** K`Tetch has quit IRC
[06:21:57] *** K`Tetch has joined #bittorrent
[06:44:08] *** bt42 has joined #bittorrent
[07:04:34] *** bittwist has quit IRC
[07:21:29] *** goussx has quit IRC
[07:34:58] *** MassaRoddel has joined #bittorrent
[07:49:02] *** Switeck has quit IRC
[07:59:31] *** gilles has joined #bittorrent
[08:02:45] *** goussx has joined #bittorrent
[08:22:41] *** gilles has quit IRC
[08:25:41] *** Andrius has joined #bittorrent
[08:43:59] *** waldorf_ has joined #bittorrent
[08:48:02] *** burris has joined #bittorrent
[09:02:38] *** cyb2063 has joined #bittorrent
[09:07:42] *** chelz has quit IRC
[09:12:33] *** chelz has joined #bittorrent
[09:19:24] *** goussx_ has joined #bittorrent
[09:21:55] *** HandheldPenguin` is now known as HandheldPenguin
[09:22:33] *** waldorf_ has quit IRC
[09:35:47] *** goussx has quit IRC
[09:35:47] *** goussx_ is now known as goussx
[09:47:49] *** rrr_ has quit IRC
[10:04:23] *** hlindhe_ has quit IRC
[10:07:39] *** hlindhe_ has joined #bittorrent
[10:22:11] *** burris has quit IRC
[10:57:38] *** GTHK has quit IRC
[12:38:34] *** thermal has quit IRC
[14:10:01] *** chelz has quit IRC
[15:04:27] *** thermal has joined #bittorrent
[15:19:00] *** bt42 is now known as Brunnn
[15:19:19] *** Brunnn is now known as bittwist
[15:24:19] <TheSHAD0W> http://qdb.us/300291
[16:00:25] *** Andrius has quit IRC
[16:02:52] *** Andrius has joined #bittorrent
[16:11:28] *** rrr_ has joined #bittorrent
[16:54:17] *** waldorf_ has joined #bittorrent
[17:10:22] *** rrr_ has quit IRC
[17:17:45] *** waldorf_ has quit IRC
[17:18:04] *** burris has joined #bittorrent
[17:34:16] *** waldorf_ has joined #bittorrent
[17:44:22] *** cyb2063 has quit IRC
[17:54:09] *** L337hium has joined #bittorrent
[17:58:56] *** gilles has joined #bittorrent
[18:00:57] *** andar2 has joined #bittorrent
[18:24:13] *** waldorf_ has quit IRC
[18:33:02] *** goussx has quit IRC
[18:53:24] *** Miller` has quit IRC
[19:00:45] *** Switeck has joined #bittorrent
[19:01:00] *** goussx has joined #bittorrent
[19:04:01] *** waldorf_ has joined #bittorrent
[19:05:05] *** swinokur has quit IRC
[19:13:14] *** GTHK has joined #bittorrent
[19:23:09] *** waldorf_ has quit IRC
[19:24:55] *** waldorf_ has joined #bittorrent
[19:29:29] *** swinokur has joined #bittorrent
[19:49:30] *** HandheldPenguin is now known as HandheldPenguin`
[20:13:23] *** bittwist has quit IRC
[20:14:36] *** gilles_ has joined #bittorrent
[20:18:40] *** Snoopotic has joined #bittorrent
[20:31:04] *** gilles has quit IRC
[20:31:04] *** gilles_ is now known as gilles
[20:41:03] *** bbelt16ag has quit IRC
[20:54:46] *** gilles has quit IRC
[20:54:59] *** GTHK has quit IRC
[20:55:03] *** rrr has joined #bittorrent
[20:59:14] *** GTHK has joined #bittorrent
[21:02:40] *** bittwist has joined #bittorrent
[21:22:55] *** L337hium has quit IRC
[22:02:46] *** Aaron_Cannon has joined #bittorrent
[22:03:45] *** Aaron_Cannon has quit IRC
[22:10:03] *** gringochapin has joined #bittorrent
[22:11:04] *** gringochapin has quit IRC
[22:13:41] *** andar2 has quit IRC
[22:25:41] *** JaVaSan has joined #bittorrent
[22:26:45] *** gringochapin has joined #bittorrent
[22:28:47] <gringochapin> Hi all. Does anyone know if any attempt has ever been made to create a sudo-tracker, one which uses DHT to return peer results? Any thoughts on why such a tracker wouldn't work/would be a bad idea?
[22:30:19] <Andrius> there was (and still is) an idea for that in my head, other than that I haven't heard about anything like that
[22:31:47] <Andrius> downsides: you have to either announce often or have slow startup
[22:32:18] <Andrius> not very scalable, since dht announce is not a trivial http request like with normal trackers
[22:32:55] <pvvni> gringochapin: isnt that what magnet links do?
[22:37:01] <gringochapin> andrius: Yeah, the initial request would be slow to fill, and before you could get the info, the request would most certainly time-out. However, if you returned an error, most clients should retry in a relatively short amount of time, giving you a chance to hopefully have some data to share. Alternatively, you could hang on to the data and just return no results until their second query.
[22:37:59] <gringochapin> pvvni: No. Magnet links only give you the hash of the torrent. They don't tell you where to find it. For that you have to use DHT or the tracker(s) listed in the URI.
[22:38:18] <Nolar> gringochapin that's kind of what we're doing to handle mldht magnets that dont have azdht peers
[22:38:51] <gringochapin> andrius: also, you would probably want to do a lot of caching, so popular torrents might not cause a delay.
[22:39:04] <Andrius> returning an error is a bad idea, it's possible to set announce interval to low value until no peers are returned and later set it to something normal
[22:39:55] <gringochapin> andrius: Announce interval... of course. Forgot about that.
[22:39:55] <Nolar> but dht tracking can be slow
[22:40:02] <Andrius> caching is obvious, since returning peers wouldn't happen in realtime
[22:40:09] <Nolar> but a http-dht tracker gateway is technically doable
[22:40:55] <gringochapin> I was just looking for a project, and this looked like it might be fun and possibly useful.
[22:41:50] <Switeck> Would a lightweight hash-only public tracker and direct .torrent file downloads still be quicker?
[22:41:51] <Andrius> the only use I see it as an addition to clients that don't support dht, adding it as a tracker while running on a local system would give those clients access to dht
[22:42:43] <Nolar> <Switeck> Would a lightweight hash-only public tracker and direct .torrent file downloads still be quicker? << yup
[22:42:50] *** gilles has joined #bittorrent
[22:43:15] <gringochapin> Andrius: exactly. I'm thinking not only old clients, but also those who don't run DHT because their routers can't handle it, or for folks with the odd uncommon other reason.
[22:43:43] <Switeck> I would definitely increase the tracker update delays from the common 30 minutes to 1 or 2 hours.
[22:44:15] <Andrius> for this http-dht tracker?
[22:45:15] *** waldorf_ has quit IRC
[22:45:29] <gringochapin> Switeck: not sure what you mean. Why?
[22:45:50] <Switeck> The tracker is used to bootstrap PEX as much as DHT
[22:46:03] <Switeck> once it's done that purpose, fewer tracker updates means the tracker can scale further
[22:46:04] <Andrius> initial tracker response should set interval to something low and not return any peers, then second response should set interval to higher value
[22:46:46] <Andrius> and such tracker would definitely need to have as little load as possible
[22:47:02] <Switeck> what I've heard about TPB at its peak, they were needing multiple 1 gbit/sec lines for tracker updates and still experiencing bandwidth overloads
[22:47:41] <Andrius> dht would be significantly more bandwidth-hungry than normal tracker
[22:47:42] <gringochapin> Andrius: For sure. :)
[22:47:54] *** bbelt16ag has joined #bittorrent
[22:48:05] <K`Tetch> yeah, we've jsut had a loon ranting for the alst 45 mins about how going to dht/pex is a criminal conspiracy to entrap -  http://opentpb.com
[22:48:23] <K`Tetch> its really funny
[22:52:56] <DWKnight> K`Tetch: whoever wrote that has mercury-laced tinfoil
[22:53:10] <Andrius> it's been a while since I last read something and had no clue what is this stuff I'm reading
[22:53:41] <Switeck> Websites offering .torrent files need not have a tracker associated with them. But seeking torrents via magnet seems silly
[22:54:04] <Andrius> why silly?
[22:54:08] <Switeck> unless you want to claim you're not even offering a (direct) link to "questionable" content
[22:54:34] <Switeck> because it's indirect, increases bandwidth just to GET the .torrent file
[22:54:41] <gringochapin> switeck: seems like a good reason to me. Also, it could, slightly, cut down on bandwidth.
[22:55:07] <gringochapin> switeck: bandwidth for the web site that is.
[22:55:14] *** Gudy has quit IRC
[22:55:15] <Andrius> Switeck, but it reduces traffic of the site that hosts torrents/magnet links
[22:55:25] <Switeck> I'm not so sure
[22:55:50] <gringochapin> Switeck: How do you figure?
[22:55:53] <Switeck> most .torrent files are small
[22:56:11] <Andrius> most magnet links are smaller
[22:56:14] <Switeck> a 100 KB .torrent file is one of the bigger ones.
[22:56:26] <Switeck> I see many that are <10 KB
[22:56:39] <K`Tetch> I made a 540kb torrent file years ago
[22:56:58] <gringochapin> Switeck: My experience is they average around 15-20K. Am I way off?
[22:57:07] <Switeck> and clearly that was exceptional XD
[22:57:12] <pvvni> K`Tetch: stop uploading your "My Little Pony" diarama scans to torrent sites.
[22:57:28] <Switeck> I'd say the .torrent files depend on the nature of what they contain
[22:57:32] <gringochapin> Switeck: Anyway, if you figure an average of 10K, that can still add up quickly.
[22:57:55] <Switeck> a picture compilation of 1000's of pictures, even if they total less than 1 GB, will be a larger .torrent file than a 4 GB video
[22:58:55] <Switeck> yes, 10000 people download the 10 KB file it's still ~100 MB
[22:59:21] <Andrius> also, it's 10000 HTTP GET requests
[22:59:26] <Switeck> direct .torrent file downloads versus magnet+DHT bootstrapping is one of convenience -- if magnets and DHT bootstrapping does not work the vast majority of the time, it is not good.
[22:59:30] <Andrius> which do not exist with magnet links
[22:59:48] <gringochapin> Switick: Anyway, Andrius is right. the magnet links are always going to be smaller, and when you're running a site with hundreds of thousands or millians of visitors, you do whatever you can within reason to reduce bandwidth.
[23:00:39] <gringochapin> and server load.
[23:00:49] <K`Tetch> Switeck - yes, it was about 6.4gb, with 64kb piecesize, I think. I did another with 16mb piecesize, that was 8kb
[23:00:51] <Switeck> same with DHT versus trackers
[23:01:02] <K`Tetch> (was when I was looking at client hashing speed)
[23:01:31] <The_8472> <Nolar> but a http-dht tracker gateway is technically doable <- partially
[23:01:38] <The_8472> only to get peer lists, not to PUT the ip
[23:01:40] <Switeck> downloading a .torrent from a website pales compared to just a day or 2 of tracker updates
[23:03:51] <Nolar> The_8472 put in the mldht?  right, we dont do that
[23:04:15] <Nolar> we rely on the clients themselves to do that
[23:05:01] <DWKnight> http-dht bridging does have some limitations
[23:05:13] <DWKnight> but it is plausible to do within those limitations
[23:05:22] <Nolar> ya, it's a last resort feature
[23:06:16] <The_8472> Nolar, its technically not possible anyway to proxy that
[23:06:43] <Nolar> anyway, all this TPB hoopla is just noise making, since they still distribute .torrent files directly, with trackers
[23:07:26] <Nolar> at least it's not their Bittorrent 2.0 project that's going to "change the world"
[23:07:41] *** _rafi2_ has joined #bittorrent
[23:11:57] <gringochapin> Switeck: In my experience, DHT and magnet links work a majority of the time.
[23:12:22] <The_8472> basically depends on the # of peers/seeds in the torrent
[23:12:28] <The_8472> in the swarm
[23:13:04] <gringochapin> True, though it's only likely to improve, as more clients get upgrade to support the new standards.
[23:13:13] <The_8472> which you obviously cannot know with dht-only torrents. since there are no DHT scrapes
[23:14:57] <Nolar> i cant vouch for the mldht magnet handling, but the azdht one is quite reliable, even if there's just one peer with the .torrent
[23:17:37] <Switeck> I've found even tracker scrapes to not be good enough, especially for public torrents prone to hit-and-runners (<100 MB size)
[23:18:01] <gringochapin> Now all we need is a distributed search protocol, which is well resistant to fakes, floods, and the like. Not sure such a thing exists, but it seems like the logical next step.
[23:19:05] <Switeck> In my very-out-of-date study of Gnutella's network for searches, keeping out hostiles is incredibly hard.
[23:20:03] <gringochapin> Switeck: That agrees with my thinking as well. It's a tough problem.
[23:20:59] *** andar2 has joined #bittorrent
[23:23:18] <Switeck> if spammers ever get the notion that DHT can be used for intrusive advertising, we're screwed :P
[23:23:22] <The_8472> search is feasible. flooding can be made expensive at least. keeping out fakes? uhh, no, not really
[23:23:45] <Nolar> ya, human lists are pretty good
[23:24:20] <gringochapin> A possible alternative would be a network which supports signed results. For example, a group could sign and revoke signatures on various infohashes and associated keywords, but all the searching would be done in the network, rather than on a web site. Using strong cryptographic methods, it should even be possible to allow such signatures to be inserted into the network anonymously. Then,...
[23:24:22] <gringochapin> ...each user could choose which "signer groups" they choose to trust.
[23:24:22] <Nolar> that said, one can do a distributed search ranked by real-user usage/ratings/etc
[23:24:56] <The_8472> then you'd have to prevent them from faking the ratings
[23:25:23] <Switeck> better to strengthen points-of-failure than moving them around.
[23:25:35] <The_8472> gringochapin, well... we did something like that with the azdht, the dht-feed plugin. basically allowed you to do RSS-over-DHT
[23:25:39] <The_8472> but nobody ever used it
[23:26:20] <The_8472> but yeah, human-managed lists of torrents are probably the way to go
[23:26:47] <Nolar> heh, parg and i were just talking about bringing that plugin back :)
[23:27:20] <The_8472> well, i think the basic idea was good, the approach bad though
[23:27:36] <gringochapin> The_8472: Interesting. I'm thinking more along the lines of a replacement for torrent indexers.
[23:27:53] <Switeck> trick GOOGLE into doing it XD
[23:28:09] <The_8472> my idea would be a) store the public key under sha1(public key) and then a list of infohashes under sha1(public key + "constantA")
[23:28:15] <Nolar> The_8472 needs a proper user ui
[23:28:40] <The_8472> *signed list
[23:28:58] <The_8472> and then you can just lookup the infohashes and get the torrents magnet-style
[23:29:15] <The_8472> Nolar, problem with that plugin was that it needed virtual torrents. and a new one for every update
[23:29:35] <The_8472> that seems too clunky
[23:30:05] <The_8472> since you use the DHT to get a pointer to the current signed torrent, download the torrent which then contains an RSS feed which you download in turn via the DHT
[23:31:27] <gringochapin> The_8472: I see a couple problems with that aproach. First, you'd have to replace the entire list when adding an additional torrent. Also, if a group had a lot of files, it could quickly become unwieldy. Better to sign each infohash individually. Also, it should be possible to revoke a signature once it has been created.
[23:31:51] <The_8472> hurr
[23:31:56] <The_8472> revocation == a nightmare
[23:32:04] <The_8472> especially in a decentralized system
[23:32:15] <Switeck> I'm finding with torrents, lots of files are a nightmare if they're individual torrents.
[23:32:22] <Nolar> The_8472 ya, we'd write it differently if we are to bring distrbuted feeds as a real feature
[23:33:09] <Nolar> especially since the tech has advanced quite a bit since that plugin was initially coded
[23:33:17] <gringochapin> The_8472: I don't think so. It's just like a signature, but instead of a signature from the group that means, "trust this" it means "don't trust this".
[23:33:33] <The_8472> gringochapin, signatures cause significant overhead. you can only transport about 1200 bytes of payload in each DHT packet
[23:33:58] <The_8472> gringochapin, it's not that easy in a distributed environment
[23:33:58] *** SuperAzim has joined #bittorrent
[23:34:21] *** SuperAzim has left #bittorrent
[23:34:29] <The_8472> since you have to make sure that users actually SEE the revocation. and not just the original data + old (now revoked) signature
[23:35:38] <gringochapin> The_8472: I agree. Anyway, for a distributed search network, I don't think it would be workable to build it on top of DHT without some serious modifications.
[23:35:52] <Nolar> one could do revokes in 8h pretty easily ;)
[23:35:56] <The_8472> it isn't
[23:36:12] <The_8472> DHTs are terribly ill-suited keyword searching for example
[23:36:27] <The_8472> Nolar, not if you consider replay attack
[23:36:29] <The_8472> s
[23:36:38] <Nolar> i suppose
[23:37:33] <Nolar> gringochapin certainly on the mldht
[23:37:55] <Nolar> azdht is far better equiped for something like that, but still would be a giant pain in the ass
[23:38:02] <Nolar> ask the emule folks ;)
[23:39:17] <The_8472> natural language search with unicode... if you consider asian scripts then it should be quite clear that a DHT is not the right approach
[23:39:26] <The_8472> at least not a hashbased one
[23:39:31] <gringochapin> No question. It would be a lot of work to build something like that, but think of the headache for the anti-P2P folks. :) No more trackers, no more indexes. :) Anuyway, it's just something I've been pondering for the past couple months.
[23:40:19] <The_8472> they're only going after the really big fishes now and focusing on legislation (3 strikes, anyone?) now
[23:40:37] <The_8472> so the real next step would be providing anonymity ala I2P
[23:40:45] *** medecau has joined #bittorrent
[23:40:56] <The_8472> but that's only possible with sacrifices in bandwidth
[23:41:24] <gringochapin> Yes. Which may become the only option in some countries.
[23:41:26] <Nolar> ya, the dreaded "my downloads are slow" ....
[23:42:15] <The_8472> without internet they would be even slower ^.^
[23:42:25] <Switeck> sacrifices in bandwidth like 1/2 to 1/5th your total upload speed = your new download speed, while you still upload at full speed.
[23:43:00] <The_8472> symmetric connections might become a lot more popular
[23:43:10] <Switeck> not at all
[23:43:17] <gringochapin> But if they manage to kill the big fish, then the little fish become the new big fish, and once you find effective ways to kill the big fish, the little ones become that much easier to intimidate and ultimately kill off.
[23:43:32] <Switeck> more upload will become more popular...being symmetric would be secondary to that.
[23:43:44] <The_8472> symmetric is the optimal case
[23:43:59] <Switeck> only considering this
[23:45:01] <Switeck> Max download being 2-5 times max upload still works just fine for many other things. (But >5 times is nuts!)
[23:45:06] <The_8472> they're optimal for generic P2P too
[23:47:56] <Nolar> <gringochapin> But if they manage to kill the big fish.....the little ones become that much easier to intimidate and ultimately kill off. <<< well, if history serves as a guide, every time they shut down a big fish, 10 more fishes pop up and eventually become even bigger than the first....
[23:48:30] <gringochapin> Nolar: good point. :)
[23:49:03] <Nolar> human/fish nature at its best
[23:53:24] *** andar2 has quit IRC





top