From zooko at zooko.com Tue Apr 3 17:16:02 2001 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] reference: "Search in Power-Law Networks" Message-ID: I recommend this paper from the Xerox PARC "Internet Ecologies" researchers: http://www.parc.xerox.com/istl/groups/iea/papers/plsearch/index.html I intend to say more about this, and about "scalability" of various topologies, when I have some time. Right now I have a newborn baby and a full-time job so essays on network topology will have to wait. :-) Regards, Zooko From zooko at zooko.com Fri Apr 13 10:20:02 2001 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] Re: Vat Location Service, Meta Tracking, mutable namespaces (was: [E-Lang] A more critical question (was: an example impatience policy)) In-Reply-To: Message from "Karp, Alan" of "Fri, 13 Apr 2001 09:35:47 PDT." <140D21516EC2D3119EE7009027876644031BEDB4@hplex1.hpl.hp.com> References: <140D21516EC2D3119EE7009027876644031BEDB4@hplex1.hpl.hp.com> Message-ID: [Cc:'ing e-lang, mojonation-devel and p2p-hackers, as this is a discussion about the possibility of combining forces on this central architectural component. For background, please see these articles or threads: [1, 2, 3, 4] and probably a dozen more like them of which I am unaware. --Z] Alan Karp wrote: > > I just read Zooko's metatracking page and realized that his system is very > similar to the e-speak advertising service. It appears that Zooko is far > ahead in the area of scalability, data integrity, and what e-speak calls > "community formation", the selection of places to search. On the other > hand, e-speak appears to be ahead in the representation of metadata, search > mechanisms, and the security aspects. Sounds like a natural collaboration > if the parties involved have the bandwidth. This topic is high on my mind right now. I am still chewing on ideas and I'll write about it soon. One thing to be careful of is that "A Plan For Easy Distributed Meta- Tracking"[5] has not been fully implemented yet. Most significantly, current Mojo Nation brokers don't actually keep a local, dynamically maintained list of meta trackers to use -- instead they just use whatever metatrackers are listed in the bootpage at `http://www.mojonation.net:25000/bootpage.txt'. Of the other six "implementation steps" in the Plan, #1 is sort of optional (it might work without it, and it might fail to work even *with* it, although #1 should definitely help), #2,3,4 are done, #5 isn't done (it just means: "manage your local, dynamically maintained list of MTs so that you have an idea of which ones you prefer to use for which purposes") and #6 is questionable in my opinion -- it might be overkill. Then there is the big question: will the system described in the Plan *work*? Without #1, or some other technique like VLS'es "here are the MetaTrackers which know me", or a hash-matching hint (this is the technique that I was dreaming about last night), it is possible that you might be unable to find the current contact info for a given peer, because he published to a set of MetaTrackers none of whom you know. (Actually, even *with* any technique that I can imagine, you might still suffer this fate, so any argument about this is going to have to be about probability and intuitions rather than something which can actually be proven to work or proven not to work.) Regards, Zooko [1] http://www.eros-os.org/pipermail/e-lang/2001-March/004904.html [2] http://zgp.org/pipermail/p2p-hackers/2001-March/000030.html [3] http://zgp.org/pipermail/p2p-hackers/2001-March/000028.html [4] http://www.parc.xerox.com/istl/groups/iea/papers/plsearch/index.html [5] http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/evil/hackerdocs/distributed_metatracking.html?cvsroot=mojonation From zooko at zooko.com Fri Apr 13 12:41:01 2001 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] distributed resource discovery service Message-ID: [Cc: e-lang, p2p-hackers, mojonation-devel] Someone wrote: > > There is a TR available at http://theory.lcs.mit.edu/~karger/chord.ps > It is public; we hope soon to have a more official publication, but > feel fee to tell other people about the tech report. It is LCS TR > 819. This is very impressive. I like it. This is a nice implementation of the "consistent hashing" approach[1], which I think should be added to Mojo Nation's distributed meta tracking in the form of a "ConsistentHashingHandicapper". (Well, that will take care of the consistent hashing part, but not of the "distributed" (i.e. transitive) consistent hashing part. Nonetheless, one step at a time is the way we get places...) FWIW, consistent hashing is I think the same thing as the "Mask Matching Handicapper" that I proposed on p2p-hackers earlier[2]. It is the case for distributed Meta-Tracking, as well as for block finding, that this (*non*-transitive consistent hashing) can be cleanly plugged into Mojo Nation in the form of a handicapper. Oh! Wait a second, we will have transitive as well in the form of "list meta trackers". Heh. Coool. Regards, Zooko [1] "Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web"; David Karger, Eric Lehman, Tom Leighton, Matthew Levine, Daniel Lewin, Rina Panigrahy; 1997 http://citeseer.nj.nec.com/karger97consistent.html [2] "proposal re: scalability of block publication and fetching"; Zooko http://zgp.org/pipermail/p2p-hackers/2001-February/000019.html From gojomo at usa.net Sat Apr 14 00:30:01 2001 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] Comments sought: Bitzi metadata service Message-ID: <014901c0c4b4$b0aa92e0$71c8a540@tron> Hello! I'd like to invite interested members of this list to visit the developer preview of my company's Bitzi service, at: http://bitzi.com/preview In a nutshell, Bitzi aims to be a community-generated and -maintained catalog about arbitrary kinds of files. Think equal parts DMOZ, Epinions, and CDDB -- except the objects being described are files, tracked by their cryptographic hashes. We don't store or transmit files themselves. All kinds of comments and questions are welcome: here, at our website forums, or via private email. We want our service to be widely useful to P2P developers, so we're especially interested in feedback on our public domain source code and proposed free reuse license. We'd also like to know what kinds of programmatic access would be most helpful. Feel free to forward this URL to associates you think might be interested in Bitzi, but I would appreciate it if you could refrain from posting the preview URL to other mailing-lists or highly-trafficked web logs; we're trying to expand our reach in small stages, at first. Thanks! - Gojomo ____________________ Gordon Mohr gojomo@bitzi.com Founder & CTO, Bitzi From wesley at felter.org Tue Apr 17 18:06:02 2001 From: wesley at felter.org (Wesley Felter) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] AVES? Message-ID: http://www.cs.cmu.edu/~eugeneng/research/aves/ "AVES restores bi-directional connectivity to hosts that do not have IP addresses." It looks like it just shifts the IP address demand to waypoints and their diagrams seem to suggest that it spoofs return adresses as well. Posters on /. have pointed out that if you drop the asymmetric routing it just looks like Yet Another VPN. Any other thoughts? Wesley Felter - wesley@felter.org - http://felter.org/wesley/ From gojomo at usa.net Tue Apr 17 21:30:01 2001 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] AVES? References: Message-ID: <009101c0c7c1$2696b380$6401a8c0@bitcollider.com> Wesley Felter writes: > http://www.cs.cmu.edu/~eugeneng/research/aves/ > > "AVES restores bi-directional connectivity to hosts that do not have IP > addresses." > > It looks like it just shifts the IP address demand to waypoints and their > diagrams seem to suggest that it spoofs return adresses as well. Posters > on /. have pointed out that if you drop the asymmetric routing it just > looks like Yet Another VPN. > > Any other thoughts? In the way that the diagram suggests that one direction of communication is spoofed, it reminds me of TriangleBoy... https://fugu.safeweb.com/webpage/tboy1.php3 ...which I think is pretty clever, but maybe not a stable long-term solution. In that it requires you to run a new "listener" on your NAT device -- well, if you could do that, you don't need the "waypoints" at all. You just report your contact address to the outside world as being the listening NAT, which you remotely control from the inside. - Gojomo From oskar at freenetproject.org Wed Apr 18 10:09:02 2001 From: oskar at freenetproject.org (Oskar Sandberg) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] AVES? In-Reply-To: <009101c0c7c1$2696b380$6401a8c0@bitcollider.com>; from gojomo@usa.net on Tue, Apr 17, 2001 at 09:35:46PM -0700 References: <009101c0c7c1$2696b380$6401a8c0@bitcollider.com> Message-ID: <20010418160348.D633@hobbex.localdomain> On Tue, Apr 17, 2001 at 09:35:46PM -0700, Gordon Mohr wrote: <> > In that it requires you to run a new "listener" on your NAT device -- > well, if you could do that, you don't need the "waypoints" at all. > You just report your contact address to the outside world as > being the listening NAT, which you remotely control from the > inside. I don't think that is completely true, in that AVES system is meant to restore complete connectivity to the host behind the NAT, not just a limited number of ports that can be forwarded from the firewall. I mean, if the DNS of the host behind the NAT resolves to the firewall, a naive computer from the outside will just send packets to the firewall which the firewall won't know which of the hosts behind it they are intended for (some protocols like HTTP contain destination host information, but not all.) The idea with AVES waypoint is (as far as I understand the page, I didn't read the full paper) that it wraps the packets with information telling the firewall which of the hosts behind it they are intended for. As I understand it, it would work something like: Alice wants to contact Bob, and AVES user behind the firewall. Alice does a DNS lookup, which reaches the the Donny, the DNS server. Donny selects a waypoint, Wally for Alice's traffic to Bob, and contacts Wally saying: "For all packets from Alice, you should send them to Bob's NAT with the extra information that they are intended for Bob". Then Donny gives Alice Wally's IP address, and she contacts him thinking that is Bob's true address. Wally then wraps and forwards _all_ traffic from Alice unconditionally to Bob's NAT, which unwraps it and sends it to Bob. This means that for every host behind a NAT that Alice wishes to contact at the same time, she needs to use a different Waypoint. So Bob's NAT and Wally could be the same host, but if Alice then wishes to contact someone else on Bob's network, she would need another waypoint. In order to maintain enough waypoints for people to be able to connect (they'll need a lot, since whole networks behind a NAT appear to come from the same IP, and could be connecting to thousands of hosts at once), they seem to be proposing that everybody who uses this on the their network also allow their firewall to be used as a waypoint for others (http://www.cs.cmu.edu/~eugeneng/research/aves/). On the whole it's a not stupid system, but a little complicated and definitely an uncomfortable hack. It's biggest advantage over anything I have seen before is that it allows not only Alice, but also Bob, to remain ignorant of the connectivity problem. The biggest disadvantages is the dependence of DNS and waste of resources of having to proxy through Waypoints. -- 'DeCSS would be fine. Where is it?' 'Here,' Montag touched his head. 'Ah,' Granger smiled and nodded. Oskar Sandberg md98-osa@nada.kth.se From hal at finney.org Wed Apr 18 10:35:01 2001 From: hal at finney.org (hal@finney.org) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] AVES? Message-ID: <200104181728.KAA06789@finney.org> Oskar Sandberg, , writes, regarding AVES: > As I understand it, it would work something like: > > Alice wants to contact Bob, and AVES user behind the firewall. Alice does > a DNS lookup, which reaches the the Donny, the DNS server. Donny selects a > waypoint, Wally for Alice's traffic to Bob, and contacts Wally > saying: > "For all packets from Alice, you should send them to Bob's NAT with the > extra information that they are intended for Bob". > Then Donny gives Alice Wally's IP address, and she contacts him thinking > that is Bob's true address. Wally then wraps and forwards _all_ traffic > from Alice unconditionally to Bob's NAT, which unwraps it and sends it to > Bob. An IP connection is the combination of an address and a port number. Typically for an HTTP connection we use port 80. An alternative to AVES is to configure your NAT box to do port forwarding. All connections on port 80 to the NAT address get transparently forwarded to one particular internal "hidden" host. Other ports could be forwarded to other hidden hosts. A conflict arises if you want to have the hidden host listen on the same port as another hidden host or the same port as one used by the NAT firewall. This is unfortunately the usual case, as everyone wants to use port 80 and certain other well-known ports. To set up a connection to port 80 on a particular hidden host, it must be mapped to a waypoint machine which does not already have its port 80 assigned to someone else. The mapping on the waypoint machine will probably be port+address specific, not just address specific. That is, a particular waypoint will be instructed to forward all connections on port 80 to a particular NAT machine, using the AVES protocol. The AVES protocol messages will tell the NAT machine which hidden host is to get the connection. I don't think the waypoint needs to be client-specific. Once a particular hidden host is assigned a waypoint (which action is triggered by the DNS request), that same waypoint can be used for other connections to the same host by other clients (although this might be an unexploited optimization). The DNS server would keep track of which hidden host-port combinations currently have waypoints assigned. One waypoint can proxy for a number of hidden hosts (from the same or different internal networks), as long as they are all listening on different ports. While it can basically only proxy for one HTTP server, it could also proxy for FTP, Napster, Freenet, SSH and telnet servers all at the same time. Nevertheless a substantial part of the traffic is likely to be HTTP on port 80, so in practice we will see close to one waypoint host being needed for every hidden host connection in existence at a time. As Oskar notes, this will be a lot of waypoints. Hal From oskar at freenetproject.org Wed Apr 18 12:31:02 2001 From: oskar at freenetproject.org (Oskar Sandberg) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] AVES? In-Reply-To: <200104181728.KAA06789@finney.org>; from hal@finney.org on Wed, Apr 18, 2001 at 10:28:44AM -0700 References: <200104181728.KAA06789@finney.org> Message-ID: <20010418213048.A1542@hobbex.localdomain> On Wed, Apr 18, 2001 at 10:28:44AM -0700, hal@finney.org wrote: > Oskar Sandberg, , writes, regarding AVES: > > As I understand it, it would work something like: <> > To set up a connection to port 80 on a particular hidden host, it must > be mapped to a waypoint machine which does not already have its port > 80 assigned to someone else. The mapping on the waypoint machine will > probably be port+address specific, not just address specific. That is, > a particular waypoint will be instructed to forward all connections on > port 80 to a particular NAT machine, using the AVES protocol. The AVES > protocol messages will tell the NAT machine which hidden host is to get > the connection. > > I don't think the waypoint needs to be client-specific. Once a particular > hidden host is assigned a waypoint (which action is triggered by the > DNS request), that same waypoint can be used for other connections to > the same host by other clients (although this might be an unexploited > optimization). The DNS server would keep track of which hidden host-port > combinations currently have waypoints assigned. Maybe I am misunderstanding you, but I don't see how this can work. I mean, you don't tell the DNS server which port you intend to connect to, so how can it return a port specifc waypoint? Once the DNS server has given Alice a waypoints IP, that waypoint has to forward connections from Alice regardless if they are on port 80 or 26451. I mean, it is even possible to have an application that resolves an IP once, and then uses it to connect to several ports (if you run a local DNS server, won't it cache results?) -- 'DeCSS would be fine. Where is it?' 'Here,' Montag touched his head. 'Ah,' Granger smiled and nodded. Oskar Sandberg md98-osa@nada.kth.se From hal at finney.org Wed Apr 18 13:41:01 2001 From: hal at finney.org (hal@finney.org) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] AVES? Message-ID: <200104182035.NAA07540@finney.org> Oskar Sandberg, , writes: > On Wed, Apr 18, 2001 at 10:28:44AM -0700, hal@finney.org wrote: > > I don't think the waypoint needs to be client-specific. Once a particular > > hidden host is assigned a waypoint (which action is triggered by the > > DNS request), that same waypoint can be used for other connections to > > the same host by other clients (although this might be an unexploited > > optimization). The DNS server would keep track of which hidden host-port > > combinations currently have waypoints assigned. > > Maybe I am misunderstanding you, but I don't see how this can work. I > mean, you don't tell the DNS server which port you intend to connect to, > so how can it return a port specifc waypoint? Once the DNS server has > given Alice a waypoints IP, that waypoint has to forward connections from > Alice regardless if they are on port 80 or 26451. I mean, it is even > possible to have an application that resolves an IP once, and then uses it > to connect to several ports (if you run a local DNS server, won't it cache > results?) Yes, I see, you're right. Without knowledge of the port number the DNS server can't allocate waypoints as I described. However there does seem to be a choice between making the waypoint client specific or server specific. The waypoint could either be instructed that all connections from Alice go to Bob, or else that all connections from everyone go to Bob. The problem with the first approach is that it seems possible that Alice's DNS query could come from a different machine than her connection. She may have a local DNS server/cache which attempts to resolve the address, and if it fails, executes a query which eventually reaches the AVES server. In that case, AVES may not know Alice's IP address, but only the address of her local DNS server. (I'm not 100% sure if DNS works this way, though.) To deal with this it would be necessary for each waypoint to proxy for no more than one hidden host at a time. Then any query to that waypoint can be presumed to be for that host. If Alice did cache the results of the DNS lookup for Bob (which point to the waypoint), that would make it hard to reuse waypoints dynamically. However DNS replies have a TTL field which can be used to disable caching. Hal From zooko at zooko.com Sun Apr 22 17:34:03 2001 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] FreeWeb and mutable namespaces Message-ID: Dear David McNab and p2p-hackers: [This is an ASCIIfied version of my web log entry for today. The original is viewable on the web at `http://zooko.com/zooko_current_events.html' or via Mojo Nation at `http://localhost:4004/id/w6jN0Gr9jfccSeNySGzJCS1MlRg'.] Last night I was talking to Amber about making a WWW to Mojo Nation[1] gateway in order to provide a space for John Young's Cryptome[2]. Today slashdot announces FreeWeb[3], which provides a WWW to Freenet[4] gateway, and has a really beautiful graphic on its front page, too. Exciting! Now the first big need that we all have is for an emergent (i.e. decentralized, attack-resistant, scalable) lookup infrastructure from globally unique (hence non-human-friendly) keys to self-authenticating objects, which I think we're about to really solve (see my messages on p2p-hackers: [5] and [6] for some of my recent thoughts). This is the same thing as a shared immutable namespace. But the next big need is an emergent lookup infrastructure from human-readable names to non-self-authenticating objects, which is the same thing as a shared mutable namespace. FreeWeb includes a central "DNS style" namespace, which is simply the Wrong Way to Do It. It is wrong because it is a top-down approach which starts by assuming that there is a globally acceptable party that everyone trusts. The Right Way to do it is a bottom-up approach in which each player gets to choose for themselves whom they will trust. There exist well-thought-out proposals for how to do such bottom-up shared mutable namespaces, including SDSI's linked local namespaces[7] and the E project's Pet Names Markup Language[8]. Hopefully the FreeWeb guy will consider implementing them instead of reinventing DNS. In fact, if you are willing to endure the problems of DNS-style namespaces as a bootstrapping step while deploying your emergent network, then you might as well just use DNS itself. For example, to see the latest version of my web page on Mojo Nation, install a Mojo Nation client and click on this link: http://zooko.com/MN/zooko_current_events.html Regards, Zooko [1] http://mojonation.net/ [2] http://cryptome.org/ [3] http://freeweb-hq.da.ru/ [4] http://freenet.sourceforge.net/ [5] http://zgp.org/pipermail/p2p-hackers/2001-April/000050.html [6] http://zgp.org/pipermail/p2p-hackers/2001-April/000051.html [7] http://citeseer.nj.nec.com/rivest96sdsi.html [8] http://www.erights.org/elib/capability/pnml.html From sam at neurogrid.com Sun Apr 22 21:04:01 2001 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] FreeWeb and mutable namespaces Message-ID: <3AE3A96A.1F1381DF@neurogrid.com> zooko@zooko.com wrote: > For example, to see the latest version of my web page > on Mojo Nation, install a Mojo Nation client and click on this link: > > http://zooko.com/MN/zooko_current_events.html Got this error trying to look at your page Error: Could not find part "style.css": (). CHEERS> SAM From blanu at uts.cc.utexas.edu Sun Apr 22 21:52:01 2001 From: blanu at uts.cc.utexas.edu (Brandon) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] FreeWeb and mutable namespaces In-Reply-To: Message-ID: > Now the first big need that we all have is for an emergent (i.e. decentralized, > attack-resistant, scalable) lookup infrastructure from globally unique (hence > non-human-friendly) keys to self-authenticating objects, which I think we're > about to really solve (see my messages on p2p-hackers: [5] and [6] for some of > my recent thoughts). This is the same thing as a shared immutable namespace. I feel like Freenet currently offers this via CHKs. > But the next big need is an emergent lookup infrastructure from human-readable > names to non-self-authenticating objects, which is the same thing as a shared > mutable namespace. I feel like Freenet also offers this via SSKs but lacks a good front-end for doing local naming. I have Freenet web sites bookmarked, for instance. So I know that when I click on Snarfoo I know I'm going the same site as before because I've bookmarked an SSK and SSKs are cool like that. But browser bookmarks are a rather sucky pet name manager. > FreeWeb includes a central "DNS style" namespace, which is simply the Wrong Way > to Do It. I think it's pretty good for a first attempt at a secure global namespace. It does assume that you want to look up sites using David's list. However, it already has some benefits over normal DNS. David can't take away your domain name The worst he can do is to refuse to give you a new one. All he needs to do is add a configuration field to his interface to let you specify which domain registrar you want to use and the problem will be solved. Ideally, he should also make his domain request processing software available so that everyone can be a registrar. It doesn't use any tricky protocols. It's all very open and simple. But I think he writes nice interfaces, so I'm sure his registrar software would be much nicer to use than my equivalent python script. An additional nice step would be to have the FreeWeb proxy periodically dump your browser's bookmark files to a Freenet domain listing. That way everyone is a domain registar automatically and all you need to do is to bookmark Freenet sites in your browser. Then, once all Freenet users are generating pet names and groups of preferred files, we can work in a ranking system with reputation and all that neat stuff. The most important thing is that we give the users a system which they can use now. Then we can incrementally improve it to be wonderful. I'm not renigging on my statement that the browser is a sucky pet name manager. The browser is a sucky manager for most things, but it's a good start for the web-addicted masses of the world. Someday hopefully we'll all move to something better. So basically I think this is mostly an interface issue. FreeWeb is currently a web-based interface to in-freenet lists of pet names and in its pre-release alpha state it assume that you want to use the author's list. I think that's just fine considering the very early state of the project and how easy it is to incrementally improve it. From zooko at zooko.com Mon Apr 23 08:46:01 2001 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] FreeWeb and mutable namespaces In-Reply-To: Message from Sam Joseph of "Mon, 23 Apr 2001 13:02:50 +0900." <3AE3A96A.1F1381DF@neurogrid.com> References: <3AE3A96A.1F1381DF@neurogrid.com> Message-ID: > zooko@zooko.com wrote: > > > For example, to see the latest version of my web page > > on Mojo Nation, install a Mojo Nation client and click on this link: > > > > http://zooko.com/MN/zooko_current_events.html > > Got this error trying to look at your page > > Error: Could not find part "style.css": (). > > CHEERS> SAM Well, that's what you get for having style-sheets turned on. It works on my machine! :-) I fixed this by moving the page to `http://zooko.com/MNref.html'. Thanks for the alert. By the way, "MNref.html" current just offers you a click-here link (although I also tested it with a client-side pull). The cool way to do it, which might be more compelling to people like David McNab (FreeWeb), would be a cgi script that does an HTTP 302 or 301. I'll set up a demo of that as soon as I get CGI perms from my web server operator. Regards, Zooko From burton at relativity.yi.org Mon Apr 23 15:22:02 2001 From: burton at relativity.yi.org (burtonator) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] Pumatech gets patent for hashing content to test for changes. Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ug. This sentence *really* scares me: "The latest patent validates Pumatech's position as the leader in Web-based change detection and notification, and further strengthens the Company's expanding portfolio of intellectual property - the largest of any change detection/notification or synchronization provider." ... what is this "intellectual property" they speak of :) http://biz.yahoo.com/bw/010423/0014.html SAN JOSE, Calif.--(BUSINESS WIRE)--April 23, 2001-- * Company's 14th Patent Pertains To Usage Of Checksum Comparisons To * Determine Whether Internet Documents Have Changed Fifth Mind-it Patent * Gives Pumatech More Change Detection/Notification-related Intellectual * Property Than Any Other Software Provider Pumatech, Inc. (Nasdaq:PUMA - news), the leading provider of software infrastructure for the mobile Internet, today announced it has received its fifth patent relating to its Mind-it(TM) Web-based change detection, end-user notification and personalization technology. The new patent (U.S. Patent No. 6,219,818) applies to the use of checksum comparisons to determine whether Internet documents have changed. The Company filed for the patent on February 18, 1999. The latest patent validates Pumatech's position as the leader in Web-based change detection and notification, and further strengthens the Company's expanding portfolio of intellectual property - the largest of any change detection/notification or synchronization provider. Pumatech holds a total of 14 patents, which protect a wide range of technologies relating to mobile and wireless Internet infrastructure. The new patent protects Mind-it's unique ability to store and compare checksums, instead of text, dramatically reducing storage and the amount of computation required to perform change detection. For example, users designate a particular part of a Web page that they would like to monitor for changes. Checksums are generated for each HTML-bound section of that Web page and for the user-defined selection of text, and are then archived. When there is change in the text, the new and archived checksums are compared, and the user is notified via email or mobile device if there is a change. The technology behind the checksum-comparison patent allows Mind-it to be scaled effortlessly to support millions of users and documents, while also improving performance by suppressing detection of trivial changes, greatly reducing the frequency of spurious notifications. ``Our Mind-it software has already redefined the mobile Internet communications model for many Fortune 500 companies,'' explained Pumatech President and CEO Brad Rowe. ``There has been a growing demand for mobile users to be able to track essential information and be notified when that information changes. The technology behind this latest patent is an essential component of Mind-it's ability to uniquely deliver the most effective Web-based change detection and notification solution to mobile customers who want to be in the know, on the go.'' In addition to its five Web-based change detection, end-user notification and personalization technology patents, Pumatech holds one patent relating to its file-transfer technology and owns the rights to eight patents relating to its synchronization technology. Pumatech also has 12 pending U.S. patents, as well as rights to enforce five patents owned by Intel Corporation, under a cross-license agreement between Pumatech and Intel. NEW PATENT BOLSTERS MAP The technology that supports Pumatech's industry-leading Mind-it software also powers the change detection, notification and personalization component of the Company's Mobile Application Platform (MAP), which is currently being licensed to carriers, ebusinesses, portals and enterprises such as CNET, Lycos and Boeing. MAP includes a variety of data access engines designed to enhance the utility of mobile devices, including a sync engine, a personalization and notification engine and a query engine. Pumatech's Intellisync.comSM service bureau, powered by the MAP architectural platform, enables consumers and business professionals to synchronize important information via the Internet, browse Web content both on and offline and be notified of changes to personalized Web information via email and mobile devices. ABOUT PUMATECH Pumatech, Inc. (Nasdaq:PUMA - news), formerly known as Puma Technology, Inc., is the leading provider of software infrastructure for the mobile world. The Company, which has long been the leader in synchronization with its Intellisync? technology, is in the process of rolling out recently acquired, leading-edge personalization, notification and Web-browsing services integrated with synchronization. Pumatech now offers a comprehensive application suite, the Mobile Application Platform (MAP), for the delivery of highly personalized content to any mobile device. It is the only integrated solution that fully supports all mobile devices and standards, including WAP phones, SMS-enabled phones, Palm OS? handhelds, Pocket PCs, Web sites, and desktop applications, such as Outlook. Companies using Pumatech(TM) products can create powerful mobile solutions that give customers and employees anytime, anywhere access to relevant information. Pumatech's mobile solutions are used by a wide range of leading companies, mobile device manufacturers, telecommunications carriers, software companies, and individuals. Headquartered in San Jose, CA, Pumatech offers more information on its products and services at www.pumatech.com. Forward-looking statements in this news release are made pursuant to the ``safe harbor'' provisions of the United States Private Securities Litigation Reform Act of 1995. Investors are cautioned that such forward-looking statements involve risks and uncertainties, including, without limitation, risks relating to possible product defects and product liability, risks related to international sales, risks related to the year 2000 issue, continued acceptance of Pumatech's products, increased levels of competition, technological changes, dependence on intellectual property rights and other risks detailed from time to time in Pumatech's periodic reports filed with the United States Securities and Exchange Commission and other regulatory authorities. Note to Editors: Pumatech, the Pumatech logo, and Intellisync are trademarks of Pumatech, Inc., that may be registered in some jurisdictions. Mind-it is a trademark of NetMind Technologies, Inc., a wholly-owned subsidiary of Pumatech, Inc. Intellisync.com is a servicemark of Pumatech, Inc. Palm OS is a registered trademark of Palm, Inc. All other product or company names are trademarks of their respective owners. - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 Faced with the choice between changing one's mind, and proving that there is no need to do so - almost everyone gets busy on the proof. -- John Kenneth Galbraith -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE65KjaAwM6xb2dfE0RAvC+AKCS8bCkxhGisP5PEPbZesjaT3q2NwCgqgde vuHZ0dY+2tIdbZHnEb7QHto= =B99X -----END PGP SIGNATURE----- From taral at taral.net Mon Apr 23 16:05:01 2001 From: taral at taral.net (Taral) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] Pumatech gets patent for hashing content to test for changes. In-Reply-To: ; from burton@relativity.yi.org on Mon, Apr 23, 2001 at 03:12:42PM -0700 References: Message-ID: <20010423180448.A26194@taral.net> On Mon, Apr 23, 2001 at 03:12:42PM -0700, burtonator wrote: > "The latest patent validates Pumatech's position as the leader in Web-based > change detection and notification, and further strengthens the Company's > expanding portfolio of intellectual property - the largest of any change > detection/notification or synchronization provider." Did you look at the patent? It's non-trivial and quite novel. Especially the HTML sectioning and select-what-you're-interested-in parts. -- Taral Please use PGP/GPG encryption to send me mail. "Any technology, no matter how primitive, is magic to those who don't understand it." -- Florence Ambrose -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20010423/d6b62261/attachment.pgp From burton at relativity.yi.org Tue Apr 24 16:35:02 2001 From: burton at relativity.yi.org (burtonator) Date: Sat Dec 9 22:11:41 2006 Subject: [p2p-hackers] Pumatech gets patent for hashing content to test for changes. In-Reply-To: Taral's message of "Mon, 23 Apr 2001 18:04:48 -0500" References: <20010423180448.A26194@taral.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taral writes: > On Mon, Apr 23, 2001 at 03:12:42PM -0700, burtonator wrote: > > "The latest patent validates Pumatech's position as the leader in Web-based > > change detection and notification, and further strengthens the Company's > > expanding portfolio of intellectual property - the largest of any change > > detection/notification or synchronization provider." > > Did you look at the patent? It's non-trivial and quite novel. Especially > the HTML sectioning and select-what-you're-interested-in parts. Here is the patent URL: http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=%276,219,818%27.WKU.&OS=PN/6,219,818&RS=PN/6,219,818 Most patents are non-trivial but they don't deserve a government monopoly for deserve 23 years :(. It is something any engineer can up within 20-30 minutes. :( I will have to check into this. I might have prior art. We were going to work on a similar system about 2-3 years ago but it was never deployed and I think it was whiteboard only so there is no technical documents to timestamp against :( Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 Never under estimate the power of a hacker! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE65fA8AwM6xb2dfE0RApYiAJ9nadC5bqvbz/0/jRipr/p5O64sKwCfcJVj XXvrlUMZk+7dyqT4ZgFN4ZA= =V3Rk -----END PGP SIGNATURE----- From gojomo at usa.net Tue Apr 24 17:49:01 2001 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:42 2006 Subject: [p2p-hackers] Pumatech gets patent for hashing content to test for changes. References: <20010423180448.A26194@taral.net> Message-ID: <016401c0cd22$6ac2b020$6401a8c0@bitcollider.com> > Here is the patent URL: > > http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=%276,219,818%27. WKU.&OS=PN/6,219,818&RS=PN/6,219,818 > > Most patents are non-trivial but they don't deserve a government monopoly for > deserve 23 years :(. > > It is something any engineer can up within 20-30 minutes. :( > > I will have to check into this. I might have prior art. We were going to work > on a similar system about 2-3 years ago but it was never deployed and I think it > was whiteboard only so there is no technical documents to timestamp against :( A product called "Tierra Highlights", which I remember seeing plugged at a conference somewhere ~1996, seemed to offer the same benefits and so probably was implemented in a similar way. See the December 1996 CNet review: http://coverage.cnet.com/Content/Reviews/Compare/Ultbrowser/tierra.html Unfortunately, the company that made the product appears to be gone, and an unrelated company has its domain name. Still, the original engineers and/or code must be around somewhere. I recall considering the use of a similar technique in mid-to-late 1998, as a way to make "static" web pages refresh on demand and/or partially without having the browser constantly reloading the entire page. (It involved an intermediate proxy, "near" the source-server, which left the connection to the client hanging open, while the proxy polled the web page. When it noticed a difference in a subsection of the source page, via remembered checksums, it would push out javascript to the client which effected the required delta, using DHTML replacing. I never built it, and doubt I could find notes from that time describing the idea in even this much details, though I did write some servlets to confirm that the hanging-open dynamic-updating approach could work.) This patent should be easy to bust. - Gojomo ______________________________ Gordon Mohr - gojomo@bitzi.com CTO, Bitzi - http://bitzi.com Personal - http://xavvy.com From gojomo at usa.net Tue Apr 24 18:24:01 2001 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:42 2006 Subject: [p2p-hackers] Pumatech gets patent for hashing content to test for changes. References: <20010423180448.A26194@taral.net> <016401c0cd22$6ac2b020$6401a8c0@bitcollider.com> Message-ID: <017001c0cd26$65f6d360$6401a8c0@bitcollider.com> Also: a very similar technique was proposed for use in XML signaturing and change-synchronization, by IBM to the IETF, in February 1999 -- suggesting yet another group working on the same idea before the patent was filed. It should be easy to prove Pumatech's idea is neither novel nor nonobvious. See: http://sunsite.ics.forth.gr/sunsite/pub/internet-drafts/draft-hiroshi-dom-hash-01.txt - Gojomo ______________________________ Gordon Mohr - gojomo@bitzi.com CTO, Bitzi - http://bitzi.com Personal - http://xavvy.com From burton at relativity.yi.org Wed Apr 25 04:13:01 2001 From: burton at relativity.yi.org (burtonator) Date: Sat Dec 9 22:11:42 2006 Subject: [p2p-hackers] Pumatech gets patent for hashing content to test for changes. In-Reply-To: "Gordon Mohr"'s message of "Tue, 24 Apr 2001 17:54:08 -0700" References: <20010423180448.A26194@taral.net> <016401c0cd22$6ac2b020$6401a8c0@bitcollider.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Gordon Mohr" writes: > See the December 1996 CNet review: > > http://coverage.cnet.com/Content/Reviews/Compare/Ultbrowser/tierra.html > > Unfortunately, the company that made the product appears to be gone, > and an unrelated company has its domain name. Still, the original > engineers and/or code must be around somewhere. I am sure some mild research could turn up some Engineers that could help. Seems like a patent worth fighting. > I recall considering the use of a similar technique in mid-to-late > 1998, as a way to make "static" web pages refresh on demand and/or > partially without having the browser constantly reloading the entire > page. (It involved an intermediate proxy, "near" the source-server, > which left the connection to the client hanging open, while the > proxy polled the web page. When it noticed a difference in a > subsection of the source page, via remembered checksums, it would > push out javascript to the client which effected the required delta, > using DHTML replacing. I never built it, and doubt I could find > notes from that time describing the idea in even this much details, > though I did write some servlets to confirm that the hanging-open > dynamic-updating approach could work.) ... The major issue it seems are the work arounds you have to do to deal with trivial content changes. IE if you have a "date" within the webpage it could change (as well as the advertisements) but the rest of the content would stay the same. This is what the patent adds and why I think it was awarded. Someone would have to find a similar technology that did the same thing. Mozilla has a feature where you can tell if a URL has changed. It was around in the old 4.x series but I don't know when the put it in. IE had the same functionality. That might be an interesting pursuit. Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 Iron rusts from disuse, stagnant water loses its purity, and in cold weather becomes frozen: even so does inaction sap the vigors of the mind. -- Leonardo da Vinci -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE65qz8AwM6xb2dfE0RAt1BAJ4zm+t7PPLphnN572fSDeuVDdniLwCgjbAl E0XZbNiviwhI8EObzA6tZJw= =1xX2 -----END PGP SIGNATURE-----