これはP2Pにおいてよく知られた問題で、Original Introductionと呼ばれている。ブートストラッピングも良い用語だ。ブートストラッピングの問題点は、分散化できないことにある。IRCであれHTTPであれDNSであれ、クライアントにはアドレスまたはアドレスリストがハードコードされている必要があり、リストされたアドレスの少なくとも1つがまだ有効であるほど十分に新鮮でなければならない。最初のノードに到達した後は、もはやOriginal Introductionモードではなくなり、ゴシップなどの分散化のための全技術を使用できる。もちろん、ネットワークから切断され、既知のピアがすべていなくなった場合は、ブートストラッピングに戻ることになる。
ブートストラッピング方式を選ぶ際に相反する2つの特性がある：堅牢性（スケーラビリティ/信頼性）と鮮度だ。堅牢性は、HTTPピアリストで一般的に行われるように、複数のサーバーにキャッシュすることで鮮度を犠牲にして向上する。鮮度は、IRCのように全員が接続した状態にすることで堅牢性を犠牲にして最大化される（少なくともTCPタイムアウトまでは）。もちろん、ブートストラップが成功するためには両方が必要なので、堅牢性と鮮度の適切なバランスを見つけることが鍵だ。
現在気に入っているブートストラッピング方法をいくつか挙げる：
ダウンロード時に実行ファイルまたはインストーラーに最新のピアリストを動的に追加する方法。通常、ユーザーはアプリケーションを公式ウェブサイトから入手するので、ウェブサイトはすでに新規ユーザーにとっての障害点だ。アプリケーションにはすでにブートストラップに使用するアドレスがハードコードされている。だから、ダウンロード時に最新のピアを追加すればいい。実行ファイルの末尾からリストを読み取るための凝ったコードが必要だが、NSISインストーラーでこれを実装したことがあり、それほど難しくはない。ほとんどのソフトウェア開発者はこの方法に抵抗を感じるが。
XMPPを介してGoogle App Engineアプリケーションに接続する方法。これはIRCの鮮度を持ちつつ、よりスケーラブルな堅牢性がある。App Engineは主にウェブアプリ向けだが、メールとXMPPの処理も提供している。XMPPまたはHTTPのいずれかで同じハンドラーコードを使ってピアリストを扱える単一のアプリケーションを書くのは簡単だ。現在あるアプリケーションでこれを使っており、うまく動作し非常に信頼性が高い。フォールバック用に第2のApp Engineがあればいいのだが、たまにダウンタイムがあるので。
IRCやXMPPのようなプロトコルの複雑さをすべてのノードに要求する代わりに、ネットワーク上にいくつかの特別なセンチネルノードを置く方法がある。これらはアクティブなノードが利用できる通常の分散手法を使って、接続されたノードのアドレスを収集する。センチネルノードは定期的に最新のアドレスをアップロードする。たとえばHTTP POSTで複数のウェブサイトに。新しいノードは、現在機能しておりアクセス可能なウェブサイトのいずれかから最新のアドレスリストをダウンロードできる。5つのセンチネルがそれぞれ5分ごとにアップロードすれば（ずらして）、約1分ごとに更新される。これは鮮度の点でIRCと同等であり、HTTPミラーの数とセンチネルの数を変えることで必要なだけ堅牢にできる。