The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.
検閲に強いグローバルな「ソーシャル」ネットワークを一挙に構築することができる最もシンプルなオープンプロトコルです。
It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works.
信頼できる中央サーバーに依存しないので弾力性があり、暗号鍵と署名に基づくので改ざん防止になり、P2P技術に依存しないので機能するのです。
This is a work-in-progress. Join the Telegram group!
これは作業中のものです。テレグラムグループに参加しよう！
Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.
誰もがクライアントを実行しています。それはネイティブクライアントであったり、ウェブクライアントであったり、様々です。何かを公開するには、記事を書き、自分の鍵で署名して、複数のリレー（他の誰かや自分がホストしているサーバー）に送ります。他の人からの更新情報を得るには、複数のリレーに、その他の人について何か知っているかどうかを尋ねます。リレーは誰でも実行できる。リレーはとてもシンプルで間抜けなものです。ある人からの投稿を受け入れ、他の人に転送する以外には何もしません。リレーは信頼される必要はありません。署名はクライアント側で検証されます。
Nostr client feature comparison
List of projects built on Nostr
-
Twitter has ads;
-
Twitter uses bizarre techniques to keep you addicted;
-
Twitter doesn't show an actual historical feed from people you follow;
-
Twitter bans people;
-
Twitter shadowbans people.
-
Twitter has a lot of spam.
-
Twitterには広告がある。
-
Twitterは、あなたを中毒にさせるために奇妙なテクニックを使っています。
-
Twitterは、あなたがフォローしている人々の実際の履歴フィードを表示しません。
-
Twitterは人々を禁止しています。
-
Twitterのシャドーバン（影武者）。
-
Twitterはスパムが多い。
-
User identities are attached to domain names controlled by third-parties;
-
Server owners can ban you, just like Twitter; Server owners can also block other servers;
-
Migration between servers is an afterthought and can only be accomplished if servers cooperate. It doesn't work in an adversarial environment (all followers are lost);
-
There are no clear incentives to run servers, therefore they tend to be run by enthusiasts and people who want to have their name attached to a cool domain. Then, users are subject to the despotism of a single person, which is often worse than that of a big company like Twitter, and they can't migrate out;
-
Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody;
-
It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. This point is exacerbated by the fact that servers tend to exist in huge numbers, therefore more data has to be passed to more places more often;
-
For the specific example of video sharing, ActivityPub enthusiasts realized it would be completely impossible to transmit video from server to server the way text notes are, so they decided to keep the video hosted only from the single instance where it was posted to, which is similar to the Nostr approach.
-
ユーザーIDは、第三者が管理するドメイン名と紐付けられています。
-
サーバーの所有者は、Twitterのようにあなたを禁止することができる。サーバーの所有者は、他のサーバーをブロックすることもできる。
-
サーバー間の移行は後回しで、サーバーが協力的でなければ実現できない。敵対的な環境ではうまくいかない（すべてのフォロワーが失われる）。
-
サーバーを運営する明確なインセンティブがないため、熱狂的なファンや、かっこいいドメインに自分の名前を付けたい人がサーバーを運営する傾向がある。そして、ユーザーは、Twitterのような大企業よりもひどい一人の人間の専横にさらされることが多く、また、移行することができない。
-
サーバーは素人が運営することが多いので、しばらくすると放棄されることが多い。これは事実上、全員を追放しているのと同じことだ。
-
もし、すべてのサーバーからのアップデートを、他のサーバーに苦労してプッシュ（そして保存！）しなければならないのであれば、サーバーを大量に持つ意味はないでしょう。この点は、サーバーが膨大な数で存在する傾向があるため、より多くのデータをより多くの場所に、より頻繁に渡さなければならないという事実によって、さらに悪化しています。
-
動画共有の具体例として、ActivityPubの熱狂的なファンは、テキストメモのようにサーバーからサーバーへ動画を転送することは完全に不可能であることを理解し、Nostrのアプローチと同様に、動画が投稿された単一のインスタンスからのみホストすることにした。
-
It doesn't have many problems. I think it's great. In fact, I was going to use it as a basis for this, but
-
its protocol is too complicated because it wasn't thought about being an open protocol at all. It was just written in JavaScript in probably a quick way to solve a specific problem and grew from that, therefore it has weird and unnecessary quirks like signing a JSON string which must strictly follow the rules of ECMA-262 6th Edition;
-
It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason);
-
It is not as simple as Nostr, as it was primarily made for P2P syncing, with "pubs" being an afterthought;
-
Still, it may be worth considering using SSB instead of this custom protocol and just adapting it to the client-relay server model, because reusing a standard is always better than trying to get people in a new one.
-
あまり問題がない。素晴らしいことだと思います。実は、これをベースにしようと思っていたのですが、オープンなプロトコルを全く考えていなかったので、プロトコルが複雑すぎるのです。
-
オープンなプロトコルであることをまったく考えていなかったので、プロトコルが複雑すぎるんです。そのため、ECMA-262 6th Editionの規則に厳密に従わなければならないJSON文字列に署名するなど、奇妙で不要な癖があります。
-
一人のユーザーから更新の連鎖を持つことにこだわっていますが、私には不必要に感じられ、このことに肥大化と硬直化を加えています - 各サーバー/ユーザーは、新しいものが有効であることを確認するためにすべての投稿の連鎖を保存する必要があります。なぜかというと、（多分、それなりの理由があるのでしょうが）。
-
Nostrは主にP2P同期用に作られたもので、"pub "は後付けなので、Nostrほどシンプルではありません。
-
それでも、このカスタムプロトコルの代わりにSSBを使い、クライアント-リレーサーバーモデルに適応させることだけを考える価値はあるかもしれません。なぜなら、標準を再利用することは、新しいものに人を集めようとするより常に良いことだからです。
-
They require everybody to run their own server;
-
Sometimes people can still be censored in these because domain names can be censored.
-
そのため、誰もが自分自身のサーバーを運営する必要があります。
-
ドメイン名が検閲されることがあるため、このような場合でも人々は検閲されることがあるのです。
-
There are two components: clients and relays. Each user runs a client. Anyone can run a relay.
-
Every user is identified by a public key. Every post is signed. Every client validates these signatures.
-
Clients fetch data from relays of their choice and publish data to other relays of their choice. A relay doesn't talk to another relay, only directly to users.
-
For example, to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key.
-
On startup, a client queries data from all relays it knows for all users it follows (for example, all updates from the last day), then displays that data to the user chronologically.
-
A "post" can contain any kind of structured data, but the most used ones are going to find their way into the standard so all clients and relays can handle them seamlessly.
-
2つのコンポーネントがあります。クライアント__と__リレー__です。各ユーザーはクライアントを実行します。リレーは誰でも実行することができます。
-
すべてのユーザは公開鍵で識別されます。すべての投稿は署名されています。すべてのクライアントはこれらの署名を検証する。
-
クライアントは自分の選んだリレーからデータを取得し、自分の選んだ他のリレーにデータを公開する。リレーは他のリレーと会話することはなく、ユーザーと直接会話するのみである。
-
例えば、ある人を「フォロー」する場合、ユーザーは自分のクライアントに、その公開鍵からの投稿を知るリレーに問い合わせるよう指示するだけでよい。
-
クライアントは起動時に、自分がフォローしているすべてのユーザーについて知っているすべてのリレーからデータを照会し（たとえば、直近のすべての更新）、そのデータを時系列でユーザーに表示する。
-
post "にはあらゆる種類の構造化データを含めることができますが、最もよく使われるものは、すべてのクライアントとリレーがシームレスに扱えるように、標準に取り込まれる予定です。
-
Users getting banned and servers being closed
-
A relay can block a user from publishing anything there, but that has no effect on them as they can still publish to other relays. Since users are identified by a public key, they don't lose their identities and their follower base when they get banned.
-
Instead of requiring users to manually type new relay addresses (although this should also be supported), whenever someone you're following posts a server recommendation, the client should automatically add that to the list of relays it will query.
-
If someone is using a relay to publish their data but wants to migrate to another one, they can publish a server recommendation to that previous relay and go;
-
If someone gets banned from many relays such that they can't get their server recommendations broadcasted, they may still let some close friends know through other means with which relay they are publishing now. Then, these close friends can publish server recommendations to that new server, and slowly, the old follower base of the banned user will begin finding their posts again from the new relay.
-
All of the above is valid too for when a relay ceases its operations.
-
リレーは、ユーザーがそこで何かを公開するのをブロックすることができますが、他のリレーに公開することができるため、ユーザーには何の影響も与えません。ユーザーは公開鍵で識別されるので、BANされてもアイデンティティとフォロワーベースを失うことはありません。
-
新しいリレーアドレスを手動で入力する代わりに（これもサポートされるべきですが）、あなたがフォローしている誰かがサーバーの推薦を投稿するたびに、クライアントは自動的にリレーを照会するリストに追加する必要があります。
-
もし誰かが自分のデータを公開するためにリレーを使用しているが、他のリレーに移行したい場合、その人は以前のリレーにサーバー推薦を公開して行くことができます。
-
もし誰かが多くのリレーから追放され、自分のサーバー推薦を放送できなくなったとしても、親しい友人たちに他の手段で、今どのリレーでサーバー推薦を公表しているかを知らせることができます。そうすれば、その親しい友人たちは、その新しいサーバーにサーバー推薦を流すことができ、徐々に、追放されたユーザーの古いフォロワーベースは、新しいリレーから再び彼らの投稿を見つけ始めるでしょう。
-
以上のことは、リレーが運営を停止した場合にも有効です。
-
-
Censorship-resistance
-
Each user can publish their updates to any number of relays.
-
A relay can charge a fee (the negotiation of that fee is outside of the protocol for now) from users to publish there, which ensures censorship-resistance (there will always be some Russian server willing to take your money in exchange for serving your posts).
-
各ユーザは、任意の数のリレーに自分のアップデートを公開することができます。
-
リレーは、そこで公開するためにユーザーから料金（料金の交渉は今のところプロトコルの外）を請求することができ、検閲への耐性を保証します（あなたの投稿を提供する代わりに、お金を取ろうとするロシアのサーバーが常に存在することになります）。
-
-
Spam
-
If spam is a concern for a relay, it can require payment for publication or some other form of authentication, such as an email address or phone, and associate these internally with a pubkey that then gets to publish to that relay — or other anti-spam techniques, like hashcash or captchas. If a relay is being used as a spam vector, it can easily be unlisted by clients, which can continue to fetch updates from other relays.
-
もしリレーがスパムを懸念しているのであれば、公開のための支払いや、メールアドレスや電話番号などの認証を要求し、それらを内部的にパブキーと関連付け、そのリレーに公開するようにすることができます。リレーがスパムベクターとして使用されている場合、クライアントによって簡単にアンリスト化することができ、他のリレーからアップデートを取得し続けることができます。
-
-
Data storage
-
For the network to stay healthy, there is no need for hundreds of active relays. In fact, it can work just fine with just a handful, given the fact that new relays can be created and spread through the network easily in case the existing relays start misbehaving. Therefore, the amount of data storage required, in general, is relatively less than Mastodon or similar software.
-
Or considering a different outcome: one in which there exist hundreds of niche relays run by amateurs, each relaying updates from a small group of users. The architecture scales just as well: data is sent from users to a single server, and from that server directly to the users who will consume that. It doesn't have to be stored by anyone else. In this situation, it is not a big burden for any single server to process updates from others, and having amateur servers is not a problem.
-
ネットワークが健全であるためには、何百ものアクティブなリレーが必要なわけではありません。むしろ、既存のリレーが誤動作を始めた場合に備えて、新しいリレーを作成してネットワークに簡単に拡散できることを考えると、ほんの一握りでも十分に機能する。そのため、一般的に必要なデータ保存量は、Mastodonなどに比べて比較的少なくて済みます。
-
また、別の結果を考えてみましょう。アマチュアが運営する何百ものニッチリレーが存在し、それぞれが小さなユーザーグループからの更新を中継しているような場合です。このアーキテクチャは、ユーザーから1つのサーバーにデータが送られ、そのサーバーから、それを消費するユーザーに直接送られる、というようにスケールします。他の誰かが保存する必要はないのです。この場合、1つのサーバーが他のサーバーからの更新を処理することは大きな負担にはならず、アマチュアのサーバーがあっても問題ありません。
-
-
Video and other heavy content
-
It's easy for a relay to reject large content, or to charge for accepting and hosting large content. When information and incentives are clear, it's easy for the market forces to solve the problem.
-
中継局が大容量コンテンツを拒否したり、大容量コンテンツの受け入れやホスティングに課金したりするのは簡単です。情報とインセンティブが明確であれば、市場原理で簡単に解決できる。
-
-
Techniques to trick the user
-
Each client can decide how to best show posts to users, so there is always the option of just consuming what you want in the manner you want — from using an AI to decide the order of the updates you'll see to just reading them in chronological order.
-
各クライアントがユーザーに最適な投稿を表示する方法を決められるので、AIを使って見る順番を決めたり、時系列で読んだりと、自分の好きな方法で好きなものだけを消費する選択肢も常にあるのです。
-
-
This is very simple. Why hasn't anyone done it before?
I don't know, but I imagine it has to do with the fact that people making social networks are either companies wanting to make money or P2P activists who want to make a thing completely without servers. They both fail to see the specific mix of both worlds that Nostr uses.
よくわかりませんが、ソーシャルネットワークを作っている人たちは、お金を稼ぎたい企業か、完全にサーバーのないものを作りたいP2P活動家のどちらかだという事実と関係があるのではないかと想像しています。彼らはどちらも、Nostrが使っている両方の世界の具体的なミックスに気づいていないのです。
-
How do I find people to follow?
First, you must know them and get their public key somehow, either by asking or by seeing it referenced somewhere. Once you're inside a Nostr social network you'll be able to see them interacting with other people and then you can also start following and interacting with these others.
まず、相手のことを知り、尋ねるか、どこかで参照して、相手の公開鍵を入手する必要があります。Nostrのソーシャルネットワークに入ると、彼らが他の人と交流しているのを見ることができ、あなたもその人をフォローして交流することができます。
-
How do I find relays? What happens if I'm not connected to the same relays someone else is?
You won't be able to communicate with that person. But there are hints on events that can be used so that your client software (or you, manually) knows how to connect to the other person's relay and interact with them. There are other ideas on how to solve this too in the future but we can't ever promise perfect reachability, no protocol can.
その相手と通信することはできません。しかし、クライアントソフトウェア（またはあなた、手動）が相手のリレーに接続し、対話する方法を知るために使用できるイベントのヒントがあります。将来的には、この問題を解決するための他のアイデアもありますが、完璧な到達可能性を約束することはできませんし、どんなプロトコルにもできません。
-
Can I know how many people are following me?
No, but you can get some estimates if relays cooperate in an extra-protocol way.
いいえ、しかし、リレーがエクストラプロトコル方式で協力すれば、ある程度の推定が可能です。
-
What incentive is there for people to run relays?
The question is misleading. It assumes that relays are free dumb pipes that exist such that people can move data around through them. In this case yes, the incentives would not exist. This in fact could be said of DHT nodes in all other p2p network stacks: what incentive is there for people to run DHT nodes?
この質問は誤解を招きます。リレーとは、人々がデータを移動させることができるように存在する無料のダムパイプであると仮定しているのです。この場合、インセンティブは存在しないでしょう。実際、これは他のすべてのP2PネットワークスタックのDHTノードにも言えることです。人々がDHTノードを実行するインセンティブがあるでしょうか?
-
Nostr enables you to move between server relays or use multiple relays but if these relays are just on AWS or Azure what’s the difference?
There are literally thousands of VPS providers scattered all around the globe today, there is not only AWS or Azure. AWS or Azure are exactly the providers used by single centralized service providers that need a lot of scale, and even then not just these two. For smaller relay servers any VPS will do the job very well.
VPSプロバイダーは文字通り何千とあり、AWSやAzureだけでなく、世界中に点在しています。AWSやAzureは、まさに大規模なスケールを必要とする単一の集中型サービスプロバイダーが使用するプロバイダーであり、この2つだけではありません。小規模な中継サーバーであれば、どのようなVPSでも十分な機能を発揮します。
See the NIPs and especially NIP-01 for a reasonably-detailed explanation of the protocol spec (hint: it is very short and simple).
There is a list of most software being built using Nostr on https://github.com/aljazceru/awesome-nostr that seemed to be almost complete last time I looked.
Public domain.