In terms of scaling the blockchain, Namecoin has similar scalability characteristics as Bitcoin. Being designed to store information, however, brings in some additional considerations but the outcome does not differ significantly than that of Bitcoin.
There are a variety of mechanisms to compress a blockchain. Libcoin has a basic UTXO mode that (when combined with file-space compression) reduced the overall size of the Namecoin blockchain from over two gigs to ~250MB. There has been discussion of a hybrid, namespace-specific UTXO mode that would only store unspent transactions of an optimized subset of domains.
SPV depends on a smaller trusted seed of information and uses probabilistic validation. This can be used by a client until their full UTXO set has been built up. Clients software does not need to store the entirety of the blockchain locally, nullifying theoretical objections regarding blockchain size.
A client only requires an insignificant amount of data locally to validate a transaction and thus any record in any of the Namecoin namespaces. The data stored in a record can be summed to the hash of that record, such that a client or a full-node for any one namespace does not need to carry the full records of all of the namespaces.
TL;DR Browsing .bit websites does not require storing records in id/.
The size of the .bit namespace can be gauged by referencing 2nd tier general TLDs such as .info and .biz, the top generic TLDs outside of .com, .net, and .org. .info has some ~5.7 million domains <ref>https://www.VerisignInc.com/DNIB</ref> and .biz has ~2.7 million domains <ref>http://www.domaintools.com/statistics/tld-counts/</ref>.
Traffic to domains is distributed in a Zipf-like fashion, with 20% of the domains receiving some 80% of all traffic. For the purposes of a web client, this means that the initial download only needs to contain 20% of all domains to eliminate DNS lookups for 80% of the users traffic. The remaining 20% of traffic will be retrieved once and then cached locally.
To store the top 20% of domains in the .biz namespace, one would need to store .5 million domains:
0.2 * 2.5 = .5. A CSV file containing 142,000 IP <-> domain pairs (culled from Alexa's top domains list as well as multiple blacklists for variety) results in a 4 megabyte file. Simple Zip compression yields 2:1 - 3:1 compression ratios while PAQ8 (a very slow but very efficient compression algorithm) delivers rates greater than 4:1. A custom data-structure would likely yield even higher compression ratios. Simple extrapolation of these numbers (142,000 per 1 megabyte) indicate that 5 megabytes can handle ~700,000 simple domain name <-> IP pairings. While these numbers are a very loose estimates, they would need to be off by over two orders of magnitude (x100) before scalability would become a concern.
TL;DR Even the lowliest of client-side web storage mechanisms, the web-browser localStorage API, guarantees a minimum of 5 megabytes of storage per website. Even in this worst-case scenario, .bit could scale to the size of .biz tomorrow without breaking a sweat.
ID does not store entire encryption keys, only hashes (or fingerprints) of such keys. A client can validate a website or PGP public key by hashing it or by using the hash listed in the blockchain to look up the full key on another database, such as the MIT PGP key server.
Proof-of-existence records only need to store hashes of the actual data. The registration of a 16-bytes key and 64-bytes value pair, for instance, increases the blockchain size by 568 bytes approx. (name_new: 256 bytes, name_firstupdate: 228+16+64 bytes), and updating it every <36000 blocks occupies some 308 bytes. Equally conceivable is an application that does not require updating names. As long as we don't introduce any blockchain purge expired names are still in the blockchain and can be used as a proof.
- Thread outlining UXTO, the data structure with the maximum theoretical compression of the blockchain.
- Introduction to UXTO on blog tracking the development of the UXTO proposal.