これは 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 ミラーの数とセンチネルの数を変えることで必要なだけ堅牢にできる。