From 96033a53db24133666061eddafc3f63c12cf1c95 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 11:36:08 +0800 Subject: [PATCH 01/77] Create README.md --- .../\344\270\255\346\226\207/README.md" | 124 ++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 "translate/\344\270\255\346\226\207/README.md" diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" new file mode 100644 index 0000000..eb6ac59 --- /dev/null +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -0,0 +1,124 @@ +# nostr - Notes and Other Stuff Transmitted by Relays + +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, and therefore it works. + +This is a work in progress. [Join the Telegram group!](https://t.me/nostr_protocol) + +## Very short summary of how it works, if you don't plan to read anything else: + +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. + +[How to start using Nostr](https://github.com/vishalxl/nostr_console/discussions/31) + +[Nostr client feature comparison](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[List of projects built on Nostr](https://github.com/aljazceru/awesome-nostr) + +## This is needed because other solutions are broken: + +### The problem with Twitter + +- 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. + +### The problem with Mastodon and similar programs + +- 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. + +### The problem with SSB (Secure Scuttlebutt) + +- It doesn't have many problems. I think it's great. 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_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); +- 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. + +### The problem with other solutions that require everybody to run their own server + +- They require everybody to run their own server; +- Sometimes people can still be censored in these because domain names can be censored. + +## How does Nostr work? + +- 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. + +## How does it solve the problems the networks above can't? + +- **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. + +- **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. + +- **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. + +## FAQ + +- **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. + +- **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. + +- **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? + +- **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. + +## Protocol specification + +See the [NIPs](https://github.com/nostr-protocol/nips) and especially [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) for a reasonably-detailed explanation of the protocol spec (hint: it is very short and simple). + +## Software + +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. + +## License + +Public domain. From a46fd66e21375ac2815f6c442150ea727add7b1d Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 11:37:45 +0800 Subject: [PATCH 02/77] Create README.md --- translate/README.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 translate/README.md diff --git a/translate/README.md b/translate/README.md new file mode 100644 index 0000000..abb5e2e --- /dev/null +++ b/translate/README.md @@ -0,0 +1 @@ +Translate content into other languages From 4c2a2c7aa3ca0b78a23fa654e00269c6ed8fd58a Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 11:38:21 +0800 Subject: [PATCH 03/77] Create README.md --- "translate/\346\227\245\346\234\254\350\252\236/README.md" | 1 + 1 file changed, 1 insertion(+) create mode 100644 "translate/\346\227\245\346\234\254\350\252\236/README.md" diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" new file mode 100644 index 0000000..8b13789 --- /dev/null +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -0,0 +1 @@ + From e79a5be253ec05569778c6c2a4b135ac293a7698 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 11:38:43 +0800 Subject: [PATCH 04/77] Update README.md --- .../README.md" | 123 ++++++++++++++++++ 1 file changed, 123 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index 8b13789..eb6ac59 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -1 +1,124 @@ +# nostr - Notes and Other Stuff Transmitted by Relays +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, and therefore it works. + +This is a work in progress. [Join the Telegram group!](https://t.me/nostr_protocol) + +## Very short summary of how it works, if you don't plan to read anything else: + +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. + +[How to start using Nostr](https://github.com/vishalxl/nostr_console/discussions/31) + +[Nostr client feature comparison](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[List of projects built on Nostr](https://github.com/aljazceru/awesome-nostr) + +## This is needed because other solutions are broken: + +### The problem with Twitter + +- 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. + +### The problem with Mastodon and similar programs + +- 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. + +### The problem with SSB (Secure Scuttlebutt) + +- It doesn't have many problems. I think it's great. 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_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); +- 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. + +### The problem with other solutions that require everybody to run their own server + +- They require everybody to run their own server; +- Sometimes people can still be censored in these because domain names can be censored. + +## How does Nostr work? + +- 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. + +## How does it solve the problems the networks above can't? + +- **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. + +- **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. + +- **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. + +## FAQ + +- **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. + +- **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. + +- **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? + +- **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. + +## Protocol specification + +See the [NIPs](https://github.com/nostr-protocol/nips) and especially [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) for a reasonably-detailed explanation of the protocol spec (hint: it is very short and simple). + +## Software + +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. + +## License + +Public domain. From f3376bb266fd7353e88497f6697dc0961511a54d Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 11:46:16 +0800 Subject: [PATCH 05/77] Update README.md --- "translate/\344\270\255\346\226\207/README.md" | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index eb6ac59..c716f5a 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -1,8 +1,10 @@ -# nostr - Notes and Other Stuff Transmitted by Relays +# nostr - 透過中繼傳輸的筆記及其他內容 +> Notes and Other Stuff Transmitted by Relays -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, and therefore it works. +能夠一勞永逸創建一個抗審查的全球「社交」網絡，最單純的開放協議。 + +它不依賴於任何受信任的中央服務器，因此具有彈性；它基於加密密鑰和簽名，因此是防篡改的；它不依賴於 P2P 技術，因此可以正常工作。 This is a work in progress. [Join the Telegram group!](https://t.me/nostr_protocol) From 5e8c5ecad7edd6cb79af9161e01c93b22ccf72f6 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 11:46:59 +0800 Subject: [PATCH 06/77] Update README.md --- "translate/\344\270\255\346\226\207/README.md" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index c716f5a..b8bf503 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -6,7 +6,7 @@ 它不依賴於任何受信任的中央服務器，因此具有彈性；它基於加密密鑰和簽名，因此是防篡改的；它不依賴於 P2P 技術，因此可以正常工作。 -This is a work in progress. [Join the Telegram group!](https://t.me/nostr_protocol) +這是一個正在進行的作業。 [加入 Telegram 群組！](https://t.me/nostr_protocol) ## Very short summary of how it works, if you don't plan to read anything else: From c5d76d7b1444df0bbf6ad721f9c4e31c53248a0f Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 11:51:35 +0800 Subject: [PATCH 07/77] Update README.md --- "translate/\344\270\255\346\226\207/README.md" | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index b8bf503..3ad293e 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -1,12 +1,11 @@ -# nostr - 透過中繼傳輸的筆記及其他內容 +# nostr - 透過中繼傳輸的筆記和其他資訊 > Notes and Other Stuff Transmitted by Relays +最簡單的開放協議，能夠一次性創建一個抵抗審查的全球「社交」網絡。 -能夠一勞永逸創建一個抗審查的全球「社交」網絡，最單純的開放協議。 +它不依賴任何值得信賴的中央服務器，因此它具有韌性；它基於密碼學密鑰和簽名，因此它是防篡改的；它不依賴P2P技術，因此它能夠運作。 -它不依賴於任何受信任的中央服務器，因此具有彈性；它基於加密密鑰和簽名，因此是防篡改的；它不依賴於 P2P 技術，因此可以正常工作。 - -這是一個正在進行的作業。 [加入 Telegram 群組！](https://t.me/nostr_protocol) +這是一個正在進行中的工作，[歡迎加入 Telegram 群組！](https://t.me/nostr_protocol) ## Very short summary of how it works, if you don't plan to read anything else: From 0b3b2baf16a431ddad3198c509d678f5c1c826fd Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 12:22:48 +0800 Subject: [PATCH 08/77] Update README.md --- .../\344\270\255\346\226\207/README.md" | 64 +++++++++---------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 3ad293e..2351db7 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -7,53 +7,53 @@ 這是一個正在進行中的工作，[歡迎加入 Telegram 群組！](https://t.me/nostr_protocol) -## Very short summary of how it works, if you don't plan to read anything else: +## 如果你不打算閱讀其他內容，以下是它運作的簡短摘要： -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. +每個人都運行客戶端。它可以是原生客戶端、Web 客戶端等。要發布內容，您需要撰寫一篇文章，用您的金鑰對其進行簽名，然後將其發送到多個轉接器（由他人或您自己託管的服務器）。要獲取其他人的更新，您可以向多個轉接器請求是否有關於這些其他人的任何信息。任何人都可以運行轉接器。轉接器非常簡單和愚笨。它除了接受某些人的文章並轉發給其他人之外什麼也不做。轉接器不需要受信任。簽名在客戶端上驗證。 -[How to start using Nostr](https://github.com/vishalxl/nostr_console/discussions/31) +[如何開始使用 Nostr](https://github.com/vishalxl/nostr_console/discussions/31) -[Nostr client feature comparison](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) +[Nostr 客戶端功能比較](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) -[List of projects built on Nostr](https://github.com/aljazceru/awesome-nostr) +[基於 Nostr 的項目列表](https://github.com/aljazceru/awesome-nostr) -## This is needed because other solutions are broken: +## 需要這是因為其他解決方案出現問題： -### The problem with Twitter +### Twitter 的問題 -- 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 有很多垃圾郵件。 -### The problem with Mastodon and similar programs +### Mastodon 和類似程序的問題 -- 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. +- 使用者身份附加在由第三方控制的域名上； +- 服務器擁有者可以像 Twitter 一樣禁止您；服務器擁有者還可以阻止其他服務器； +- 在對抗環境中，遷移之間是一個後顧之憂，只有服務器合作才能實現。在失敗的情況下，所有追蹤者都會丟失； +- 沒有明確的激勵措施來運行服務器，因此它們往往由熱心愛好者和想要將自己的名字與一個很酷的域名相關聯的人來運行。然後，用戶受到單個人的專制統治，這通常比 Twitter 等大公司更糟糕，他們無法遷移出去； +- 由於服務器往往是業餘人士運行，所以它們經常在一段時間後被廢棄——這與禁止每個人的效果相同； +- 如果每個服務器的更新必須痛苦地推送（和保存！）到許多其他服務器，那麼擁有大量服務器是毫無意義的。這一點由於服務器往往存在大量，因此需要將更多數據傳遞到更多地方更經常； +- 對於影片分享的特定示例，ActivityPub 熱衷者意識到從服務器到服務器傳輸影片是完全不可能的，所以他們決定將影片僅從發布它的單個實例中托管，這與 Nostr 方法類似。 -### The problem with SSB (Secure Scuttlebutt) +### SSB（Secure Scuttlebutt）的問題 -- It doesn't have many problems. I think it's great. 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_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); -- 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. +- 它沒有太多問題。我認為它很棒。我本來想將其用作基礎來進行此項目，但是 +- 因為它沒有考慮成為一個開放協議，所以其協議過於複雜。它只是用 JavaScript 編寫，可能是為了快速解決特定問題，然後從那裡發展而來，因此它具有奇怪且不必要的怪癖，如簽署必須嚴格遵循 [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify) 規則的 JSON 字符串； +- 它堅持需要來自單個用戶的更新鏈，我認為這是不必要的，它增加了贅餘和僵硬的東西——每個服務器/用戶需要存儲所有文章鏈以確保新文章有效。為甚麼？（也許他們有一個好的理由）； +- 它不像 Nostr 那麼簡單，因為它主要是用於 P2P 同步，並且「pubs」是一個次要考慮的問題； +- 儘管如此，仍然值得考慮改用 SSB 而不是這個自定義協議，並將其適應為客戶端-中繼服務器模型，因為重複使用標准始終比嘗試讓人們使用新標准更好。 -### The problem with other solutions that require everybody to run their own server +### 其他需要每個人運行自己服務器的解決方案的問題 -- They require everybody to run their own server; -- Sometimes people can still be censored in these because domain names can be censored. +- 它們要求每個人都運行自己的服務器； +- 有時人們仍然可能會在其中被審查，因為域名可能會受到審查。 -## How does Nostr work? +## Nostr 如何運作？ -- 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. From 93588e7fb8df4d720ec9625361577f94cfd0f95a Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 12:25:31 +0800 Subject: [PATCH 09/77] Update README.md --- "translate/\344\270\255\346\226\207/README.md" | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 2351db7..87faf2e 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -54,11 +54,11 @@ ## Nostr 如何運作？ - 有兩個組件：**客戶端** 和 **中繼服務器**。每個用戶都運行客戶端。任何人都可以運行中繼服務器。 -- 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. +- 每個用戶都由公共密鑰識別。每個帖子都經過簽署。每個客戶端驗證這些簽名。 +- 客戶端從其選擇的中繼服務器提取數據並將數據發布到其選擇的其他中繼服務器。一個中繼服務器不與另一個中繼服務器通信，僅直接與用戶通信。 +- 例如，要「關注」某人，用戶只需指示其客戶端向其所知的中繼服務器查詢來自該公共密鑰的帖子。 +- 在啟動時，客戶端會從其所知道的所有中繼服務器中查詢所有其正在關注的用戶的數據（例如，從最近一天開始的所有更新），然後按時間順序向用戶顯示該數據。 +- 「貼文」可以包含任何形式的結構化數據，但最常用的數據將在標準中找到其位置，因此所有客戶端和中繼服務器都可以無縫處理它們。 ## How does it solve the problems the networks above can't? From 8f10ab075fbae01531db1a84cf8540d9b648da80 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 12:26:49 +0800 Subject: [PATCH 10/77] Update README.md --- "translate/\344\270\255\346\226\207/README.md" | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 87faf2e..c81e4c8 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -60,10 +60,10 @@ - 在啟動時，客戶端會從其所知道的所有中繼服務器中查詢所有其正在關注的用戶的數據（例如，從最近一天開始的所有更新），然後按時間順序向用戶顯示該數據。 - 「貼文」可以包含任何形式的結構化數據，但最常用的數據將在標準中找到其位置，因此所有客戶端和中繼服務器都可以無縫處理它們。 -## How does it solve the problems the networks above can't? +## 它如何解決上述網絡無法解決的問題？ -- **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. From 6e4aaec6299bb74576a6d109779f20cf750841e0 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 12:42:32 +0800 Subject: [PATCH 11/77] Update README.md --- .../\344\270\255\346\226\207/README.md" | 44 +++++++++---------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index c81e4c8..229d334 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -1,15 +1,15 @@ -# nostr - 透過中繼傳輸的筆記和其他資訊 +# nostr - 透過中繼轉接器傳輸的筆記和其他資訊 > Notes and Other Stuff Transmitted by Relays 最簡單的開放協議，能夠一次性創建一個抵抗審查的全球「社交」網絡。 -它不依賴任何值得信賴的中央服務器，因此它具有韌性；它基於密碼學密鑰和簽名，因此它是防篡改的；它不依賴P2P技術，因此它能夠運作。 +它不依賴任何值得信賴的中央伺服器，因此它具有韌性；它基於密碼學密鑰和簽名，因此它是防篡改的；它不依賴P2P技術，因此它能夠運作。 這是一個正在進行中的工作，[歡迎加入 Telegram 群組！](https://t.me/nostr_protocol) ## 如果你不打算閱讀其他內容，以下是它運作的簡短摘要： -每個人都運行客戶端。它可以是原生客戶端、Web 客戶端等。要發布內容，您需要撰寫一篇文章，用您的金鑰對其進行簽名，然後將其發送到多個轉接器（由他人或您自己託管的服務器）。要獲取其他人的更新，您可以向多個轉接器請求是否有關於這些其他人的任何信息。任何人都可以運行轉接器。轉接器非常簡單和愚笨。它除了接受某些人的文章並轉發給其他人之外什麼也不做。轉接器不需要受信任。簽名在客戶端上驗證。 +每個人都運行客戶端。它可以是原生客戶端、Web 客戶端等。要發佈內容，您需要撰寫一篇文章，用您的金鑰對其進行簽名，然後將其發送到多個中斷轉接器（由他人或您自己託管的伺服器）。要獲取其他人的更新，您可以向多個轉接器請求是否有關於這些其他人的任何信息。任何人都可以運行轉接器。轉接器非常簡單和愚笨。它除了接受某些人的文章並轉發給其他人之外什麼也不做。轉接器不需要受信任。簽名在客戶端上驗證。 [如何開始使用 Nostr](https://github.com/vishalxl/nostr_console/discussions/31) @@ -17,7 +17,7 @@ [基於 Nostr 的項目列表](https://github.com/aljazceru/awesome-nostr) -## 需要這是因為其他解決方案出現問題： +## 需要 Nostr 是因為其他解決方案出現問題： ### Twitter 的問題 @@ -31,40 +31,40 @@ ### Mastodon 和類似程序的問題 - 使用者身份附加在由第三方控制的域名上； -- 服務器擁有者可以像 Twitter 一樣禁止您；服務器擁有者還可以阻止其他服務器； -- 在對抗環境中，遷移之間是一個後顧之憂，只有服務器合作才能實現。在失敗的情況下，所有追蹤者都會丟失； -- 沒有明確的激勵措施來運行服務器，因此它們往往由熱心愛好者和想要將自己的名字與一個很酷的域名相關聯的人來運行。然後，用戶受到單個人的專制統治，這通常比 Twitter 等大公司更糟糕，他們無法遷移出去； -- 由於服務器往往是業餘人士運行，所以它們經常在一段時間後被廢棄——這與禁止每個人的效果相同； -- 如果每個服務器的更新必須痛苦地推送（和保存！）到許多其他服務器，那麼擁有大量服務器是毫無意義的。這一點由於服務器往往存在大量，因此需要將更多數據傳遞到更多地方更經常； -- 對於影片分享的特定示例，ActivityPub 熱衷者意識到從服務器到服務器傳輸影片是完全不可能的，所以他們決定將影片僅從發布它的單個實例中托管，這與 Nostr 方法類似。 +- 伺服器擁有者可以像 Twitter 一樣禁止您；伺服器擁有者還可以阻止其他伺服器； +- 在對抗環境中，遷移之間是一個後顧之憂，只有伺服器合作才能實現。在失敗的情況下，所有追蹤者都會丟失； +- 沒有明確的激勵措施來運行伺服器，因此它們往往由熱心愛好者和想要將自己的名字與一個很酷的域名相關聯的人來運行。然後，用戶受到單個人的專制統治，這通常比 Twitter 等大公司更糟糕，他們無法遷移出去； +- 由於伺服器往往是業餘人士運行，所以它們經常在一段時間後被廢棄——這與禁止每個人的效果相同； +- 如果每個伺服器的更新必須痛苦地推送（和保存！）到許多其他伺服器，那麼擁有大量伺服器是毫無意義的。這一點由於伺服器往往存在大量，因此需要將更頻繁將更多數據傳遞到更多地方； +- 對於影片分享的特定示例，ActivityPub 熱衷者意識到從伺服器傳輸影片至其他伺服器是完全不可能的，所以他們決定將影片僅從發佈它的單個實例中托管，這與 Nostr 方法類似。 ### SSB（Secure Scuttlebutt）的問題 - 它沒有太多問題。我認為它很棒。我本來想將其用作基礎來進行此項目，但是 - 因為它沒有考慮成為一個開放協議，所以其協議過於複雜。它只是用 JavaScript 編寫，可能是為了快速解決特定問題，然後從那裡發展而來，因此它具有奇怪且不必要的怪癖，如簽署必須嚴格遵循 [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify) 規則的 JSON 字符串； -- 它堅持需要來自單個用戶的更新鏈，我認為這是不必要的，它增加了贅餘和僵硬的東西——每個服務器/用戶需要存儲所有文章鏈以確保新文章有效。為甚麼？（也許他們有一個好的理由）； +- 它堅持需要來自單個用戶的更新鏈，我認為這是不必要的，它增加了贅餘和僵硬的東西——每個伺服器/用戶需要存儲所有文章鏈以確保新文章有效。為甚麼？（也許他們有一個好的理由）； - 它不像 Nostr 那麼簡單，因為它主要是用於 P2P 同步，並且「pubs」是一個次要考慮的問題； -- 儘管如此，仍然值得考慮改用 SSB 而不是這個自定義協議，並將其適應為客戶端-中繼服務器模型，因為重複使用標准始終比嘗試讓人們使用新標准更好。 +- 儘管如此，仍然值得考慮改用 SSB 而不是這個自定義協議，並將其適應為客戶端-中繼轉接器模型，因為重複使用標准始終比嘗試讓人們使用新標准更好。 -### 其他需要每個人運行自己服務器的解決方案的問題 +### 其他需要每個人運行自己伺服器的解決方案的問題 -- 它們要求每個人都運行自己的服務器； +- 它們要求每個人都運行自己的伺服器； - 有時人們仍然可能會在其中被審查，因為域名可能會受到審查。 ## Nostr 如何運作？ -- 有兩個組件：**客戶端** 和 **中繼服務器**。每個用戶都運行客戶端。任何人都可以運行中繼服務器。 -- 每個用戶都由公共密鑰識別。每個帖子都經過簽署。每個客戶端驗證這些簽名。 -- 客戶端從其選擇的中繼服務器提取數據並將數據發布到其選擇的其他中繼服務器。一個中繼服務器不與另一個中繼服務器通信，僅直接與用戶通信。 -- 例如，要「關注」某人，用戶只需指示其客戶端向其所知的中繼服務器查詢來自該公共密鑰的帖子。 -- 在啟動時，客戶端會從其所知道的所有中繼服務器中查詢所有其正在關注的用戶的數據（例如，從最近一天開始的所有更新），然後按時間順序向用戶顯示該數據。 -- 「貼文」可以包含任何形式的結構化數據，但最常用的數據將在標準中找到其位置，因此所有客戶端和中繼服務器都可以無縫處理它們。 +- 有兩個組件：**客戶端** 和 **中繼轉接器**。每個用戶都運行客戶端。任何人都可以運行中繼轉接器。 +- 每個用戶都由公共密鑰識別。每個貼文都經過簽署。每個客戶端驗證這些簽名。 +- 客戶端從其選擇的中繼轉接器提取數據並將數據發佈到其選擇的其他中繼轉接器。一個中繼轉接器不與另一個中繼轉接器通信，僅直接與用戶通信。 +- 例如，要「關注」某人，用戶只需指示其客戶端向其所知的中繼轉接器查詢來自該公共密鑰的貼文。 +- 在啟動時，客戶端會從其所知道的所有中繼轉接器中查詢所有其正在關注的用戶的數據（例如，從最近一天開始的所有更新），然後按時間順序向用戶顯示該數據。 +- 「貼文」可以包含任何形式的結構化數據，但最常用的數據將在標準中找到其位置，因此所有客戶端和中繼轉接器都可以無縫處理它們。 ## 它如何解決上述網絡無法解決的問題？ - **用戶被禁止和服務器被關閉** - - 中繼服務器可以阻止用戶在那裡發佈任何內容，但對他們沒有任何影響，因為他們仍然可以發佈到其他中繼服務器。由於用戶由公共密鑰識別，因此當他們被禁止時，他們不會失去自己的身份和追隨者基礎。 - - 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. + - 中繼轉接器可以阻止用戶在那裡發佈任何內容，但對他們沒有任何影響，因為他們仍然可以發佈到其他中繼轉接器。由於用戶由公共密鑰識別，因此當他們被禁止時，他們不會失去自己的身份和追隨者基礎。 + - 除了要求用戶手動輸入新的中繼轉接器地址（雖然這也應得到支持）之外，如果你正在關注的某人發佈服務器建議，則客戶端應自動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. From 201944e665656603658abaca24b5d66361a35a22 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 12:51:37 +0800 Subject: [PATCH 12/77] Update README.md --- .../\344\270\255\346\226\207/README.md" | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 229d334..4fc87e6 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -26,7 +26,7 @@ - Twitter 不顯示您關注的人的實際歷史動態； - Twitter 禁止某些人； - Twitter 隱藏某些人； -- Twitter 有很多垃圾郵件。 +- Twitter 有很多詐騙訊息。 ### Mastodon 和類似程序的問題 @@ -62,19 +62,19 @@ ## 它如何解決上述網絡無法解決的問題？ -- **用戶被禁止和服務器被關閉** +- **用戶被禁止和轉接器被關閉** - 中繼轉接器可以阻止用戶在那裡發佈任何內容，但對他們沒有任何影響，因為他們仍然可以發佈到其他中繼轉接器。由於用戶由公共密鑰識別，因此當他們被禁止時，他們不會失去自己的身份和追隨者基礎。 - - 除了要求用戶手動輸入新的中繼轉接器地址（雖然這也應得到支持）之外，如果你正在關注的某人發佈服務器建議，則客戶端應自動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. + - 除了要求用戶手動輸入新的中繼轉接器地址（雖然這也應得到支持）之外，如果你正在關注的某人發佈轉接器建議，則客戶端應自動將其添加到它將查詢的中繼轉接器列表中。 + - 如果有人使用中繼轉接器發佈其數據，但想遷移到另一個中繼轉接器，則可以向該先前的中繼轉接器發佈轉接器建議，然後再移動； + - 如果某個人被多個中繼轉接器封鎖，以至於他們無法廣播其轉接器建議，他們仍然可以通過其他方式告訴一些親密的朋友他們現在正在哪個中繼轉接器上發佈。然後，這些親密的朋友可以向新轉接器發佈轉接器建議，慢慢地，被封鎖的用戶的舊追隨者群將開始從新的中繼轉接器中找到他們的貼文。 + - 以上所有內容也適用於中繼轉接器停止運營的情況。 -- **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. From 055bd33dc0fc175ef17eb6defdf75ba6f31b2449 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 13:05:49 +0800 Subject: [PATCH 13/77] Update README.md --- .../\344\270\255\346\226\207/README.md" | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 4fc87e6..1dc2363 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -76,33 +76,33 @@ - **詐騙訊息** - 若詐騙訊息對中繼轉接器造成威脅，它可以要求用戶支付發佈費用或其他形式的驗證，例如電子郵件地址或手機號碼，並在內部與一個公共密鑰相關聯，然後該公共密鑰就可以發佈到該中繼轉接器上 - 或者其他抗詐騙訊息技術，例如哈希現金或驗證碼。如果中繼轉接器被用作詐騙訊息向量，則客戶端可以輕鬆將其從列表中刪除，並繼續從其他中繼轉接器獲取更新。 -- **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或類似軟件來說相對較少。 + - 或者考慮另一種情況：存在數百個業餘運營的小型中繼轉接器，每個中繼轉接器都中繼來自一小組用戶的更新。該體系結構同樣可擴展：數據從用戶發送到單個伺服器，然後從該伺服器直接傳送給將要消費該數據的用戶。它不需要由任何其他人存儲。在這種情況下，任何單個伺服器處理來自其他用戶的更新都不是什麼大負擔，並且擁有業餘伺服器不是問題。 -- **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. +- **欺騙用戶的技術** + - 每個客戶端都可以決定如何最好地向用戶顯示貼文，因此始終有選擇按您想要的方式消耗內容的選項 - 從使用人工智能來決定您將看到的更新的順序，到按時間順序閱讀它們。 -## FAQ +## 常見問題 FAQ -- **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?** From 81a2daba4fb7d9b0d6c8dd7722b7d39e5a830843 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 13:11:56 +0800 Subject: [PATCH 14/77] Update README.md --- .../\344\270\255\346\226\207/README.md" | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 1dc2363..065ea89 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -90,36 +90,36 @@ - **這很簡單。為甚麼以前沒有人這樣做？** -我不知道，但我想這可能與製作社交網絡的人要麼是想賺錢的公司，要麼是想完全不使用伺服器的P2P活動家有關。他們都未能看到Nostr使用的兩個世界的具體結合。 + 我不知道，但我想這可能與製作社交網絡的人要麼是想賺錢的公司，要麼是想完全不使用伺服器的P2P活動家有關。他們都未能看到Nostr使用的兩個世界的具體結合。 - **我如何找到要關注的人？** -首先，您必須知道他們，並以某種方式獲得他們的公共密鑰，可以通過請求或在某個地方看到它們的引用來獲取。一旦進入Nostr社交網絡，您就可以看到他們與其他人的互動，然後您也可以開始關注和與其他人互動。 + 首先，您必須知道他們，並以某種方式獲得他們的公共密鑰，可以通過請求或在某個地方看到它們的引用來獲取。一旦進入Nostr社交網絡，您就可以看到他們與其他人的互動，然後您也可以開始關注和與其他人互動。 - **我如何找到中繼轉接器？如果我與其他人未連接到同一個中繼轉接器會發生甚麼？** -您將無法與該人進行通信。但是，有關事件的提示可以用作您的客戶端軟件（或您手動）知道如何連接到另一個人的中繼轉接器並與其互動。未來還有其他解決此問題的想法，但我們無法保證完美的可達性，沒有協議可以實現這一點。 + 您將無法與該人進行通信。但是，有關事件的提示可以用作您的客戶端軟件（或您手動）知道如何連接到另一個人的中繼轉接器並與其互動。未來還有其他解決此問題的想法，但我們無法保證完美的可達性，沒有協議可以實現這一點。 - **我可以知道有多少人在關注我嗎？** -不行，但如果中繼轉接器在協議之外合作，您可以得到一些估計。 + 不行，但如果中繼轉接器在協議之外合作，您可以得到一些估計。 -- **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?** +- **Nostr使您能夠在伺服器中繼之間移動或使用多個中繼，但如果這些中繼只是在AWS或Azure上，有甚麼不同嗎？** - 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是單一集中服務提供商使用的提供商，需要大量規模，即使這樣也不僅僅是這兩個。對於小型中繼轉接器，任何VPS都可以很好地完成工作。 -## Protocol specification +## 協議規範 -See the [NIPs](https://github.com/nostr-protocol/nips) and especially [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) for a reasonably-detailed explanation of the protocol spec (hint: it is very short and simple). +請參閱[NIPs](https://github.com/nostr-protocol/nips)和特別是[NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md)，其中對協議規範進行了相當詳細的解釋（提示：非常簡短和簡單）。 -## Software +## 軟件 -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. +有一個正在使用Nostr構建的軟件列表，可在 https://github.com/aljazceru/awesome-nostr 上查看，上次我看到它時，它似乎幾乎是完整的。 -## License +## 許可 -Public domain. +公共領域。 From 6b6400ca07c863c4dc57edf55cda8edab50e8bb8 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 13:38:35 +0800 Subject: [PATCH 15/77] Update README.md --- .../\344\270\255\346\226\207/README.md" | 44 +++++++++---------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 065ea89..63c2ded 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -3,13 +3,13 @@ 最簡單的開放協議，能夠一次性創建一個抵抗審查的全球「社交」網絡。 -它不依賴任何值得信賴的中央伺服器，因此它具有韌性；它基於密碼學密鑰和簽名，因此它是防篡改的；它不依賴P2P技術，因此它能夠運作。 +它不依賴任何信賴中央伺服器，因此它具有韌性；它基於密碼學密鑰及簽名，因此它是防篡改的；它不依賴P2P技術，因此它能夠運作。 -這是一個正在進行中的工作，[歡迎加入 Telegram 群組！](https://t.me/nostr_protocol) +這是一個正在進行中的作業，[歡迎加入 Telegram 群組！](https://t.me/nostr_protocol) -## 如果你不打算閱讀其他內容，以下是它運作的簡短摘要： +## 如果你不打算閱讀其他內容，以下是其如何運作的簡短摘要： -每個人都運行客戶端。它可以是原生客戶端、Web 客戶端等。要發佈內容，您需要撰寫一篇文章，用您的金鑰對其進行簽名，然後將其發送到多個中斷轉接器（由他人或您自己託管的伺服器）。要獲取其他人的更新，您可以向多個轉接器請求是否有關於這些其他人的任何信息。任何人都可以運行轉接器。轉接器非常簡單和愚笨。它除了接受某些人的文章並轉發給其他人之外什麼也不做。轉接器不需要受信任。簽名在客戶端上驗證。 +每個人都運行客戶端。它可以是原生客戶端、Web客戶端等。要發佈內容，您需要撰寫一篇文章，用您的密鑰對其進行簽名，然後將其發送到多個中斷轉接器（由他人或您自己託管的伺服器）。要獲取其他人的更新，您可以向多個轉接器請求是否有關於這些其他人的任何信息。任何人都可以運行轉接器。轉接器結構非常簡潔。它除了接收貼文並轉發給其他人之外甚麼也不做。轉接器不需要被信任。簽名在客戶端上驗證。 [如何開始使用 Nostr](https://github.com/vishalxl/nostr_console/discussions/31) @@ -24,7 +24,7 @@ - Twitter 有廣告； - Twitter 使用奇怪的技術讓你上癮； - Twitter 不顯示您關注的人的實際歷史動態； -- Twitter 禁止某些人； +- Twitter 封鎖某些人； - Twitter 隱藏某些人； - Twitter 有很多詐騙訊息。 @@ -32,19 +32,19 @@ - 使用者身份附加在由第三方控制的域名上； - 伺服器擁有者可以像 Twitter 一樣禁止您；伺服器擁有者還可以阻止其他伺服器； -- 在對抗環境中，遷移之間是一個後顧之憂，只有伺服器合作才能實現。在失敗的情況下，所有追蹤者都會丟失； -- 沒有明確的激勵措施來運行伺服器，因此它們往往由熱心愛好者和想要將自己的名字與一個很酷的域名相關聯的人來運行。然後，用戶受到單個人的專制統治，這通常比 Twitter 等大公司更糟糕，他們無法遷移出去； -- 由於伺服器往往是業餘人士運行，所以它們經常在一段時間後被廢棄——這與禁止每個人的效果相同； -- 如果每個伺服器的更新必須痛苦地推送（和保存！）到許多其他伺服器，那麼擁有大量伺服器是毫無意義的。這一點由於伺服器往往存在大量，因此需要將更頻繁將更多數據傳遞到更多地方； -- 對於影片分享的特定示例，ActivityPub 熱衷者意識到從伺服器傳輸影片至其他伺服器是完全不可能的，所以他們決定將影片僅從發佈它的單個實例中托管，這與 Nostr 方法類似。 +- 在競爭環境中，在伺服器之間遷移是一個後顧之憂，只有伺服器合作才能實現。在失敗的情況下，所有追蹤者都會丟失； +- 運行伺服器不存在明確的激勵措施，因此它們往往是由熱心愛好者及想要將自己的名字與一個很酷的域名連結的人來運行。然後，用戶受到特定個體的專制統治，這通常比 Twitter 等大公司更糟糕，而且用戶無法遷移； +- 由於伺服器往往是業餘人士運行，所以它們經常在一段時間後被廢棄 —— 其效果與封鎖每個人相同； +- 如果每個伺服器所有內容的更新必須透過痛苦地推送（和保存！）至許多其他伺服器，那麼擁有大量伺服器是毫無意義的。此論點基於由於存在大量伺服器，因此往往需要更頻繁將更多數據傳遞到更多地方； +- 對於影片分享的特定案例，ActivityPub 熱衷者意識到從伺服器傳輸影片至其他伺服器是完全不可能的，所以他們決定將影片僅從發佈至它的單個實例中托管，這與 Nostr 方法類似。 ### SSB（Secure Scuttlebutt）的問題 - 它沒有太多問題。我認為它很棒。我本來想將其用作基礎來進行此項目，但是 -- 因為它沒有考慮成為一個開放協議，所以其協議過於複雜。它只是用 JavaScript 編寫，可能是為了快速解決特定問題，然後從那裡發展而來，因此它具有奇怪且不必要的怪癖，如簽署必須嚴格遵循 [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify) 規則的 JSON 字符串； -- 它堅持需要來自單個用戶的更新鏈，我認為這是不必要的，它增加了贅餘和僵硬的東西——每個伺服器/用戶需要存儲所有文章鏈以確保新文章有效。為甚麼？（也許他們有一個好的理由）； -- 它不像 Nostr 那麼簡單，因為它主要是用於 P2P 同步，並且「pubs」是一個次要考慮的問題； -- 儘管如此，仍然值得考慮改用 SSB 而不是這個自定義協議，並將其適應為客戶端-中繼轉接器模型，因為重複使用標准始終比嘗試讓人們使用新標准更好。 +- 因為它沒有考慮成為一個開放協議，所以其協議過於複雜。它只用 JavaScript 編寫，可能是為了快速解決特定問題，然後從此基礎發展而來，因此它具有奇怪且不必要的怪癖，如簽署必須嚴格遵循 [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify) 規則的 JSON 字符串； +- 它堅持需要來自單個用戶的更新鏈，我認為這是不必要的，它增加了贅餘和僵硬的東西 —— 每個伺服器/用戶都需要存儲所有貼文鏈以確保新貼文有效。為甚麼？（也許他們有一個好的理由）； +- 它不像 Nostr 那麼簡潔，因為它主要用於 P2P 同步，「pubs」是一個次要考慮的問題； +- 儘管如此，仍然值得考慮改用 SSB 而不是這個自定義協議，並將其適應於客戶端-中繼轉接器模型，因為重複使用標準始終比嘗試讓人們使用新標準好。 ### 其他需要每個人運行自己伺服器的解決方案的問題 @@ -54,19 +54,19 @@ ## Nostr 如何運作？ - 有兩個組件：**客戶端** 和 **中繼轉接器**。每個用戶都運行客戶端。任何人都可以運行中繼轉接器。 -- 每個用戶都由公共密鑰識別。每個貼文都經過簽署。每個客戶端驗證這些簽名。 +- 每個用戶都由公共密鑰識別。每個貼文都經過簽署。每個客戶端都驗證這些簽名。 - 客戶端從其選擇的中繼轉接器提取數據並將數據發佈到其選擇的其他中繼轉接器。一個中繼轉接器不與另一個中繼轉接器通信，僅直接與用戶通信。 -- 例如，要「關注」某人，用戶只需指示其客戶端向其所知的中繼轉接器查詢來自該公共密鑰的貼文。 -- 在啟動時，客戶端會從其所知道的所有中繼轉接器中查詢所有其正在關注的用戶的數據（例如，從最近一天開始的所有更新），然後按時間順序向用戶顯示該數據。 -- 「貼文」可以包含任何形式的結構化數據，但最常用的數據將在標準中找到其位置，因此所有客戶端和中繼轉接器都可以無縫處理它們。 +- 例如，要「關注」某人，用戶只需指示其使用者介面（應用程式）向其所知的中繼轉接器查詢來自該公共密鑰的貼文。 +- 在啟動時，使用者介面會從其所知道的所有中繼轉接器中查詢所有其正在關注的用戶的數據（例如，從最近一天開始的所有更新），然後按時間順序向用戶顯示該數據。 +- 「貼文」可以包含任何形式的結構化數據，但最常用的數據將在標準中找到其位置，因此所有使用者介面和中繼轉接器都可以無縫處理它們。 ## 它如何解決上述網絡無法解決的問題？ -- **用戶被禁止和轉接器被關閉** - - 中繼轉接器可以阻止用戶在那裡發佈任何內容，但對他們沒有任何影響，因為他們仍然可以發佈到其他中繼轉接器。由於用戶由公共密鑰識別，因此當他們被禁止時，他們不會失去自己的身份和追隨者基礎。 - - 除了要求用戶手動輸入新的中繼轉接器地址（雖然這也應得到支持）之外，如果你正在關注的某人發佈轉接器建議，則客戶端應自動將其添加到它將查詢的中繼轉接器列表中。 +- **用戶被禁止及轉接器被關閉** + - 中繼轉接器可以阻止用戶透過它發佈任何內容，但對用戶沒有任何影響，因為用戶仍然可以發佈至其他中繼轉接器。由於用戶由公共密鑰識別，因此當他們被禁止時，他們不會失去自己的身份和追隨者基礎。 + - 除了要求用戶手動輸入新的中繼轉接器地址（雖然這也應得到支持）外，如果你正在關注的某人發佈轉接器建議，則使用者介面應自動將其添加到它將查詢的中繼轉接器列表中。 - 如果有人使用中繼轉接器發佈其數據，但想遷移到另一個中繼轉接器，則可以向該先前的中繼轉接器發佈轉接器建議，然後再移動； - - 如果某個人被多個中繼轉接器封鎖，以至於他們無法廣播其轉接器建議，他們仍然可以通過其他方式告訴一些親密的朋友他們現在正在哪個中繼轉接器上發佈。然後，這些親密的朋友可以向新轉接器發佈轉接器建議，慢慢地，被封鎖的用戶的舊追隨者群將開始從新的中繼轉接器中找到他們的貼文。 + - 如果某個人被多個中繼轉接器封鎖，以至於他們無法廣播其轉接器建議，他們仍然可以通過其他方式告訴朋友他們現在正在透過哪個中繼轉接器發佈。然後，這些朋友可以向新轉接器發佈轉接器建議，與時俱進，被封鎖的用戶的舊追隨者群將開始從新的中繼轉接器中找到他們的貼文。 - 以上所有內容也適用於中繼轉接器停止運營的情況。 - **對審查的抗爭** From 9dac9bf8523f4e64dd9daf42e7a9789d0b02ce43 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 13:47:03 +0800 Subject: [PATCH 16/77] Update README.md --- "translate/\344\270\255\346\226\207/README.md" | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 63c2ded..000993f 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -70,27 +70,27 @@ - 以上所有內容也適用於中繼轉接器停止運營的情況。 - **對審查的抗爭** - - 每個用戶可以將其更新發佈到任意數量的中繼轉接器上。 - - 中繼轉接器可以向用戶收取費用（目前協商該費用的金額外部協議），以確保它們不會受到審查（總是有一些願意接受你的錢以提供服務的俄羅斯轉接器）。 + - 每個用戶可以將其更新資訊發佈到任意數量的中繼轉接器上。 + - 中繼轉接器可以向用戶收取費用（目前協商該費用的金額外部協議），以確保它們不會受到審查（總會有一些願意接受你的錢以提供服務的俄羅斯轉接器）。 - **詐騙訊息** - - 若詐騙訊息對中繼轉接器造成威脅，它可以要求用戶支付發佈費用或其他形式的驗證，例如電子郵件地址或手機號碼，並在內部與一個公共密鑰相關聯，然後該公共密鑰就可以發佈到該中繼轉接器上 - 或者其他抗詐騙訊息技術，例如哈希現金或驗證碼。如果中繼轉接器被用作詐騙訊息向量，則客戶端可以輕鬆將其從列表中刪除，並繼續從其他中繼轉接器獲取更新。 + - 若詐騙訊息對中繼轉接器造成威脅，它可以要求用戶支付發佈費用或其他形式的驗證，例如電子郵件地址或手機號碼，並在內部與一個公共密鑰相聯，然後該公共密鑰就可以發佈到該中繼轉接器上 - 或者其他抗詐騙訊息技術，例如雜湊現金演算法或驗證碼。如果特定中繼轉接器被用作詐騙訊息媒介，透過使用者介面可以輕鬆將其從列表中刪除，並繼續從其他中繼轉接器獲取更新。 - **數據存儲** - - 為了保持網絡健康，並不需要數百個活躍的中繼轉接器。實際上，只有幾個轉接器也可以運作得很好，因為在現有的中繼轉接器開始運作不當的情況下，新的中繼轉接器可以很容易地在網絡中創建並傳播。因此，總體而言，所需的數據存儲量相對於Mastodon或類似軟件來說相對較少。 + - 為了保持網絡健康，並不需要數百個活躍的中繼轉接器。實際上，只有幾個轉接器也可以運作得很好，因為在現有的中繼轉接器開始運作不當的情況下，新的中繼轉接器可以很容易地在網絡中創建並傳播。因此，總體而言，所需的數據存儲量相對於 Mastodon 或類似軟件來說相對較少。 - 或者考慮另一種情況：存在數百個業餘運營的小型中繼轉接器，每個中繼轉接器都中繼來自一小組用戶的更新。該體系結構同樣可擴展：數據從用戶發送到單個伺服器，然後從該伺服器直接傳送給將要消費該數據的用戶。它不需要由任何其他人存儲。在這種情況下，任何單個伺服器處理來自其他用戶的更新都不是什麼大負擔，並且擁有業餘伺服器不是問題。 - **影片和其他重型內容** - 中繼轉接器可以輕鬆拒絕大型內容，或收取費用以接受和托管大型內容。當信息和激勵措施清晰時，市場力量可以輕鬆解決問題。 - **欺騙用戶的技術** - - 每個客戶端都可以決定如何最好地向用戶顯示貼文，因此始終有選擇按您想要的方式消耗內容的選項 - 從使用人工智能來決定您將看到的更新的順序，到按時間順序閱讀它們。 + - 每個使用者介面都可以決定如何最好地向用戶顯示貼文，因此始終有選擇按您想要的方式消耗內容的選項 - 從使用人工智能來決定您將看到的更新的順序，到按時間順序閱讀它們。 ## 常見問題 FAQ - **這很簡單。為甚麼以前沒有人這樣做？** - 我不知道，但我想這可能與製作社交網絡的人要麼是想賺錢的公司，要麼是想完全不使用伺服器的P2P活動家有關。他們都未能看到Nostr使用的兩個世界的具體結合。 + 我不知道，但我想這可能與製作社交網絡的人要麼是想賺錢的公司、要麼是想完全不使用伺服器的P2P活動分子有關。他們都未能看到Nostr使用的兩個世界的具體結合。 - **我如何找到要關注的人？** @@ -98,7 +98,7 @@ - **我如何找到中繼轉接器？如果我與其他人未連接到同一個中繼轉接器會發生甚麼？** - 您將無法與該人進行通信。但是，有關事件的提示可以用作您的客戶端軟件（或您手動）知道如何連接到另一個人的中繼轉接器並與其互動。未來還有其他解決此問題的想法，但我們無法保證完美的可達性，沒有協議可以實現這一點。 + 您將無法與該人進行通信。但是，有關事件的提示可以用作您的使用者介面應用程式（或您手動）知道如何連接到另一個人的中繼轉接器並與其互動。未來還有其他解決此問題的想法，但我們無法保證完美的可達性，沒有協議可以實現這一點。 - **我可以知道有多少人在關注我嗎？** From 11b432c61401e9867beef3db08c4343f22b2e5f0 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 13:51:34 +0800 Subject: [PATCH 17/77] Update README.md --- .../README.md" | 126 +----------------- 1 file changed, 2 insertions(+), 124 deletions(-) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index eb6ac59..a99ffa1 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -1,124 +1,2 @@ -# nostr - Notes and Other Stuff Transmitted by Relays - -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, and therefore it works. - -This is a work in progress. [Join the Telegram group!](https://t.me/nostr_protocol) - -## Very short summary of how it works, if you don't plan to read anything else: - -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. - -[How to start using Nostr](https://github.com/vishalxl/nostr_console/discussions/31) - -[Nostr client feature comparison](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) - -[List of projects built on Nostr](https://github.com/aljazceru/awesome-nostr) - -## This is needed because other solutions are broken: - -### The problem with Twitter - -- 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. - -### The problem with Mastodon and similar programs - -- 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. - -### The problem with SSB (Secure Scuttlebutt) - -- It doesn't have many problems. I think it's great. 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_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); -- 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. - -### The problem with other solutions that require everybody to run their own server - -- They require everybody to run their own server; -- Sometimes people can still be censored in these because domain names can be censored. - -## How does Nostr work? - -- 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. - -## How does it solve the problems the networks above can't? - -- **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. - -- **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. - -- **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. - -## FAQ - -- **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. - -- **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. - -- **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? - -- **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. - -## Protocol specification - -See the [NIPs](https://github.com/nostr-protocol/nips) and especially [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) for a reasonably-detailed explanation of the protocol spec (hint: it is very short and simple). - -## Software - -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. - -## License - -Public domain. +# nostr - 中継によって送信されたメモやその他のもの +> Notes and Other Stuff Transmitted by Relays From eab3f86d772335665d36dfdf2faa04ce825b4df3 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 13:54:21 +0800 Subject: [PATCH 18/77] Create README.md --- "translate/Espa\303\261ol/README.md" | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 "translate/Espa\303\261ol/README.md" diff --git "a/translate/Espa\303\261ol/README.md" "b/translate/Espa\303\261ol/README.md" new file mode 100644 index 0000000..6ee909e --- /dev/null +++ "b/translate/Espa\303\261ol/README.md" @@ -0,0 +1,2 @@ +# nostr - Notas y Otras Cosas Transmitidas por Relevos +> Notes and Other Stuff Transmitted by Relays From 9815014425fe84b91675f4807e8f501e407b2bde Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 13:57:03 +0800 Subject: [PATCH 19/77] Create README.md --- "translate/Fran\303\247ais/README.md" | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 "translate/Fran\303\247ais/README.md" diff --git "a/translate/Fran\303\247ais/README.md" "b/translate/Fran\303\247ais/README.md" new file mode 100644 index 0000000..04e6568 --- /dev/null +++ "b/translate/Fran\303\247ais/README.md" @@ -0,0 +1,2 @@ +# nostr - Notes et Autres Choses Transmises par Relais +> Notes and Other Stuff Transmitted by Relays From 34657986e1ed55588517c81a6a39232dfd22da33 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 14:08:41 +0800 Subject: [PATCH 20/77] Create README.md --- "translate/\330\271\330\261\330\250\331\212/README.md" | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 "translate/\330\271\330\261\330\250\331\212/README.md" diff --git "a/translate/\330\271\330\261\330\250\331\212/README.md" "b/translate/\330\271\330\261\330\250\331\212/README.md" new file mode 100644 index 0000000..71fa690 --- /dev/null +++ "b/translate/\330\271\330\261\330\250\331\212/README.md" @@ -0,0 +1,2 @@ +# nostr - ملاحظات وأشياء أخرى مرسلة عبر الأرجحية +> Notes and Other Stuff Transmitted by Relays From 33d8dfd10f2de8bbfd0830aaec75d2f15b4f75e4 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 14:10:09 +0800 Subject: [PATCH 21/77] Create README.md --- translate/Deutsch/README.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 translate/Deutsch/README.md diff --git a/translate/Deutsch/README.md b/translate/Deutsch/README.md new file mode 100644 index 0000000..500867a --- /dev/null +++ b/translate/Deutsch/README.md @@ -0,0 +1,2 @@ +# nostr - Notizen und Andere Dinge, die per Relais Übertragen Werden +> Notes and Other Stuff Transmitted by Relays From 3a7b4e4735cbfa98198224685901fd473602a683 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 14:11:28 +0800 Subject: [PATCH 22/77] Create README.md --- "translate/Portugu\303\252s/README.md" | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 "translate/Portugu\303\252s/README.md" diff --git "a/translate/Portugu\303\252s/README.md" "b/translate/Portugu\303\252s/README.md" new file mode 100644 index 0000000..7eed14d --- /dev/null +++ "b/translate/Portugu\303\252s/README.md" @@ -0,0 +1,2 @@ +# nostr - Notas e Outras Coisas Transmitidas por Relés +> Notes and Other Stuff Transmitted by Relays From 87c8d058eccaf3eb1d7fbe5ec9a5d6fc97a95afa Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Feb 2023 16:23:11 +0800 Subject: [PATCH 23/77] Update README.md --- "translate/\344\270\255\346\226\207/README.md" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/translate/\344\270\255\346\226\207/README.md" "b/translate/\344\270\255\346\226\207/README.md" index 000993f..f16b916 100644 --- "a/translate/\344\270\255\346\226\207/README.md" +++ "b/translate/\344\270\255\346\226\207/README.md" @@ -31,7 +31,7 @@ ### Mastodon 和類似程序的問題 - 使用者身份附加在由第三方控制的域名上； -- 伺服器擁有者可以像 Twitter 一樣禁止您；伺服器擁有者還可以阻止其他伺服器； +- 伺服器擁有者可以像 Twitter 一樣封鎖您；伺服器擁有者還可以阻止其他伺服器； - 在競爭環境中，在伺服器之間遷移是一個後顧之憂，只有伺服器合作才能實現。在失敗的情況下，所有追蹤者都會丟失； - 運行伺服器不存在明確的激勵措施，因此它們往往是由熱心愛好者及想要將自己的名字與一個很酷的域名連結的人來運行。然後，用戶受到特定個體的專制統治，這通常比 Twitter 等大公司更糟糕，而且用戶無法遷移； - 由於伺服器往往是業餘人士運行，所以它們經常在一段時間後被廢棄 —— 其效果與封鎖每個人相同； From 51788abb512f89b99c88a73efc67b7050e5b014a Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 15:59:38 +0800 Subject: [PATCH 24/77] Update README.md --- .../README.md" | 29 ++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index a99ffa1..a911e9e 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -1,2 +1,29 @@ -# nostr - 中継によって送信されたメモやその他のもの +# nostr - リレーによる送信されるメモやその他のもの > Notes and Other Stuff Transmitted by Relays + +一度限りの検閲抵抗性のあるグローバルな「ソーシャル」ネットワークを作成できる、最もシンプルなオープンプロトコル。 + +信頼できる中央サーバーに依存しないため、強靱性があります。暗号鍵と署名に基づいているため、改竄防止性があります。P2P技術に依存しないため、動作します。 + +これは進行中の作業です。[Telegramグループに参加してください！](https://t.me/nostr_protocol) + +## それがどのように機能するかの非常に簡単な要約、それ以外を読む予定がない場合： + +誰もがクライアントを実行します。ネイティブクライアント、Webクライアントなどがあります。投稿するには、投稿を書き、キーで署名し、複数のリレー（他人または自分がホストするサーバー）に送信します。他の人から更新を取得するには、複数のリレーにその他の人物について何か知っているかどうか尋ねます。誰でもリレーを実行できます。リレーは非常にシンプルで愚かです。何もしないで、一部の人から投稿を受け取り、他の人に転送します。リレーは信頼される必要はありません。署名はクライアント側で検証されます。 + +[Nostrの使用を開始する方法](https://github.com/vishalxl/nostr_console/discussions/31) + +[Nostrクライアントの機能比較](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Nostrで構築されたプロジェクトのリスト](https://github.com/aljazceru/awesome-nostr) + +## これが必要な理由は、他の解決策が壊れているためです： + +### Twitterの問題 + +- Twitterには広告があります。 +- Twitterはあなたを中毒にさせる奇妙な技術を使っています。 +- Twitterは、フォローしている人々の実際の履歴的フィードを表示しません。 +- Twitterは人々を禁止します。 +- Twitterは人々をシャドウバンします。 +- Twitterには多くのスパムがあります。 From b3fa5ab7722f09097d04f2170844fd70ae8e3848 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 16:13:19 +0800 Subject: [PATCH 25/77] Update README.md --- .../README.md" | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index a911e9e..ba353b3 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -27,3 +27,25 @@ - Twitterは人々を禁止します。 - Twitterは人々をシャドウバンします。 - Twitterには多くのスパムがあります。 + +### Mastodonや類似のプログラムの問題点 + +- ユーザーのアイデンティティは、第三者によって制御されるドメイン名に紐づけられている。 +- サーバーのオーナーは、Twitterと同様にあなたを禁止することができる。サーバーのオーナーは他のサーバーをブロックすることもできる。 +- サーバー間の移行は、サーバーが協力しない限り後回しにされ、敵対的な環境では機能しない（全てのフォロワーが失われる）。 +- サーバーを運営するための明確なインセンティブが存在しないため、サーバーは愛好家やクールなドメインに名前を付けたい人たちによって運営される傾向があります。そして、ユーザーは一人の専制主義者の支配下に置かれ、しばしばTwitterのような大企業のそれよりも悪くなり、移動することができません。 +- サーバーが素人的に運営される傾向があるため、しばしば放棄されることがあります。これは事実上、全員を禁止するのと同じです。 +- 全てのサーバーからの更新を痛み分け（そして保存！）しなければならない場合、大量のサーバーを持つ意味がありません。この点は、サーバーが膨大な数存在する傾向があるため、より多くのデータをより頻繁により多くの場所に渡す必要があるため、悪化しています。 +- 動画共有の具体例として、ActivityPubの愛好家たちは、テキストノートのようにサーバー間でビデオを完全に伝送することは完全に不可能であることに気づき、ビデオを投稿した単一のインスタンスからのみホストされるようにすることに決めました。これはNostrのアプローチに似ています。 + +### SSB (Secure Scuttlebutt)の問題点 + +- 大きな問題はないと思います。とても素晴らしいと思います。私はこれを基にしていましたが、 +- このプロトコルは、オープンプロトコルになることは全く考慮されていないため、ある特定の問題を解決するために急いでJavaScriptで書かれ、それが拡大されたため、不必要で奇妙なクセがある、JSON文字列の署名がECMA-262第6版の規則に厳密に従わなければならないなどの問題があります。 +- 単一ユーザーからの更新チェーンを持つようにインサイトを持っているため、私にとっては不必要であり、物事に膨張性と剛性を加えるもののように感じられます - 各サーバー/ユーザーは新しいものが有効であることを確認するために、すべての投稿のチェーンを格納する必要があります。なぜ？（良い理由があるかもしれません） +- Nostrほど単純ではありませんが、P2P同期を主な目的として作られ、 "pubs" は後付けされたものであるため、SSBをこのカスタムプロトコルの代わりに使用し、クライアントリレーサーバーモデルに適応させることを検討する価値があります。標準を再利用する方が、新しい標準に人々を移行させるよりも常に良いからです。 + +### 他のソリューションの問題点 + +- すべての人が自分自身のサーバーを実行する必要があります。 +- ドメイン名が検閲されるため、これらの中でまだ検閲される可能性があります。 From b0ecca0194ab4db24e7c7afc7501c427df574b79 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 16:26:18 +0800 Subject: [PATCH 26/77] Update README.md --- .../README.md" | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index ba353b3..48f25b6 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -49,3 +49,21 @@ - すべての人が自分自身のサーバーを実行する必要があります。 - ドメイン名が検閲されるため、これらの中でまだ検閲される可能性があります。 + +## Nostrはどのように機能しますか？ + +- 2つのコンポーネント、__クライアント__と__リレー__があります。各ユーザーはクライアントを実行します。誰でもリレーを実行できます。 +- すべてのユーザーは公開鍵によって識別されます。すべての投稿に署名があります。すべてのクライアントはこれらの署名を検証します。 +- クライアントは、自分が選択したリレーからデータを取得し、自分が選択した他のリレーにデータを公開します。リレーは他のリレーとは話しません。直接ユーザーと通信します。 +- たとえば、誰かを「フォロー」する場合、ユーザーは自分のクライアントに対して、その公開鍵からの投稿をクエリするよう指示するだけです。 +- クライアントを起動すると、ユーザーがクロノロジカルに表示されるよう、クライアントはフォローするすべてのユーザーのすべてのリレーからデータを取得します（たとえば、最後の1日間のすべての更新）。。 +- 「投稿」には、任意の種類の構造化データを含めることができますが、最も使用されるものは標準に組み込まれるため、すべてのクライアントとリレーでシームレスに処理できます。 + +## どのようにして、Nostrは、上記のネットワークが解決できない問題を解決するのですか？ + +- **ユーザーの禁止およびサーバーの閉鎖** + - リレーは、そこに何も公開しないようにユーザーをブロックすることができますが、これは彼らが他のリレーに公開することができるため、彼らに影響を与えません。ユーザーは公開鍵によって識別されるため、禁止されたときにアイデンティティとフォロワーベースを失うことはありません。 + - 新しいリレーのアドレスを手動で入力する必要はありません（ただし、これはサポートされる必要があります）。フォローしている誰かがサーバーの推奨事項を投稿した場合、クライアントは自動的にそのリストに追加する必要があります。 + - データを公開するためにリレーを使用している人が、別のリレーに移行したい場合は、以前のリレーにサーバーの推奨事項を公開して、移行先に移動することができます。 + - 多くのリレーから禁止されて、サーバーの推奨事項を放送できなくなった場合、親しい友人には、どのリレーで投稿しているかを別の手段で知らせることができます。そうすることで、これらの親しい友人は、新しいリレーにサーバーの推奨事項を公開でき、徐々に禁止されたユーザーのフォロワーが、新しいリレーから彼らの投稿を再び見つけ始めます。 + - 上記のすべては、リレーが操作を停止した場合にも有効です。 From 1e9d3d482c29967718b100b653946094c6a2694d Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 16:31:11 +0800 Subject: [PATCH 27/77] Update README.md --- .../\346\227\245\346\234\254\350\252\236/README.md" | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index 48f25b6..f4ffcc1 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -67,3 +67,11 @@ - データを公開するためにリレーを使用している人が、別のリレーに移行したい場合は、以前のリレーにサーバーの推奨事項を公開して、移行先に移動することができます。 - 多くのリレーから禁止されて、サーバーの推奨事項を放送できなくなった場合、親しい友人には、どのリレーで投稿しているかを別の手段で知らせることができます。そうすることで、これらの親しい友人は、新しいリレーにサーバーの推奨事項を公開でき、徐々に禁止されたユーザーのフォロワーが、新しいリレーから彼らの投稿を再び見つけ始めます。 - 上記のすべては、リレーが操作を停止した場合にも有効です。 + +- **検閲への抵抗** + - 各ユーザーは、任意の数のリレーに自分のアップデートを投稿することができます。 + - リレーは、そこに投稿するためにユーザーから手数料を請求できます（その手数料の交渉は、現時点ではプロトコルの外側で行われます）。これにより、検閲への抵抗性が確保されます（あなたの投稿を提供するためにお金を受け取るロシアのサーバーが常に存在するため）。 + +- **スパム** + - スパムがリレーの懸念事項である場合、リレーは投稿のための支払いや、メールアドレスや電話番号などの認証形式、または内部的にパブキーに関連付けて、そのリレーに投稿することができるようにすることができます。または、ハッシュキャッシュやCAPTCHAのようなスパム対策技術を使用することもできます。リレーがスパムベクターとして使用されている場合、クライアントはそのリレーから更新を取得し続けることができず、簡単にリストから外すことができます。 + From 17ed2331e758a952abed9215143c715a81fd9907 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 16:33:35 +0800 Subject: [PATCH 28/77] Update README.md --- "translate/\346\227\245\346\234\254\350\252\236/README.md" | 6 ++++++ 1 file changed, 6 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index f4ffcc1..d639bfa 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -75,3 +75,9 @@ - **スパム** - スパムがリレーの懸念事項である場合、リレーは投稿のための支払いや、メールアドレスや電話番号などの認証形式、または内部的にパブキーに関連付けて、そのリレーに投稿することができるようにすることができます。または、ハッシュキャッシュやCAPTCHAのようなスパム対策技術を使用することもできます。リレーがスパムベクターとして使用されている場合、クライアントはそのリレーから更新を取得し続けることができず、簡単にリストから外すことができます。 +- **データの保存** + - ネットワークが健全であるためには、数百のアクティブなリレーが必要ではありません。実際、既存のリレーが誤動作を始めた場合、新しいリレーが簡単に作成されてネットワークに広がるため、わずかでも十分に機能します。したがって、一般的に必要とされるデータストレージの量は、Mastodonや類似のソフトウェアよりも相対的に少ないです。 + - また、別の結果を考慮すると、アマチュアによって運営される数百のニッチなリレーが存在する場合、各リレーが小さなユーザーグループからの更新を中継するというものがあります。このアーキテクチャも同様にスケーリングされます：データはユーザーから単一のサーバーに送信され、そのサーバーから直接それを消費するユーザーに送信されます。誰かがそれを保存する必要はありません。この状況では、他のユーザーからの更新を処理することは単一のサーバーにとって大きな負担ではなく、アマチュアサーバーを持つことも問題ありません。 + +- **ビデオやその他の重いコンテンツ** + - リレーは大容量のコンテンツを拒否するか、受け入れとホスティングのために料金を請求することが簡単です。情報とインセンティブが明確であれば、市場力が問題を解決することは簡単です。 From ec49f4adac55c6e87ef6f391a75c828045e0f203 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 16:36:52 +0800 Subject: [PATCH 29/77] Update README.md --- .../\346\227\245\346\234\254\350\252\236/README.md" | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index d639bfa..32e3959 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -81,3 +81,12 @@ - **ビデオやその他の重いコンテンツ** - リレーは大容量のコンテンツを拒否するか、受け入れとホスティングのために料金を請求することが簡単です。情報とインセンティブが明確であれば、市場力が問題を解決することは簡単です。 + +- **ユーザーをだますための技術** + - 各クライアントは、ユーザーに投稿を最適に表示する方法を決定できるため、AIを使用して更新の順序を決定することから、時系列順に読むことまで、好きな方法で投稿を消費するオプションが常にあります。 + +## FAQ + +- **これは非常にシンプルです。なぜ以前に誰もやっていないのですか？** + + 私は知りませんが、ソーシャルネットワークを作る人々はお金を稼ぎたい企業またはサーバーなしで完全にものを作りたいP2Pアクティビストのどちらかであるため、Nostrが使用する両方の世界の特定のミックスを見落としています。 From 52525919f0cb3b74824faa56640195b113269a03 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 16:39:54 +0800 Subject: [PATCH 30/77] Update README.md --- .../\346\227\245\346\234\254\350\252\236/README.md" | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index 32e3959..edfb01d 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -90,3 +90,11 @@ - **これは非常にシンプルです。なぜ以前に誰もやっていないのですか？** 私は知りませんが、ソーシャルネットワークを作る人々はお金を稼ぎたい企業またはサーバーなしで完全にものを作りたいP2Pアクティビストのどちらかであるため、Nostrが使用する両方の世界の特定のミックスを見落としています。 + +- **フォローする人をどうやって見つけますか？** + + まず、彼らを知って、どこかで公開鍵を見つける必要があります。それは、尋ねることやどこかで参照されていることがあります。Nostrソーシャルネットワークに入ると、彼らが他の人々と交流しているのを見ることができ、他の人々をフォローして、彼らと交流を始めることもできます。 + +- **中継を見つけるにはどうすればよいですか？他の人と同じ中継に接続されていない場合はどうなりますか？** + + その人と通信することはできません。ただし、イベントに関するヒントがあり、クライアントソフトウェア（または手動で）他の人の中継に接続して彼らとやりとりする方法を知ることができます。将来的には、これを解決するための他のアイデアがありますが、完璧な到達性を保証することはできません。どのプロトコルでもそうです。 From 92b4cd58f3ce58fd512016f093072f5dc5588987 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 16:45:04 +0800 Subject: [PATCH 31/77] Update README.md --- .../README.md" | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git "a/translate/\346\227\245\346\234\254\350\252\236/README.md" "b/translate/\346\227\245\346\234\254\350\252\236/README.md" index edfb01d..3410730 100644 --- "a/translate/\346\227\245\346\234\254\350\252\236/README.md" +++ "b/translate/\346\227\245\346\234\254\350\252\236/README.md" @@ -98,3 +98,27 @@ - **中継を見つけるにはどうすればよいですか？他の人と同じ中継に接続されていない場合はどうなりますか？** その人と通信することはできません。ただし、イベントに関するヒントがあり、クライアントソフトウェア（または手動で）他の人の中継に接続して彼らとやりとりする方法を知ることができます。将来的には、これを解決するための他のアイデアがありますが、完璧な到達性を保証することはできません。どのプロトコルでもそうです。 + +- **私をフォローしている人数を知ることはできますか？** + + いいえ、しかし、リレーが追加のプロトコル方法で協力すれば、いくつかの推定値を得ることができます。 + +- **人々がリレーを実行するための動機は何ですか？** + + この質問は誤解を招くものです。それは、リレーが存在して人々がデータを移動できるようにするための自由なダムパイプであるという前提に基づいています。この場合、はい、動機は存在しません。実際、これはすべての他のP2PネットワークスタックのDHTノードにも言えることです。すなわち、人々がDHTノードを実行する動機は何ですか？ + +- **Nostr は、サーバーリレー間を移動したり、複数のリレーを使用したりすることができますが、これらのリレーが単に AWS や Azure 上にある場合、どのような違いがありますか？** + + 今日は世界中に数千の VPS プロバイダーが点在しており、AWS や Azure だけではありません。AWS や Azure は、スケールが大量に必要な単一の中央集権的なサービスプロバイダーが使用するプロバイダーであり、それ以外にもあります。より小さいリレーサーバーには、どの VPS も非常に適しています。 + +## プロトコル仕様 + +プロトコル仕様の詳細な説明については、[NIP](https://github.com/nostr-protocol/nips)、特に[NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md)を参照してください（ヒント：非常に短くシンプルです）。 + +## ソフトウェア + +Nostr を使用して構築されたほとんどのソフトウェアのリストは、https://github.com/aljazceru/awesome-nostr にあります。最後に確認した時は、ほぼ完全であったようです。 + +## ライセンス + +パブリックドメイン。 From 1edbf3e75262470986e09158e27627497c3c43fb Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:01:54 +0800 Subject: [PATCH 32/77] Update README.md --- "translate/Espa\303\261ol/README.md" | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git "a/translate/Espa\303\261ol/README.md" "b/translate/Espa\303\261ol/README.md" index 6ee909e..0d53a76 100644 --- "a/translate/Espa\303\261ol/README.md" +++ "b/translate/Espa\303\261ol/README.md" @@ -1,2 +1,8 @@ -# nostr - Notas y Otras Cosas Transmitidas por Relevos +# nostr - Notas y Otros Contenidos Transmitidos por Relevos > Notes and Other Stuff Transmitted by Relays + +El protocolo abierto más simple capaz de crear una red "social" global resistente a la censura de una vez por todas. + +No depende de ningún servidor central de confianza, por lo tanto es resistente; se basa en claves y firmas criptográficas, por lo que es a prueba de manipulaciones; no depende de técnicas P2P, y por lo tanto funciona. + +Esto es un trabajo en progreso. [Únete al grupo de Telegram!](https://t.me/nostr_protocol) From ba287572865dd4783b7cd2a24d3387c059b32fa1 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:09:01 +0800 Subject: [PATCH 33/77] Update README.md --- "translate/Espa\303\261ol/README.md" | 39 +++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git "a/translate/Espa\303\261ol/README.md" "b/translate/Espa\303\261ol/README.md" index 0d53a76..f6a74af 100644 --- "a/translate/Espa\303\261ol/README.md" +++ "b/translate/Espa\303\261ol/README.md" @@ -5,4 +5,41 @@ El protocolo abierto más simple capaz de crear una red "social" global resisten No depende de ningún servidor central de confianza, por lo tanto es resistente; se basa en claves y firmas criptográficas, por lo que es a prueba de manipulaciones; no depende de técnicas P2P, y por lo tanto funciona. -Esto es un trabajo en progreso. [Únete al grupo de Telegram!](https://t.me/nostr_protocol) +## Resumen muy breve de cómo funciona, si no planeas leer nada más: + +Todo el mundo ejecuta un cliente. Puede ser un cliente nativo, un cliente web, etc. Para publicar algo, escribes una publicación, la firmas con tu clave y la envías a múltiples relevos (servidores alojados por alguien más, o por ti mismo). Para obtener actualizaciones de otras personas, preguntas a múltiples relevos si saben algo sobre esas otras personas. Cualquiera puede ejecutar un relé. Un relé es muy simple y tonto. No hace nada más que aceptar publicaciones de algunas personas y reenviarlas a otras. Los relevos no tienen que ser confiables. Las firmas se verifican en el lado del cliente. + +[Cómo empezar a usar Nostr](https://github.com/vishalxl/nostr_console/discussions/31) + +[Comparación de características de clientes de Nostr](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Lista de proyectos construidos en Nostr](https://github.com/aljazceru/awesome-nostr) + +## Esto es necesario porque otras soluciones están rotas: + +### El problema con Twitter + +- Twitter tiene anuncios; +- Twitter utiliza técnicas extrañas para mantenerte adicto; +- Twitter no muestra un flujo histórico real de personas que sigues; +- Twitter prohíbe a las personas; +- Twitter hace shadowban a las personas; +- Twitter tiene mucho spam. + +### El problema con Mastodon y programas similares + +- Las identidades de usuario están asociadas con nombres de dominio controlados por terceros; +- Los dueños de los servidores pueden prohibirte, como en Twitter; Los dueños del servidor también pueden bloquear otros servidores; +- La migración entre servidores es una idea secundaria y solo se puede lograr si los servidores cooperan. No funciona en un entorno adversarial (se pierden todos los seguidores). +- No hay incentivos claros para ejecutar servidores, por lo tanto, tienden a ser operados por entusiastas y personas que quieren tener su nombre adjunto a un dominio genial. Luego, los usuarios están sujetos al despotismo de una sola persona, lo que a menudo es peor que el de una gran empresa como Twitter, y no pueden migrar; +- Dado que los servidores tienden a ser operados de manera amateur, a menudo son abandonados después de un tiempo, lo que es efectivamente lo mismo que prohibir a todo el mundo; +- No tiene sentido tener toneladas de servidores si las actualizaciones de cada servidor tendrán que ser dolorosamente empujadas (¡y guardadas!) a toneladas de otros servidores. Este punto se ve exacerbado por el hecho de que los servidores tienden a existir en grandes cantidades, por lo que se debe pasar más datos a más lugares con más frecuencia; +- Para el ejemplo específico de compartir videos, los entusiastas de ActivityPub se dieron cuenta de que sería completamente imposible transmitir videos de servidor a servidor de la misma manera que se hacen las notas de texto, por lo que decidieron mantener el video alojado solo desde la única instancia donde se publicó, lo que es similar al enfoque de Nostr. + +### El problema con SSB (Secure Scuttlebutt) + +- No tiene muchos problemas. Me parece genial. Iba a usarlo como base para esto, pero +- su protocolo es demasiado complicado porque no se pensó en ser un protocolo abierto en absoluto. Simplemente se escribió en JavaScript probablemente de manera rápida para resolver un problema específico y creció a partir de eso, por lo tanto, tiene peculiaridades extrañas e innecesarias como firmar una cadena JSON que debe seguir estrictamente las reglas de [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); +- insiste en tener una cadena de actualizaciones de un solo usuario, lo cual me parece innecesario y algo que agrega inflado y rigidez a la cosa; cada servidor/usuario debe almacenar toda la cadena de publicaciones para estar seguro de que la nueva es válida. ¿Por qué? (Tal vez tengan una buena razón); +- No es tan simple como Nostr, ya que se hizo principalmente para la sincronización P2P, siendo las "pubs" una idea secundaria; +- Aún así, puede valer la pena considerar el uso de SSB en lugar de este protocolo personalizado y simplemente adaptarlo al modelo cliente-relé de servidor, porque reutilizar un estándar siempre es mejor que tratar de hacer que la gente se una a uno nuevo. From 621e766ce7b20e09ff03ac36e36494994bfbcd94 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:17:08 +0800 Subject: [PATCH 34/77] Update README.md --- "translate/Espa\303\261ol/README.md" | 35 ++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git "a/translate/Espa\303\261ol/README.md" "b/translate/Espa\303\261ol/README.md" index f6a74af..47d50c8 100644 --- "a/translate/Espa\303\261ol/README.md" +++ "b/translate/Espa\303\261ol/README.md" @@ -43,3 +43,38 @@ Todo el mundo ejecuta un cliente. Puede ser un cliente nativo, un cliente web, e - insiste en tener una cadena de actualizaciones de un solo usuario, lo cual me parece innecesario y algo que agrega inflado y rigidez a la cosa; cada servidor/usuario debe almacenar toda la cadena de publicaciones para estar seguro de que la nueva es válida. ¿Por qué? (Tal vez tengan una buena razón); - No es tan simple como Nostr, ya que se hizo principalmente para la sincronización P2P, siendo las "pubs" una idea secundaria; - Aún así, puede valer la pena considerar el uso de SSB en lugar de este protocolo personalizado y simplemente adaptarlo al modelo cliente-relé de servidor, porque reutilizar un estándar siempre es mejor que tratar de hacer que la gente se una a uno nuevo. + +## Problemas con otras soluciones que requieren que todos ejecuten su propio servidor + +- Requieren que todos ejecuten su propio servidor; +- A veces, las personas aún pueden ser censuradas en estas soluciones porque los nombres de dominio pueden ser censurados. + +## ¿Cómo funciona Nostr? + +- Hay dos componentes: __clientes__ y __retransmisiones__. Cada usuario ejecuta un cliente. Cualquiera puede ejecutar una retransmisión. +- Cada usuario está identificado por una clave pública. Cada publicación está firmada. Cada cliente valida estas firmas. +- Los clientes recuperan datos de las retransmisiones de su elección y publican datos en otras retransmisiones de su elección. Una retransmisión no habla con otra retransmisión, solo directamente con los usuarios. +- Por ejemplo, para "seguir" a alguien, un usuario simplemente instruye a su cliente que consulte las retransmisiones que conoce para obtener publicaciones de esa clave pública. +- Al iniciarse, un cliente consulta datos de todas las retransmisiones que conoce para todos los usuarios que sigue (por ejemplo, todas las actualizaciones desde el día anterior), luego muestra esos datos al usuario cronológicamente. +- Una "publicación" puede contener cualquier tipo de datos estructurados, pero los más utilizados encontrarán su camino en el estándar para que todos los clientes y retransmisiones puedan manejarlos sin problemas. + +## ¿Cómo resuelve los problemas que las redes anteriores no pueden? + +- **Usuarios baneados y servidores cerrados** + - Un relay puede bloquear a un usuario para publicar en él, pero eso no tiene efecto ya que aún puede publicar en otros relays. Como los usuarios son identificados por una clave pública, no pierden su identidad ni su base de seguidores cuando son baneados. + - En lugar de requerir que los usuarios escriban manualmente nuevas direcciones de relays (aunque también debería ser compatible), cuando alguien que sigues publica una recomendación de servidor, el cliente debe agregar automáticamente eso a la lista de relays que consultará. + - Si alguien está usando un relay para publicar sus datos pero quiere migrar a otro, puede publicar una recomendación de servidor en ese relay anterior y listo. + - Si alguien es baneado de muchos relays de manera que no puede hacer que sus recomendaciones de servidor se transmitan, aún puede informar a algunos amigos cercanos a través de otros medios en qué relay está publicando ahora. Entonces, estos amigos cercanos pueden publicar recomendaciones de servidor a ese nuevo servidor y, lentamente, la antigua base de seguidores del usuario baneado comenzará a encontrar sus publicaciones nuevamente desde el nuevo relay. + - Todo lo anterior también es válido cuando un relay cesa sus operaciones. + +- **Resistencia a la censura** + - Cada usuario puede publicar sus actualizaciones en cualquier cantidad de retransmisiones. + - Una retransmisión puede cobrar una tarifa (la negociación de esa tarifa está fuera del protocolo por ahora) a los usuarios para publicar allí, lo que asegura la resistencia a la censura (siempre habrá algún servidor ruso dispuesto a tomar su dinero a cambio de servir sus publicaciones). + +- **Spam** + - Si el spam es una preocupación para una retransmisión, puede requerir un pago por publicación u otra forma de autenticación, como una dirección de correo electrónico o un teléfono, y asociarlos internamente con una pubkey que luego pueda publicar en esa retransmisión, o utilizar otras técnicas anti-spam, como hashcash o captchas. Si una retransmisión está siendo utilizada como vector de spam, puede ser fácilmente eliminada de la lista por los clientes, que pueden continuar obteniendo actualizaciones de otras retransmisiones. + +- **Almacenamiento de datos** + - Para que la red funcione correctamente, no se necesitan cientos de relays activos. De hecho, puede funcionar perfectamente bien con solo unos pocos, dado que nuevos relays pueden crearse y propagarse fácilmente en la red en caso de que los relays existentes comiencen a comportarse mal. Por lo tanto, la cantidad de almacenamiento de datos requerido, en general, es relativamente menor que en Mastodon u otro software similar. + - O considerando un resultado diferente: uno en el que existen cientos de relays de nicho administrados por aficionados, cada uno transmitiendo actualizaciones de un pequeño grupo de usuarios. La arquitectura también es escalable: los datos se envían desde los usuarios a un servidor único y desde ese servidor directamente a los usuarios que los consumirán. No es necesario que nadie más los almacene. En esta situación, no es una gran carga para ningún servidor procesar actualizaciones de otros, y tener servidores de aficionados no es un problema. + From b2afd23aa2c7c3d99bdf21799b2785eefc42c0d2 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:25:50 +0800 Subject: [PATCH 35/77] Update README.md --- "translate/Espa\303\261ol/README.md" | 43 ++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git "a/translate/Espa\303\261ol/README.md" "b/translate/Espa\303\261ol/README.md" index 47d50c8..17936ab 100644 --- "a/translate/Espa\303\261ol/README.md" +++ "b/translate/Espa\303\261ol/README.md" @@ -78,3 +78,46 @@ Todo el mundo ejecuta un cliente. Puede ser un cliente nativo, un cliente web, e - Para que la red funcione correctamente, no se necesitan cientos de relays activos. De hecho, puede funcionar perfectamente bien con solo unos pocos, dado que nuevos relays pueden crearse y propagarse fácilmente en la red en caso de que los relays existentes comiencen a comportarse mal. Por lo tanto, la cantidad de almacenamiento de datos requerido, en general, es relativamente menor que en Mastodon u otro software similar. - O considerando un resultado diferente: uno en el que existen cientos de relays de nicho administrados por aficionados, cada uno transmitiendo actualizaciones de un pequeño grupo de usuarios. La arquitectura también es escalable: los datos se envían desde los usuarios a un servidor único y desde ese servidor directamente a los usuarios que los consumirán. No es necesario que nadie más los almacene. En esta situación, no es una gran carga para ningún servidor procesar actualizaciones de otros, y tener servidores de aficionados no es un problema. +- **Video y otro contenido pesado** + - Es fácil para un relay rechazar contenido grande o cobrar por aceptar y alojar contenido grande. Cuando la información y los incentivos son claros, es fácil para las fuerzas del mercado resolver el problema. + +- **Técnicas para engañar al usuario** + - Cada cliente puede decidir cómo mostrar mejor las publicaciones a los usuarios, por lo que siempre está la opción de consumir solo lo que desee de la manera que desee, desde usar una inteligencia artificial para decidir el orden de las actualizaciones que verá hasta simplemente leerlas en orden cronológico. + +## Preguntas frecuentes + +- **Esto es muy simple. ¿Por qué nadie lo ha hecho antes?** + + No lo sé, pero imagino que tiene que ver con el hecho de que las personas que crean redes sociales son empresas que quieren ganar dinero o activistas P2P que quieren hacer una cosa completamente sin servidores. Ambos no ven la mezcla específica de ambos mundos que utiliza Nostr. + +- **¿Cómo encuentro personas a las que seguir?** + + Primero, debes conocerlas y obtener su clave pública de alguna manera, ya sea preguntándoles o viéndola referenciada en algún lugar. Una vez que estás dentro de una red social de Nostr, podrás verlas interactuando con otras personas y así también puedes empezar a seguir e interactuar con estos otros. + +- **¿Cómo encuentro relays? ¿Qué sucede si no estoy conectado a los mismos relays que alguien más?** + + No podrás comunicarte con esa persona. Pero hay pistas en eventos que se pueden utilizar para que tu software cliente (o tú manualmente) sepa cómo conectarse al relay de la otra persona e interactuar con ella. Hay otras ideas sobre cómo resolver esto en el futuro, pero nunca podemos prometer una accesibilidad perfecta, ningún protocolo puede hacerlo. + +- **¿Puedo saber cuántas personas me siguen?** + + No, pero puedes obtener algunas estimaciones si los relays cooperan de manera extra-protocolo. + +- **¿Qué incentivo hay para que la gente ejecute relays?** + + La pregunta es engañosa. Parte de la premisa de que los relays son tuberías tontas gratuitas que existen para que la gente pueda mover datos a través de ellas. En este caso, es cierto que no habría incentivos. Esto podría decirse de los nodos DHT en todas las otras pilas de redes p2p: ¿qué incentivo hay para que la gente ejecute nodos DHT? + +- **Nostr te permite moverte entre los relays del servidor o usar múltiples relays, pero si estos relays están en AWS o Azure, ¿cuál es la diferencia?** + + Literalmente hay miles de proveedores de VPS repartidos por todo el mundo hoy en día, no solo AWS o Azure. AWS o Azure son precisamente los proveedores utilizados por los proveedores de servicios centralizados únicos que necesitan mucha escala, y aun así no solo estos dos. Para los servidores de relay más pequeños, cualquier VPS hará perfectamente el trabajo. + +## Especificación del protocolo + +Consulte los [NIPs](https://github.com/nostr-protocol/nips) y especialmente [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) para obtener una explicación razonablemente detallada de la especificación del protocolo (pista: es muy corta y simple). + +## Software + +Hay una lista de la mayoría del software que se está construyendo utilizando Nostr en https://github.com/aljazceru/awesome-nostr que parecía estar casi completa la última vez que lo miré. + +## Licencia + +Dominio público. From 31dbf5e2f80bd402cfd04243ed8035355ed213cf Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:29:18 +0800 Subject: [PATCH 36/77] Update README.md --- translate/README.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/translate/README.md b/translate/README.md index abb5e2e..38103f8 100644 --- a/translate/README.md +++ b/translate/README.md @@ -1 +1,7 @@ Translate content into other languages + +- [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) + +- [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) + +- [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) From 2975f1cbb9e1a3c5da8e139c4b098e2bf1645ab6 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:32:23 +0800 Subject: [PATCH 37/77] Update README.md --- translate/README.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/translate/README.md b/translate/README.md index 38103f8..e726f79 100644 --- a/translate/README.md +++ b/translate/README.md @@ -1,7 +1,5 @@ Translate content into other languages -- [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) - -- [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) - -- [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) +| Japanese | Chinese | Spanish | +| -------- | -------- | -------- | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | From d1342a800498d54d3515f9c13f2aee8bd5f6562f Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:33:29 +0800 Subject: [PATCH 38/77] Update README.md --- translate/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/README.md b/translate/README.md index e726f79..b96e2a7 100644 --- a/translate/README.md +++ b/translate/README.md @@ -1,4 +1,4 @@ -Translate content into other languages +Content in other languages | Japanese | Chinese | Spanish | | -------- | -------- | -------- | From c766530ba90321fabe883de9c4c355b186b4e3a4 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:57:01 +0800 Subject: [PATCH 39/77] Update README.md --- "translate/Fran\303\247ais/README.md" | 71 +++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) diff --git "a/translate/Fran\303\247ais/README.md" "b/translate/Fran\303\247ais/README.md" index 04e6568..55a2c7f 100644 --- "a/translate/Fran\303\247ais/README.md" +++ "b/translate/Fran\303\247ais/README.md" @@ -1,2 +1,73 @@ # nostr - Notes et Autres Choses Transmises par Relais > Notes and Other Stuff Transmitted by Relays + +# nostr - Notes et autres éléments transmis par relais + +Le protocole ouvert le plus simple capable de créer un réseau social mondial résistant à la censure une fois pour toutes. + +Il ne dépend d'aucun serveur central de confiance, donc il est résilient ; il est basé sur des clés et des signatures cryptographiques, donc il est inviolable ; il ne dépend pas des techniques P2P, donc il fonctionne. + +Ceci est un travail en cours. [Rejoignez le groupe Telegram !](https://t.me/nostr_protocol) + +## Résumé très court du fonctionnement, si vous ne prévoyez pas de lire quoi que ce soit d'autre : + +Tout le monde exécute un client. Il peut s'agir d'un client natif, d'un client web, etc. Pour publier quelque chose, vous écrivez un post, vous le signez avec votre clé et vous l'envoyez à plusieurs relais (des serveurs hébergés par quelqu'un d'autre, ou vous-même). Pour obtenir des mises à jour des autres personnes, vous demandez à plusieurs relais s'ils savent quelque chose à propos de ces autres personnes. Tout le monde peut exécuter un relais. Un relais est très simple et stupide. Il ne fait rien d'autre qu'accepter des publications de certaines personnes et les transmettre à d'autres. Les relais n'ont pas besoin d'être dignes de confiance. Les signatures sont vérifiées côté client. + +[Comment commencer à utiliser Nostr](https://github.com/vishalxl/nostr_console/discussions/31) + +[Comparaison des fonctionnalités des clients Nostr](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Liste de projets construits sur Nostr](https://github.com/aljazceru/awesome-nostr) + +## Ceci est nécessaire car d'autres solutions sont cassées : + +### Le problème avec Twitter + +- Twitter a des publicités ; +- Twitter utilise des techniques étranges pour vous rendre accro ; +- Twitter ne montre pas un flux historique réel des personnes que vous suivez ; +- Twitter interdit des personnes ; +- Twitter met des personnes en "shadowban" ; +- Twitter a beaucoup de spam. + +### Le problème avec Mastodon et programmes similaires + +- Les identités d'utilisateurs sont attachées à des noms de domaine contrôlés par des tiers ; +- Les propriétaires de serveurs peuvent vous interdire, tout comme Twitter ; Les propriétaires de serveurs peuvent également bloquer d'autres serveurs ; +- La migration entre serveurs est une réflexion après coup et ne peut être réalisée que si les serveurs coopèrent. Cela ne fonctionne pas dans un environnement hostile (tous les abonnés sont perdus) ; +- Il n'y a pas d'incitations claires à exploiter des serveurs, donc ils ont tendance à être exploités par des enthousiastes et des personnes qui veulent avoir leur nom attaché à un domaine cool. Ensuite, les utilisateurs sont soumis au despotisme d'une seule personne, qui est souvent pire que celui d'une grande entreprise comme Twitter, et ils ne peuvent pas migrer ; +- Comme les serveurs ont tendance à être exploités de manière amateur, ils sont souvent abandonnés après un certain temps - ce qui revient effectivement à interdire à tout le monde ; +- Il n'a pas de sens d'avoir une tonne de serveurs si les mises à jour de chaque serveur doivent être poussées (et sauvegardées !) douloureusement vers une tonne d'autres serveurs. Ce point est exacerbé par le fait que les serveurs ont tendance à exister en grand nombre, donc plus de données doivent être transmises à plus d'endroits plus souvent ; +- Pour l'exemple spécifique du partage de vidéos, les enthousiastes d'ActivityPub ont réalisé qu'il serait complètement impossible de transmettre des vidéos de serveur à serveur de la même manière que les notes textuelles, donc ils ont décidé de garder la vidéo hébergée uniquement à partir de l'instance unique où elle a été postée, ce qui est similaire à l'approche de Nostr. + +### Le problème avec SSB (Secure Scuttlebutt) + +- Il n'a pas beaucoup de problèmes. Je pense que c'est génial. J'allais l'utiliser comme base pour cela, mais +- son protocole est trop compliqué car il n'a pas été conçu comme un protocole ouvert du tout. Il a simplement été écrit en JavaScript probablement de manière rapide pour résoudre un problème spécifique et a grandi à partir de cela, donc il a des bizarreries étranges et inutiles comme la signature d'une chaîne JSON qui doit strictement suivre les règles de [_ECMA-262 6ème édition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); +- Il insiste sur le fait d'avoir une chaîne de mises à jour d'un seul utilisateur, ce qui me semble inutile et quelque chose qui ajoute de l'encombrement et de la rigidité à la chose - chaque serveur/utilisateur doit stocker toute la chaîne de publications pour être sûr que la nouvelle est valide. Pourquoi ? (Peut-être ont-ils une bonne raison); +- Ce n'est pas aussi simple que Nostr, car il a été principalement conçu pour la synchronisation P2P, avec des "pubs" étant une réflexion après coup ; +- Néanmoins, il peut être intéressant de considérer l'utilisation de SSB au lieu de ce protocole personnalisé et simplement de l'adapter au modèle client-relais serveur, car la réutilisation d'une norme est toujours meilleure que d'essayer de faire adopter une nouvelle norme. + +### Le problème avec d'autres solutions qui nécessitent que tout le monde exécute son propre serveur + +- Ils nécessitent que tout le monde exécute son propre serveur ; +- Parfois, les gens peuvent encore être censurés dans ces solutions car les noms de domaine peuvent être censurés. + +## Comment fonctionne Nostr ? + +- Il y a deux composants: __clients__ et __relais__. Chaque utilisateur exécute un client. Tout le monde peut exécuter un relais. +- Chaque utilisateur est identifié par une clé publique. Chaque publication est signée. Chaque client valide ces signatures. +- Les clients récupèrent des données à partir des relais de leur choix et publient des données à d'autres relais de leur choix. Un relais ne communique pas avec un autre relais, seulement directement avec les utilisateurs. +- Par exemple, pour "suivre" quelqu'un, un utilisateur indique simplement à son client de rechercher les publications à partir de cette clé publique dans les relais qu'il connaît. +- Au démarrage, un client interroge tous les relais qu'il connaît pour tous les utilisateurs qu'il suit (par exemple, toutes les mises à jour depuis le dernier jour), puis affiche ces données à l'utilisateur de manière chronologique. +- Une "publication" peut contenir n'importe quel type de données structurées, mais les plus utilisées vont trouver leur place dans la norme de sorte que tous les clients et relais peuvent les gérer de manière transparente. + +## Comment résout-il les problèmes que les réseaux ci-dessus ne peuvent pas résoudre ? + +- **Utilisateurs bannis et serveurs fermés** + - Un relais peut bloquer un utilisateur de publier quoi que ce soit là-bas, mais cela n'a aucun effet sur eux car ils peuvent toujours publier sur d'autres relais. Comme les utilisateurs sont identifiés par une clé publique, ils ne perdent pas leur identité et leur base de suiveurs lorsqu'ils sont bannis. + - Au lieu d'exiger des utilisateurs qu'ils saisissent manuellement de nouvelles adresses de relais (bien que cela devrait également être pris en charge), chaque fois que quelqu'un que vous suivez publie une recommandation de serveur, le client devrait automatiquement l'ajouter à la liste des relais qu'il interrogera. + - Si quelqu'un utilise un relais pour publier ses données mais veut migrer vers un autre, il peut publier une recommandation de serveur à ce relais précédent et partir ; + - Si quelqu'un est banni de nombreux relais de sorte qu'il ne peut pas faire diffuser ses recommandations de serveur, il peut toujours informer quelques amis proches par d'autres moyens sur le relais sur lequel il publie maintenant. Ensuite, ces amis proches peuvent publier des recommandations de serveur vers ce nouveau serveur, et lentement, l'ancienne base de suiveurs de l'utilisateur banni commencera à trouver ses publications à nouveau depuis le nouveau relais. + - Tout ce qui précède est également valable lorsque qu'un relais cesse ses opérations. + From 686eaa1ece68d1e6a230a5e1d1923cd160deab8d Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 17:57:22 +0800 Subject: [PATCH 40/77] Update README.md --- "translate/Fran\303\247ais/README.md" | 2 -- 1 file changed, 2 deletions(-) diff --git "a/translate/Fran\303\247ais/README.md" "b/translate/Fran\303\247ais/README.md" index 55a2c7f..07fc7ce 100644 --- "a/translate/Fran\303\247ais/README.md" +++ "b/translate/Fran\303\247ais/README.md" @@ -1,8 +1,6 @@ # nostr - Notes et Autres Choses Transmises par Relais > Notes and Other Stuff Transmitted by Relays -# nostr - Notes et autres éléments transmis par relais - Le protocole ouvert le plus simple capable de créer un réseau social mondial résistant à la censure une fois pour toutes. Il ne dépend d'aucun serveur central de confiance, donc il est résilient ; il est basé sur des clés et des signatures cryptographiques, donc il est inviolable ; il ne dépend pas des techniques P2P, donc il fonctionne. From 117069347d48c5a969d59e9935355de65aa5cf6b Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 18:03:01 +0800 Subject: [PATCH 41/77] Update README.md --- "translate/Fran\303\247ais/README.md" | 43 +++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git "a/translate/Fran\303\247ais/README.md" "b/translate/Fran\303\247ais/README.md" index 07fc7ce..e2bd63d 100644 --- "a/translate/Fran\303\247ais/README.md" +++ "b/translate/Fran\303\247ais/README.md" @@ -69,3 +69,46 @@ Tout le monde exécute un client. Il peut s'agir d'un client natif, d'un client - Si quelqu'un est banni de nombreux relais de sorte qu'il ne peut pas faire diffuser ses recommandations de serveur, il peut toujours informer quelques amis proches par d'autres moyens sur le relais sur lequel il publie maintenant. Ensuite, ces amis proches peuvent publier des recommandations de serveur vers ce nouveau serveur, et lentement, l'ancienne base de suiveurs de l'utilisateur banni commencera à trouver ses publications à nouveau depuis le nouveau relais. - Tout ce qui précède est également valable lorsque qu'un relais cesse ses opérations. +- **Résistance à la censure** + - Chaque utilisateur peut publier ses mises à jour sur un nombre quelconque de relais. + - Un relais peut facturer des frais (la négociation de ces frais est actuellement en dehors du protocole) aux utilisateurs pour publier sur le relais, ce qui garantit la résistance à la censure (il y aura toujours un serveur russe prêt à prendre votre argent en échange de la diffusion de vos publications). + +- **Spam** + - Si le spam est une préoccupation pour un relais, il peut exiger un paiement pour la publication ou une autre forme d'authentification, comme une adresse e-mail ou un numéro de téléphone, et les associer internement avec une clé publique qui sera autorisée à publier sur ce relais - ou d'autres techniques anti-spam, comme hashcash ou des captchas. Si un relais est utilisé comme vecteur de spam, il peut facilement être retiré de la liste des clients, qui peuvent continuer à récupérer des mises à jour à partir d'autres relais. + +- **Stockage de données** + - Pour que le réseau reste sain, il n'est pas nécessaire d'avoir des centaines de relais actifs. En fait, il peut fonctionner parfaitement avec seulement quelques-uns, étant donné que de nouveaux relais peuvent être créés et diffusés facilement dans le réseau au cas où les relais existants commenceraient à mal fonctionner. Par conséquent, la quantité de stockage de données requise, en général, est relativement moins importante que celle de Mastodon ou de logiciels similaires. + - Ou en envisageant un résultat différent: celui où il existe des centaines de relais de niche gérés par des amateurs, chacun relayant les mises à jour d'un petit groupe d'utilisateurs. L'architecture fonctionne tout aussi bien: les données sont envoyées des utilisateurs à un seul serveur, et de ce serveur directement aux utilisateurs qui les consommeront. Elles ne doivent pas être stockées par quelqu'un d'autre. Dans cette situation, ce n'est pas un gros fardeau pour un seul serveur de traiter les mises à jour des autres, et avoir des serveurs amateurs n'est pas un problème. + +- **Vidéos et autres contenus lourds** + - Il est facile pour un relais de rejeter les contenus volumineux ou de facturer leur acceptation et leur hébergement. Lorsque les informations et les incitations sont claires, il est facile pour les forces du marché de résoudre le problème. + +- **Techniques pour tromper l'utilisateur** + - Chaque client peut décider de la meilleure façon de présenter les publications aux utilisateurs, de sorte qu'il y a toujours la possibilité de ne consommer que ce que vous voulez de la manière que vous souhaitez, que ce soit en utilisant une IA pour décider de l'ordre des mises à jour que vous verrez ou en les lisant simplement dans l'ordre chronologique. + +## FAQ + +- **C'est très simple. Pourquoi personne ne l'a fait auparavant ?** + + Je ne sais pas, mais j'imagine que cela a à voir avec le fait que les personnes qui créent des réseaux sociaux sont soit des entreprises qui veulent gagner de l'argent, soit des militants P2P qui veulent créer une chose complètement sans serveurs. Ils ne parviennent pas à voir le mélange spécifique des deux mondes qu'utilise Nostr. + +- **Comment trouver des personnes à suivre ?** + + Tout d'abord, vous devez les connaître et obtenir leur clé publique, soit en demandant soit en la voyant quelque part. Une fois que vous êtes à l'intérieur d'un réseau social Nostr, vous pourrez les voir interagir avec d'autres personnes et vous pourrez alors commencer à suivre et à interagir avec ces autres. + +- **Comment trouver des relais ? Que se passe-t-il si je ne suis pas connecté aux mêmes relais que quelqu'un d'autre ?** + + Vous ne pourrez pas communiquer avec cette personne. Mais il y a des indices sur des événements qui peuvent être utilisés pour que votre logiciel client (ou vous, manuellement) sache comment se connecter au relais de l'autre personne et interagir avec elle. Il y a d'autres idées sur la façon de résoudre cela dans le futur, mais nous ne pouvons jamais promettre une accessibilité parfaite, aucun protocole ne peut le garantir. + +- **Puis-je savoir combien de personnes me suivent ?** + + Non, mais vous pouvez obtenir des estimations si les relais coopèrent d'une manière extra-protocolaire. + +- **Quel est l'incitatif pour les gens de faire fonctionner des relais ?** + + La question est trompeuse. Elle suppose que les relais sont des tuyaux muets gratuits qui existent pour que les gens puissent déplacer des données à travers eux. Dans ce cas, oui, les incitations n'existeraient pas. Cela pourrait en fait être dit des nœuds DHT dans toutes les autres piles de réseaux p2p : quel est l'incitatif pour les gens de faire fonctionner des nœuds DHT ? + +- **Nostr vous permet de passer d'un relais à un autre ou d'utiliser plusieurs relais, mais s'ils sont simplement sur AWS ou Azure, quelle est la différence ?** + + Il y a littéralement des milliers de fournisseurs de VPS dispersés partout dans le monde aujourd'hui, il n'y a pas seulement AWS ou Azure. AWS ou Azure sont exactement les fournisseurs utilisés par les fournisseurs de services centralisés uniques qui ont besoin d'une grande échelle, et même alors, pas seulement ces deux-là. Pour les serveurs de relais plus petits, n'importe quel VPS fera très bien l'affaire. + From ae0d0f58595729f77c59c75994a36c89f6bd091b Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 18:04:55 +0800 Subject: [PATCH 42/77] Update README.md --- "translate/Fran\303\247ais/README.md" | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git "a/translate/Fran\303\247ais/README.md" "b/translate/Fran\303\247ais/README.md" index e2bd63d..caf3154 100644 --- "a/translate/Fran\303\247ais/README.md" +++ "b/translate/Fran\303\247ais/README.md" @@ -112,3 +112,14 @@ Tout le monde exécute un client. Il peut s'agir d'un client natif, d'un client Il y a littéralement des milliers de fournisseurs de VPS dispersés partout dans le monde aujourd'hui, il n'y a pas seulement AWS ou Azure. AWS ou Azure sont exactement les fournisseurs utilisés par les fournisseurs de services centralisés uniques qui ont besoin d'une grande échelle, et même alors, pas seulement ces deux-là. Pour les serveurs de relais plus petits, n'importe quel VPS fera très bien l'affaire. +## Spécification du protocole + +Voir les [NIPs](https://github.com/nostr-protocol/nips) et en particulier [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) pour une explication raisonnablement détaillée de la spécification du protocole (indice: elle est très courte et simple). + +## Logiciel + +Il y a une liste de la plupart des logiciels construits en utilisant Nostr sur https://github.com/aljazceru/awesome-nostr qui semblait être presque complète la dernière fois que j'ai regardé. + +## Licence + +Domaine public. From 64bbb818d42ef85747d4a0c29c6f44b03e4bc8d7 Mon Sep 17 00:00:00 2001 From: Eugene Date: Tue, 21 Mar 2023 18:06:40 +0800 Subject: [PATCH 43/77] Update README.md --- translate/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/translate/README.md b/translate/README.md index b96e2a7..c01f93f 100644 --- a/translate/README.md +++ b/translate/README.md @@ -1,5 +1,5 @@ Content in other languages -| Japanese | Chinese | Spanish | -| -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | +| Japanese | Chinese | Spanish | French | +| -------- | -------- | -------- | -------- | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | From d0f9d1d3439a0ebabd743b8a3675fb96d090c017 Mon Sep 17 00:00:00 2001 From: Eugene Date: Wed, 22 Mar 2023 14:49:20 +0800 Subject: [PATCH 44/77] Update README.md --- translate/Deutsch/README.md | 52 ++++++++++++++++++++++++++++++++++++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/translate/Deutsch/README.md b/translate/Deutsch/README.md index 500867a..e047e34 100644 --- a/translate/Deutsch/README.md +++ b/translate/Deutsch/README.md @@ -1,2 +1,52 @@ -# nostr - Notizen und Andere Dinge, die per Relais Übertragen Werden +# nostr - Notizen und Anderes Zeug, Übertragen durch Relais > Notes and Other Stuff Transmitted by Relays + +Das einfachste offene Protokoll, das in der Lage ist, ein zensurresistentes globales "soziales" Netzwerk ein für allemal zu erschaffen. + +Es stützt sich nicht auf einen vertrauenswürdigen zentralen Server, daher ist es belastbar; es basiert auf kryptographischen Schlüsseln und Signaturen, daher ist es manipulationssicher; es verlässt sich nicht auf P2P-Techniken, und deshalb funktioniert es. + +Dies ist eine laufende Arbeit. [Tritt der Telegram-Gruppe bei!](https://t.me/nostr_protocol) + +## Sehr kurze Zusammenfassung, wie es funktioniert, falls du nichts anderes lesen möchtest: + +Jeder führt einen Client aus. Es kann ein nativer Client, ein Web-Client usw. sein. Um etwas zu veröffentlichen, schreibst du einen Beitrag, signierst ihn mit deinem Schlüssel und sendest ihn an mehrere Relais (Server, die von jemand anderem oder dir selbst gehostet werden). Um Updates von anderen Personen zu erhalten, fragst du mehrere Relais, ob sie etwas über diese anderen Personen wissen. Jeder kann ein Relais betreiben. Ein Relais ist sehr einfach und dumm. Es macht nichts anderes, als Beiträge von einigen Personen zu akzeptieren und an andere weiterzuleiten. Relais müssen nicht vertrauenswürdig sein. Signaturen werden auf der Client-Seite überprüft. + +[Wie man Nostr verwendet](https://github.com/vishalxl/nostr_console/discussions/31) + +[Nostr-Client-Funktionsvergleich](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Liste der Projekte, die auf Nostr aufbauen](https://github.com/aljazceru/awesome-nostr) + +## Dies ist notwendig, weil andere Lösungen nicht funktionieren: + +### Das Problem mit Twitter + +- Twitter hat Werbung; +- Twitter verwendet bizarre Techniken, um dich süchtig zu halten; +- Twitter zeigt keinen tatsächlichen chronologischen Feed von Personen, denen du folgst; +- Twitter sperrt Personen; +- Twitter schattensperrt Personen; +- Twitter hat viel Spam. + +### Das Problem mit Mastodon und ähnlichen Programmen + +- Benutzeridentitäten sind an Domainnamen gebunden, die von Dritten kontrolliert werden; +- Serverbesitzer können dich sperren, genau wie bei Twitter; Serverbesitzer können auch andere Server blockieren; +- Die Migration zwischen Servern ist ein nachträglicher Gedanke und kann nur erreicht werden, wenn die Server zusammenarbeiten. Es funktioniert nicht in einer feindlichen Umgebung (alle Follower gehen verloren); +- Es gibt keine klaren Anreize, Server zu betreiben, daher werden sie oft von Enthusiasten und Menschen betrieben, die ihren Namen mit einer coolen Domain verbinden wollen. Dann sind die Benutzer dem Despotismus einer einzelnen Person ausgesetzt, der oft schlimmer ist als der eines großen Unternehmens wie Twitter, und sie können nicht auswandern; +- Da die Server oft laienhaft betrieben werden, werden sie nach einer Weile häufig aufgegeben - was faktisch einer Sperrung aller Benutzer gleichkommt; +- Es macht keinen Sinn, eine Unmenge von Servern zu haben, wenn Updates von jedem Server mühsam an eine Unmenge anderer Server gepusht (und gespeichert!) werden müssen. Dieser Punkt wird verschärft durch die Tatsache, dass Server in großen Mengen vorhanden sind, daher müssen mehr Daten häufiger an mehr Orte übertragen werden; +- Im speziellen Beispiel der Videofreigabe erkannten die ActivityPub-Enthusiasten, dass es völlig unmöglich wäre, Videos von Server zu Server zu übertragen, wie es bei Textnotizen der Fall ist. Daher beschlossen sie, das Video nur von der einzelnen Instanz zu hosten, auf der es veröffentlicht wurde, was dem Nostr-Ansatz ähnelt. + +### Das Problem mit SSB (Secure Scuttlebutt) + +- Es hat nicht viele Probleme. Ich finde es großartig. Ich wollte es als Basis dafür verwenden, aber +- das Protokoll ist zu kompliziert, weil es gar nicht als offenes Protokoll gedacht war. Es wurde einfach in JavaScript geschrieben, wahrscheinlich um schnell ein spezifisches Problem zu lösen, und wuchs von dort aus. Daher hat es seltsame und unnötige Eigenheiten wie das Signieren eines JSON-Strings, der streng den Regeln von [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify) folgen muss; +- Es besteht darauf, eine Kette von Updates von einem einzelnen Benutzer zu haben, was mir unnötig erscheint und etwas, das Aufgeblähtes und Starrheit hinzufügt - jeder Server/Benutzer muss die gesamte Kette von Beiträgen speichern, um sicherzustellen, dass der neue gültig ist. Warum? (Vielleicht haben sie einen guten Grund); +- Es ist nicht so einfach wie Nostr, da es hauptsächlich für P2P-Synchronisation entwickelt wurde, wobei "Pubs" ein nachträglicher Gedanke waren; +- Dennoch könnte es sich lohnen, SSB anstelle dieses benutzerdefinierten Protokolls zu verwenden und es einfach an das Client-Relay-Server-Modell anzupassen, weil die Wiederverwendung eines Standards immer besser ist, als zu versuchen, die Leute in einen neuen zu bringen. + +### Das Problem mit anderen Lösungen, die von jedem verlangen, ihren eigenen Server zu betreiben + +- Sie erfordern, dass jeder seinen eigenen Server betreibt; +- Manchmal können Menschen trotzdem zensiert werden, weil Domainnamen zensiert werden können. From def45ae7e70ee301fc294641df6f580d9aa5ea19 Mon Sep 17 00:00:00 2001 From: Eugene Date: Wed, 22 Mar 2023 14:55:23 +0800 Subject: [PATCH 45/77] Update README.md --- translate/Deutsch/README.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/translate/Deutsch/README.md b/translate/Deutsch/README.md index e047e34..d2920f3 100644 --- a/translate/Deutsch/README.md +++ b/translate/Deutsch/README.md @@ -50,3 +50,33 @@ Jeder führt einen Client aus. Es kann ein nativer Client, ein Web-Client usw. s - Sie erfordern, dass jeder seinen eigenen Server betreibt; - Manchmal können Menschen trotzdem zensiert werden, weil Domainnamen zensiert werden können. + +## Wie funktioniert Nostr? + +- Es gibt zwei Komponenten: __Clients__ und __Relais__. Jeder Benutzer führt einen Client aus. Jeder kann ein Relais betreiben. +- Jeder Benutzer wird durch einen öffentlichen Schlüssel identifiziert. Jeder Beitrag ist signiert. Jeder Client validiert diese Signaturen. +- Clients holen Daten von Relais ihrer Wahl und veröffentlichen Daten auf anderen Relais ihrer Wahl. Ein Relais kommuniziert nicht mit einem anderen Relais, sondern nur direkt mit Benutzern. +- Um zum Beispiel jemandem zu "folgen", weist ein Benutzer seinen Client einfach an, die ihm bekannten Relais nach Beiträgen von diesem öffentlichen Schlüssel zu durchsuchen. +- Beim Start fragt ein Client Daten von allen Relais ab, die er kennt, für alle Benutzer, denen er folgt (zum Beispiel alle Updates vom letzten Tag), und zeigt diese Daten dem Benutzer chronologisch an. +- Ein "Beitrag" kann jede Art von strukturierten Daten enthalten, aber die am häufigsten verwendeten werden in den Standard aufgenommen, damit alle Clients und Relais sie nahtlos verarbeiten können. + +## Wie löst es die Probleme, die die oben genannten Netzwerke nicht lösen können? + +- **Benutzer werden gesperrt und Server geschlossen** + - Ein Relais kann einen Benutzer daran hindern, dort etwas zu veröffentlichen, aber das hat keine Auswirkungen auf ihn, da er immer noch auf anderen Relais veröffentlichen kann. Da Benutzer durch einen öffentlichen Schlüssel identifiziert werden, verlieren sie nicht ihre Identität und ihre Follower-Basis, wenn sie gesperrt werden. + - Anstatt von Benutzern zu verlangen, manuell neue Relaisadressen einzugeben (obwohl dies auch unterstützt werden sollte), sollte der Client automatisch eine Serverempfehlung zur Liste der abzufragenden Relais hinzufügen, wenn jemand, dem Sie folgen, eine Serverempfehlung veröffentlicht. + - Wenn jemand ein Relais zum Veröffentlichen seiner Daten verwendet, aber zu einem anderen wechseln möchte, kann er eine Serverempfehlung an das vorherige Relais veröffentlichen und gehen; + - Wenn jemand von so vielen Relais gesperrt wird, dass er seine Serverempfehlungen nicht mehr verbreiten kann, kann er trotzdem einige enge Freunde auf anderem Wege darüber informieren, auf welchem Relais er jetzt veröffentlicht. Diese engen Freunde können dann Serverempfehlungen zu diesem neuen Server veröffentlichen, und langsam wird die alte Follower-Basis des gesperrten Benutzers wieder Beiträge von dem neuen Relais finden. + - All dies gilt auch, wenn ein Relais seinen Betrieb einstellt. + +- **Zensurresistenz** + - Jeder Benutzer kann seine Updates auf beliebig vielen Relais veröffentlichen. + - Ein Relais kann eine Gebühr verlangen (die Verhandlung dieser Gebühr liegt vorerst außerhalb des Protokolls) von Benutzern, um dort zu veröffentlichen, was die Zensurresistenz sicherstellt (es wird immer einen russischen Server geben, der bereit ist, Ihr Geld im Austausch für das Bereitstellen Ihrer Beiträge zu nehmen). + +- **Spam** + - Wenn Spam für ein Relais ein Problem ist, kann es eine Zahlung für die Veröffentlichung oder eine andere Form der Authentifizierung verlangen, wie zum Beispiel eine E-Mail-Adresse oder Telefonnummer, und diese intern mit einem Pubkey verknüpfen, der dann auf diesem Relais veröffentlichen darf – oder andere Anti-Spam-Techniken wie Hashcash oder Captchas. Wenn ein Relais als Spam-Vektor verwendet wird, kann es leicht von Clients von der Liste genommen werden, die weiterhin Updates von anderen Relais abrufen können. + +- **Datenspeicherung** + - Damit das Netzwerk gesund bleibt, ist es nicht notwendig, Hunderte von aktiven Relais zu haben. Tatsächlich kann es auch mit nur einer Handvoll funktionieren, da neue Relais leicht erstellt und im Netzwerk verbreitet werden können, falls die vorhandenen Relais anfangen, sich schlecht zu verhalten. Daher ist der allgemeine Bedarf an Datenspeicherung im Vergleich zu Mastodon oder ähnlicher Software relativ gering. + - Oder betrachten wir ein anderes Szenario: eines, in dem es Hunderte von Nischenrelais gibt, die von Amateuren betrieben werden und jeweils Updates von einer kleinen Gruppe von Benutzern weiterleiten. Die Architektur skaliert genauso gut: Daten werden von Benutzern an einen einzelnen Server gesendet und von diesem Server direkt an die Benutzer, die diese Daten konsumieren werden. Es muss von niemand anderem gespeichert werden. In dieser Situation ist es für keinen einzelnen Server eine große Belastung, Updates von anderen zu verarbeiten, und das Vorhandensein von Amateurservern ist kein Problem. + From 199a435c387982312fd9fb8202f7bfe87b78ad4f Mon Sep 17 00:00:00 2001 From: Eugene Date: Wed, 22 Mar 2023 14:58:16 +0800 Subject: [PATCH 46/77] Update README.md --- translate/Deutsch/README.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/translate/Deutsch/README.md b/translate/Deutsch/README.md index d2920f3..9d1f951 100644 --- a/translate/Deutsch/README.md +++ b/translate/Deutsch/README.md @@ -80,3 +80,28 @@ Jeder führt einen Client aus. Es kann ein nativer Client, ein Web-Client usw. s - Damit das Netzwerk gesund bleibt, ist es nicht notwendig, Hunderte von aktiven Relais zu haben. Tatsächlich kann es auch mit nur einer Handvoll funktionieren, da neue Relais leicht erstellt und im Netzwerk verbreitet werden können, falls die vorhandenen Relais anfangen, sich schlecht zu verhalten. Daher ist der allgemeine Bedarf an Datenspeicherung im Vergleich zu Mastodon oder ähnlicher Software relativ gering. - Oder betrachten wir ein anderes Szenario: eines, in dem es Hunderte von Nischenrelais gibt, die von Amateuren betrieben werden und jeweils Updates von einer kleinen Gruppe von Benutzern weiterleiten. Die Architektur skaliert genauso gut: Daten werden von Benutzern an einen einzelnen Server gesendet und von diesem Server direkt an die Benutzer, die diese Daten konsumieren werden. Es muss von niemand anderem gespeichert werden. In dieser Situation ist es für keinen einzelnen Server eine große Belastung, Updates von anderen zu verarbeiten, und das Vorhandensein von Amateurservern ist kein Problem. +- **Video und anderer umfangreicher Inhalt** + - Es ist einfach für ein Relais, große Inhalte abzulehnen oder für das Akzeptieren und Hosten großer Inhalte Gebühren zu erheben. Wenn Informationen und Anreize klar sind, können die Marktkräfte das Problem leicht lösen. + +- **Techniken, um den Benutzer zu täuschen** + - Jeder Client kann entscheiden, wie Beiträge am besten den Benutzern angezeigt werden, sodass immer die Möglichkeit besteht, nur das zu konsumieren, was Sie möchten, und das auf die gewünschte Weise - von der Verwendung einer KI zur Entscheidung über die Reihenfolge der Updates, die Sie sehen werden, bis hin zum einfachen chronologischen Lesen. + +## Häufig gestellte Fragen (FAQ) + +- **Das ist sehr einfach. Warum hat das bisher niemand gemacht?** + + Ich weiß es nicht, aber ich stelle mir vor, dass es damit zu tun hat, dass Menschen, die soziale Netzwerke erstellen, entweder Unternehmen sind, die Geld verdienen wollen, oder P2P-Aktivisten, die eine Sache komplett ohne Server erstellen möchten. Beide übersehen die spezielle Mischung aus beiden Welten, die Nostr verwendet. + + +- **Wie finde ich Leute, denen ich folgen kann?** + + Zuerst müssen Sie sie kennen und irgendwie ihren öffentlichen Schlüssel erhalten, entweder durch Nachfragen oder indem Sie ihn irgendwo referenziert sehen. Sobald Sie in einem Nostr-Sozialnetzwerk sind, können Sie sie mit anderen Personen interagieren sehen und dann können Sie auch anfangen, diesen anderen zu folgen und mit ihnen zu interagieren. + +- **Wie finde ich Relais? Was passiert, wenn ich nicht mit denselben Relais verbunden bin wie jemand anderes?** + + Sie können nicht mit dieser Person kommunizieren. Es gibt jedoch Hinweise auf Ereignisse, die verwendet werden können, damit Ihre Client-Software (oder Sie manuell) weiß, wie sie sich mit dem Relais der anderen Person verbinden und mit ihnen interagieren kann. Es gibt auch andere Ideen, wie man dieses Problem in Zukunft lösen kann, aber wir können niemals eine perfekte Erreichbarkeit versprechen, das kann kein Protokoll. + +- **Kann ich wissen, wie viele Leute mir folgen?** + + Nein, aber Sie können einige Schätzungen erhalten, wenn Relais in einer außerprotokollarischen Weise zusammenarbeiten. + From e0b04369caf282131edab7ac23a17d0ac98cc500 Mon Sep 17 00:00:00 2001 From: Eugene Date: Wed, 22 Mar 2023 15:00:14 +0800 Subject: [PATCH 47/77] Update README.md --- translate/Deutsch/README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/translate/Deutsch/README.md b/translate/Deutsch/README.md index 9d1f951..8eb8588 100644 --- a/translate/Deutsch/README.md +++ b/translate/Deutsch/README.md @@ -105,3 +105,22 @@ Jeder führt einen Client aus. Es kann ein nativer Client, ein Web-Client usw. s Nein, aber Sie können einige Schätzungen erhalten, wenn Relais in einer außerprotokollarischen Weise zusammenarbeiten. +- **Welchen Anreiz gibt es für Menschen, Relais zu betreiben?** + + Die Frage ist irreführend. Sie geht davon aus, dass Relais kostenlose, dumme Rohre sind, die existieren, damit die Menschen Daten über sie hinweg bewegen können. In diesem Fall gäbe es tatsächlich keine Anreize. Dies könnte tatsächlich auch für DHT-Knoten in allen anderen P2P-Netzwerkstacks gesagt werden: Welchen Anreiz gibt es für Menschen, DHT-Knoten zu betreiben? + +- **Nostr ermöglicht Ihnen, zwischen Server-Relais zu wechseln oder mehrere Relais zu nutzen, aber wenn diese Relais nur auf AWS oder Azure sind, was ist der Unterschied?** + + Es gibt heute buchstäblich Tausende von VPS-Anbietern, die auf der ganzen Welt verstreut sind, nicht nur AWS oder Azure. AWS oder Azure sind genau die Anbieter, die von zentralisierten Dienstleistern verwendet werden, die eine große Skalierung benötigen, und selbst dann nicht nur diese beiden. Für kleinere Relais-Server wird jeder VPS die Arbeit sehr gut erledigen. + +## Protokollspezifikation + +Sehen Sie sich die [NIPs](https://github.com/nostr-protocol/nips) und insbesondere [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) für eine angemessen detaillierte Erklärung der Protokollspezifikation an (Hinweis: sie ist sehr kurz und einfach). + +## Software + +Es gibt eine Liste der meisten Software, die mit Nostr entwickelt wird, auf https://github.com/aljazceru/awesome-nostr, die beim letzten Mal, als ich nachgesehen habe, fast vollständig zu sein schien. + +## Lizenz + +Gemeinfrei. From 2a8929b187aa8e60e71375034b2b5dc8c70c7bca Mon Sep 17 00:00:00 2001 From: Eugene Date: Wed, 22 Mar 2023 15:00:40 +0800 Subject: [PATCH 48/77] Update README.md --- translate/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translate/README.md b/translate/README.md index c01f93f..44f4321 100644 --- a/translate/README.md +++ b/translate/README.md @@ -1,5 +1,5 @@ Content in other languages -| Japanese | Chinese | Spanish | French | -| -------- | -------- | -------- | -------- | +| Japanese | Chinese | Spanish | French | German | +| -------- | -------- | -------- | -------- | -------- | | [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | From df1e41751f9739761c026f63c70034e80d31c5c5 Mon Sep 17 00:00:00 2001 From: Eugene Date: Wed, 22 Mar 2023 15:03:49 +0800 Subject: [PATCH 49/77] Update README.md --- translate/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/README.md b/translate/README.md index 44f4321..63610ae 100644 --- a/translate/README.md +++ b/translate/README.md @@ -2,4 +2,4 @@ Content in other languages | Japanese | Chinese | Spanish | French | German | | -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | From 1ac068f25057a59faa9eff09a687c971216d02d1 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:49:32 +0800 Subject: [PATCH 50/77] Update README.md --- translate/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/translate/README.md b/translate/README.md index 63610ae..b60ed15 100644 --- a/translate/README.md +++ b/translate/README.md @@ -1,5 +1,5 @@ Content in other languages -| Japanese | Chinese | Spanish | French | German | -| -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | +| Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Arabic | Hindi | +| -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português]() | [Italiano]() | [عربي]() | [हिंदी]() | From d26ca7b833d49dc6cbc5768a5de6beb33777d238 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:50:20 +0800 Subject: [PATCH 51/77] Update README.md --- translate/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/README.md b/translate/README.md index b60ed15..e3fdc7b 100644 --- a/translate/README.md +++ b/translate/README.md @@ -2,4 +2,4 @@ Content in other languages | Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Arabic | Hindi | | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português]() | [Italiano]() | [عربي]() | [हिंदी]() | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano]() | [عربي]() | [हिंदी]() | From 41290cfaf82d3e900ec15e0262d6041ce9f47caa Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:51:25 +0800 Subject: [PATCH 52/77] Update README.md --- translate/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/README.md b/translate/README.md index e3fdc7b..a8febac 100644 --- a/translate/README.md +++ b/translate/README.md @@ -2,4 +2,4 @@ Content in other languages | Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Arabic | Hindi | | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano]() | [عربي]() | [हिंदी]() | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [عربي]() | [हिंदी]() | From bcfbec32f8ad71f0ed16c473449d8c87601f791b Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:51:58 +0800 Subject: [PATCH 53/77] Create README.md --- translate/Italiano/README.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 translate/Italiano/README.md diff --git a/translate/Italiano/README.md b/translate/Italiano/README.md new file mode 100644 index 0000000..87e55de --- /dev/null +++ b/translate/Italiano/README.md @@ -0,0 +1,2 @@ +# nostr - Notes and Other Stuff Transmitted by Relays +> Notes and Other Stuff Transmitted by Relays From b848a8390b9c52bb258636588e50ab0579c9f4b6 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:52:41 +0800 Subject: [PATCH 54/77] Update README.md --- translate/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/README.md b/translate/README.md index a8febac..a389267 100644 --- a/translate/README.md +++ b/translate/README.md @@ -2,4 +2,4 @@ Content in other languages | Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Arabic | Hindi | | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [عربي]() | [हिंदी]() | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [عربي](https://github.com/EugeneYip/nostr/tree/master/translate/%D8%B9%D8%B1%D8%A8%D9%8A) | [हिंदी]() | From f9f4573dd8fbcd736ea85bca807b7bf41785b0e5 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:53:37 +0800 Subject: [PATCH 55/77] Create README.md --- .../README.md" | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 "translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" diff --git "a/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" new file mode 100644 index 0000000..87e55de --- /dev/null +++ "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" @@ -0,0 +1,2 @@ +# nostr - Notes and Other Stuff Transmitted by Relays +> Notes and Other Stuff Transmitted by Relays From 09e9a9a16cefd17278ab4f46a8e2e76a6e8bef73 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:54:01 +0800 Subject: [PATCH 56/77] Update README.md --- translate/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/README.md b/translate/README.md index a389267..9f93e1b 100644 --- a/translate/README.md +++ b/translate/README.md @@ -2,4 +2,4 @@ Content in other languages | Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Arabic | Hindi | | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [عربي](https://github.com/EugeneYip/nostr/tree/master/translate/%D8%B9%D8%B1%D8%A8%D9%8A) | [हिंदी]() | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [عربي](https://github.com/EugeneYip/nostr/tree/master/translate/%D8%B9%D8%B1%D8%A8%D9%8A) | [हिंदी](https://github.com/EugeneYip/nostr/tree/master/translate/%E0%A4%B9%E0%A4%BF%E0%A4%82%E0%A4%A6%E0%A5%80) | From 0e7ba67ca072b6ae03207f6e95afc683fe87319b Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 15:57:32 +0800 Subject: [PATCH 57/77] Update README.md --- "translate/Portugu\303\252s/README.md" | 40 +++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git "a/translate/Portugu\303\252s/README.md" "b/translate/Portugu\303\252s/README.md" index 7eed14d..4d7772f 100644 --- "a/translate/Portugu\303\252s/README.md" +++ "b/translate/Portugu\303\252s/README.md" @@ -1,2 +1,40 @@ -# nostr - Notas e Outras Coisas Transmitidas por Relés +# nostr - Notas e Outras Coisas Transmitidas por Revezamento > Notes and Other Stuff Transmitted by Relays + +O protocolo aberto mais simples capaz de criar uma rede "social" global resistente à censura de uma vez por todas. + +Ele não depende de nenhum servidor central confiável, portanto é resiliente; é baseado em chaves criptográficas e assinaturas, tornando-se à prova de adulteração; ele não depende de técnicas P2P e, por isso, funciona. + +Este é um trabalho em andamento. [Participe do grupo do Telegram!](https://t.me/nostr_protocol) + +## Resumo bem curto de como funciona, caso você não planeje ler mais nada: + +Todo mundo executa um cliente. Pode ser um cliente nativo, um cliente web, etc. Para publicar algo, você escreve uma postagem, assina-a com sua chave e envia para vários servidores de revezamento (hospedados por outras pessoas ou por você mesmo). Para receber atualizações de outras pessoas, você pergunta a vários servidores de revezamento se eles sabem algo sobre essas outras pessoas. Qualquer um pode executar um servidor de revezamento. Um servidor de revezamento é muito simples e limitado. Ele não faz nada além de aceitar postagens de algumas pessoas e encaminhar para outras. Os servidores de revezamento não precisam ser confiáveis. As assinaturas são verificadas no lado do cliente. + +[Como começar a usar o Nostr](https://github.com/vishalxl/nostr_console/discussions/31) + +[Comparação de recursos do cliente Nostr](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Lista de projetos baseados no Nostr](https://github.com/aljazceru/awesome-nostr) + +## Isso é necessário porque outras soluções estão quebradas: + +### O problema com o Twitter + +- O Twitter tem anúncios; +- O Twitter usa técnicas bizarras para mantê-lo viciado; +- O Twitter não mostra um feed histórico real das pessoas que você segue; +- O Twitter bane pessoas; +- O Twitter faz shadowban de pessoas; +- O Twitter tem muito spam. + +### O problema com o Mastodon e programas similares + +- As identidades dos usuários estão vinculadas a nomes de domínio controlados por terceiros; +- Os proprietários dos servidores podem bani-lo, assim como o Twitter; os proprietários dos servidores também podem bloquear outros servidores; +- A migração entre servidores é uma reflexão tardia e só pode ser realizada se os servidores cooperarem. Não funciona em um ambiente adversarial (todos os seguidores são perdidos); +- Não há incentivos claros para executar servidores, portanto, eles tendem a ser executados por entusiastas e pessoas que desejam ter seu nome vinculado a um domínio legal. Assim, os usuários estão sujeitos ao despotismo de uma única pessoa, que muitas vezes é pior do que o de uma grande empresa como o Twitter, e eles não podem migrar para fora; +- Como os servidores tendem a ser executados de maneira amadora, muitas vezes são abandonados após um tempo - o que é efetivamente o mesmo que banir todos; +- Não faz sentido ter uma tonelada de servidores se as atualizações de todos os servidores tiverem que ser dolorosamente enviadas (e salvas!) para uma tonelada de outros servidores. Este ponto é exacerbado pelo fato de que os servidores tendem a existir em grande número, portanto, mais dados precisam ser repassados para mais lugares com mais frequência; +- Para o exemplo específico de compartilhamento de vídeo, os entusiastas do ActivityPub perceberam que seria completamente impossível transmitir vídeo de servidor para servidor da mesma forma que as notas de texto, então decidiram manter o vídeo hospedado apenas na instância única em que foi postado, o que é semelhante à abordagem do Nostr. + From 9e59ae312ba02378a86f29eac165ec987729019b Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:04:01 +0800 Subject: [PATCH 58/77] Update README.md --- "translate/Portugu\303\252s/README.md" | 53 ++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git "a/translate/Portugu\303\252s/README.md" "b/translate/Portugu\303\252s/README.md" index 4d7772f..fea4312 100644 --- "a/translate/Portugu\303\252s/README.md" +++ "b/translate/Portugu\303\252s/README.md" @@ -38,3 +38,56 @@ Todo mundo executa um cliente. Pode ser um cliente nativo, um cliente web, etc. - Não faz sentido ter uma tonelada de servidores se as atualizações de todos os servidores tiverem que ser dolorosamente enviadas (e salvas!) para uma tonelada de outros servidores. Este ponto é exacerbado pelo fato de que os servidores tendem a existir em grande número, portanto, mais dados precisam ser repassados para mais lugares com mais frequência; - Para o exemplo específico de compartilhamento de vídeo, os entusiastas do ActivityPub perceberam que seria completamente impossível transmitir vídeo de servidor para servidor da mesma forma que as notas de texto, então decidiram manter o vídeo hospedado apenas na instância única em que foi postado, o que é semelhante à abordagem do Nostr. +## Como funciona o Nostr? + +- Existem dois componentes: __clientes__ e __retransmissores__. Cada usuário executa um cliente. Qualquer um pode executar um retransmissor. +- Cada usuário é identificado por uma chave pública. Cada postagem é assinada. Cada cliente valida essas assinaturas. +- Os clientes buscam dados dos retransmissores de sua escolha e publicam dados em outros retransmissores de sua escolha. Um retransmissor não se comunica com outro retransmissor, apenas diretamente com os usuários. +- Por exemplo, para "seguir" alguém, um usuário simplesmente instrui seu cliente a consultar os retransmissores que conhece em busca de postagens dessa chave pública. +- Na inicialização, um cliente consulta dados de todos os retransmissores que conhece para todos os usuários que segue (por exemplo, todas as atualizações do último dia) e, em seguida, exibe esses dados para o usuário em ordem cronológica. +- Uma "postagem" pode conter qualquer tipo de dado estruturado, mas os mais usados encontrarão seu caminho no padrão para que todos os clientes e retransmissores possam lidar com eles de forma contínua. + +## Como isso resolve os problemas que as redes acima não conseguem? + +- **Usuários sendo banidos e servidores sendo fechados** + - Um retransmissor pode bloquear um usuário para evitar que ele publique qualquer coisa lá, mas isso não afeta o usuário, já que ele ainda pode publicar em outros retransmissores. Como os usuários são identificados por uma chave pública, eles não perdem suas identidades e sua base de seguidores quando são banidos. + - Em vez de exigir que os usuários digitem manualmente os novos endereços de retransmissores (embora isso também deva ser suportado), sempre que alguém que você está seguindo postar uma recomendação de servidor, o cliente deve adicionar automaticamente essa recomendação à lista de retransmissores que ele consultará. + - Se alguém estiver usando um retransmissor para publicar seus dados, mas desejar migrar para outro, pode publicar uma recomendação de servidor no retransmissor anterior e ir embora; + - Se alguém for banido de muitos retransmissores a ponto de não conseguir transmitir suas recomendações de servidores, ainda poderá avisar alguns amigos próximos por outros meios em qual retransmissor está publicando agora. Então, esses amigos próximos podem publicar recomendações de servidores para esse novo servidor, e aos poucos, a antiga base de seguidores do usuário banido começará a encontrar suas postagens novamente no novo retransmissor. + - Tudo o que foi mencionado acima também é válido para quando um retransmissor encerra suas operações. + +- **Resistência à censura** + - Cada usuário pode publicar suas atualizações em qualquer número de retransmissores. + - Um retransmissor pode cobrar uma taxa (a negociação dessa taxa está fora do protocolo por enquanto) dos usuários para publicar lá, o que garante resistência à censura (sempre haverá algum servidor russo disposto a receber seu dinheiro em troca de veicular suas postagens). + +- **Spam** + - Se o spam for uma preocupação para um retransmissor, ele pode exigir pagamento pela publicação ou alguma outra forma de autenticação, como um endereço de e-mail ou telefone, e associar internamente esses dados a uma chave pública que pode publicar nesse retransmissor - ou outras técnicas anti-spam, como hashcash ou captchas. Se um retransmissor estiver sendo usado como vetor de spam, ele pode ser facilmente retirado da lista pelos clientes, que podem continuar a buscar atualizações de outros retransmissores. + +- **Armazenamento de dados** + - Para que a rede permaneça saudável, não há necessidade de centenas de retransmissores ativos. Na verdade, pode funcionar muito bem com apenas alguns, dado o fato de que novos retransmissores podem ser criados e espalhados pela rede facilmente, caso os retransmissores existentes comecem a se comportar mal. Portanto, a quantidade de armazenamento de dados necessário, em geral, é relativamente menor do que Mastodon ou software similar. + - Ou considerando um resultado diferente: um em que existam centenas de retransmissores de nicho administrados por amadores, cada um retransmitindo atualizações de um pequeno grupo de usuários. A arquitetura escala igualmente bem: os dados são enviados dos usuários para um único servidor e, desse servidor, diretamente para os usuários que consumirão isso. Não precisa ser armazenado por mais ninguém. Nessa situação, não é um grande fardo para um único servidor processar atualizações de outros, e ter servidores amadores não é um problema. + +- **Vídeo e outros conteúdos pesados** + - É fácil para um retransmissor rejeitar conteúdo grande ou cobrar por aceitar e hospedar conteúdo grande. Quando as informações e incentivos são claros, é fácil para as forças do mercado resolverem o problema. + +- **Técnicas para enganar o usuário** + - Cada cliente pode decidir como melhor mostrar as postagens aos usuários, então sempre há a opção de apenas consumir o que você deseja da maneira que desejar - desde usar uma IA para decidir a ordem das atualizações que você verá até lê-las em ordem cronológica. + +## FAQ + +- **Isso é muito simples. Por que ninguém fez isso antes?** + + Eu não sei, mas imagino que isso tenha a ver com o fato de que as pessoas que criam redes sociais são ou empresas querendo ganhar dinheiro ou ativistas P2P que desejam criar algo completamente sem servidores. Ambos falham em perceber a mistura específica de ambos os mundos que o Nostr utiliza. + +- **Como encontro pessoas para seguir?** + + Primeiro, você deve conhecê-las e obter a chave pública delas de alguma forma, seja perguntando ou vendo-a referenciada em algum lugar. Uma vez que você esteja dentro de uma rede social Nostr, você poderá vê-las interagindo com outras pessoas e então também poderá começar a seguir e interagir com esses outros. + +- **Como encontro retransmissores? O que acontece se eu não estiver conectado aos mesmos retransmissores que outra pessoa?** + + Você não conseguirá se comunicar com essa pessoa. Mas há dicas em eventos que podem ser usadas para que seu software cliente (ou você, manualmente) saiba como se conectar ao retransmissor da outra pessoa e interagir com ela. Há outras ideias sobre como resolver isso também no futuro, mas nunca podemos prometer alcançabilidade perfeita, nenhum protocolo pode. + +- **Posso saber quantas pessoas estão me seguindo?** + + Não, mas você pode obter algumas estimativas se os retransmissores cooperarem de forma extra-protocolar. + From c9c1b24e6f3b6911391d31a58cf8f8f50cacf49d Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:05:13 +0800 Subject: [PATCH 59/77] Update README.md --- "translate/Portugu\303\252s/README.md" | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git "a/translate/Portugu\303\252s/README.md" "b/translate/Portugu\303\252s/README.md" index fea4312..9d39a05 100644 --- "a/translate/Portugu\303\252s/README.md" +++ "b/translate/Portugu\303\252s/README.md" @@ -91,3 +91,22 @@ Todo mundo executa um cliente. Pode ser um cliente nativo, um cliente web, etc. Não, mas você pode obter algumas estimativas se os retransmissores cooperarem de forma extra-protocolar. +- **Qual incentivo existe para as pessoas executarem retransmissores?** + + A pergunta é enganosa. Ela pressupõe que os retransmissores são tubos burros e gratuitos que existem para que as pessoas possam movimentar dados através deles. Nesse caso, sim, os incentivos não existiriam. Isso, de fato, poderia ser dito sobre os nós DHT em todas as outras pilhas de redes p2p: qual incentivo existe para as pessoas executarem nós DHT? + +- **Nostr permite que você se mova entre retransmissores de servidores ou use vários retransmissores, mas se esses retransmissores estiverem apenas na AWS ou Azure, qual é a diferença?** + + Existem literalmente milhares de provedores de VPS espalhados por todo o mundo hoje, não existem apenas AWS ou Azure. AWS ou Azure são exatamente os provedores usados ​​por provedores de serviços centralizados que precisam de muita escala e, mesmo assim, não apenas esses dois. Para servidores de retransmissão menores, qualquer VPS fará o trabalho muito bem. + +## Especificação do protocolo + +Consulte os [NIPs](https://github.com/nostr-protocol/nips) e especialmente o [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) para uma explicação razoavelmente detalhada da especificação do protocolo (dica: é muito curto e simples). + +## Software + +Há uma lista da maioria dos softwares sendo construídos usando Nostr em https://github.com/aljazceru/awesome-nostr que parecia estar quase completa na última vez que olhei. + +## Licença + +Domínio público. From a578f862ff7df3ad746f22f8a60c54ed999694b3 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:07:10 +0800 Subject: [PATCH 60/77] Update README.md --- translate/Italiano/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/Italiano/README.md b/translate/Italiano/README.md index 87e55de..d65d52a 100644 --- a/translate/Italiano/README.md +++ b/translate/Italiano/README.md @@ -1,2 +1,2 @@ -# nostr - Notes and Other Stuff Transmitted by Relays +# nostr - Note e Altre Cose Trasmesse dai Relay > Notes and Other Stuff Transmitted by Relays From 599dc0e72170a5fdd39c616b27bbe9e1710c3d3c Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:10:16 +0800 Subject: [PATCH 61/77] Update README.md --- translate/Italiano/README.md | 40 ++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/translate/Italiano/README.md b/translate/Italiano/README.md index d65d52a..992f554 100644 --- a/translate/Italiano/README.md +++ b/translate/Italiano/README.md @@ -1,2 +1,42 @@ # nostr - Note e Altre Cose Trasmesse dai Relay > Notes and Other Stuff Transmitted by Relays + +# nostr - Note e Altre Cose Trasmesse dai Relay + +Il protocollo aperto più semplice in grado di creare una volta per tutte una rete "sociale" globale resistente alla censura. + +Non si basa su alcun server centrale di fiducia, quindi è resiliente; si basa su chiavi e firme crittografiche, quindi è a prova di manomissione; non si basa su tecniche P2P e quindi funziona. + +Questo è un lavoro in corso. [Unisciti al gruppo Telegram!](https://t.me/nostr_protocol) + +## Breve riassunto di come funziona, se non hai intenzione di leggere altro: + +Tutti eseguono un client. Può essere un client nativo, un client web, ecc. Per pubblicare qualcosa, scrivi un post, firmalo con la tua chiave e invialo a più relay (server ospitati da qualcun altro o da te stesso). Per ricevere aggiornamenti da altre persone, chiedi a più relay se sanno qualcosa su queste altre persone. Chiunque può eseguire un relay. Un relay è molto semplice e stupido. Non fa altro che accettare post da alcune persone e inoltrarli ad altre. I relay non devono essere di fiducia. Le firme vengono verificate sul lato client. + +[Cosa fare per iniziare a utilizzare Nostr](https://github.com/vishalxl/nostr_console/discussions/31) + +[Confronto delle funzionalità dei client Nostr](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Elenco dei progetti basati su Nostr](https://github.com/aljazceru/awesome-nostr) + +## Questo è necessario perché altre soluzioni sono difettose: + +### Il problema con Twitter + +- Twitter ha pubblicità; +- Twitter utilizza tecniche bizzarre per mantenerti dipendente; +- Twitter non mostra un feed storico effettivo delle persone che segui; +- Twitter banna le persone; +- Twitter mette in shadowban le persone; +- Twitter ha molto spam. + +### Il problema con Mastodon e programmi simili + +- Le identità degli utenti sono legate a nomi di dominio controllati da terze parti; +- I proprietari dei server possono bannarti, proprio come Twitter; i proprietari dei server possono anche bloccare altri server; +- La migrazione tra server è un'aggiunta tardiva e può essere realizzata solo se i server cooperano. Non funziona in un ambiente ostile (tutti i follower vengono persi); +- Non ci sono incentivi chiari per gestire i server, quindi, tendono ad essere gestiti da appassionati e persone che vogliono avere il loro nome associato a un dominio interessante. Quindi, gli utenti sono soggetti al dispotismo di una singola persona, che spesso è peggiore di quello di una grande azienda come Twitter, e non possono migrare; +- Poiché i server tendono ad essere gestiti in modo dilettantesco, spesso vengono abbandonati dopo un po' - il che è effettivamente lo stesso che bannare tutti; +- Non ha senso avere un'enorme quantità di server se gli aggiornamenti da ogni server dovranno essere spinti (e salvati!) dolorosamente su un'enorme quantità di altri server. Questo punto è aggravato dal fatto che i server tendono ad esistere in grandi numeri, quindi più dati devono essere trasmessi a più luoghi più spesso; +- Per l'esempio specifico della condivisione di video, gli appassionati di ActivityPub si sono resi conto che sarebbe stato completamente impossibile trasmettere video da server a server come si fa con le note di testo, quindi hanno deciso di mantenere il video ospitato solo dall'istanza singola in cui è stato pubblicato, il che è simile all'approccio di Nostr. + From d148cee58512713271a18da123b5b87d942ba16d Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:10:35 +0800 Subject: [PATCH 62/77] Update README.md --- translate/Italiano/README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/translate/Italiano/README.md b/translate/Italiano/README.md index 992f554..2f25a19 100644 --- a/translate/Italiano/README.md +++ b/translate/Italiano/README.md @@ -1,8 +1,6 @@ # nostr - Note e Altre Cose Trasmesse dai Relay > Notes and Other Stuff Transmitted by Relays -# nostr - Note e Altre Cose Trasmesse dai Relay - Il protocollo aperto più semplice in grado di creare una volta per tutte una rete "sociale" globale resistente alla censura. Non si basa su alcun server centrale di fiducia, quindi è resiliente; si basa su chiavi e firme crittografiche, quindi è a prova di manomissione; non si basa su tecniche P2P e quindi funziona. From 600b3a0eba1a028a02e39d08e0a0b074b4ef06e3 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:13:44 +0800 Subject: [PATCH 63/77] Update README.md --- translate/Italiano/README.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/translate/Italiano/README.md b/translate/Italiano/README.md index 2f25a19..ad56b45 100644 --- a/translate/Italiano/README.md +++ b/translate/Italiano/README.md @@ -38,3 +38,34 @@ Tutti eseguono un client. Può essere un client nativo, un client web, ecc. Per - Non ha senso avere un'enorme quantità di server se gli aggiornamenti da ogni server dovranno essere spinti (e salvati!) dolorosamente su un'enorme quantità di altri server. Questo punto è aggravato dal fatto che i server tendono ad esistere in grandi numeri, quindi più dati devono essere trasmessi a più luoghi più spesso; - Per l'esempio specifico della condivisione di video, gli appassionati di ActivityPub si sono resi conto che sarebbe stato completamente impossibile trasmettere video da server a server come si fa con le note di testo, quindi hanno deciso di mantenere il video ospitato solo dall'istanza singola in cui è stato pubblicato, il che è simile all'approccio di Nostr. +### Il problema con SSB (Secure Scuttlebutt) + +- Non ha molti problemi. Penso che sia fantastico. Stavo per usarlo come base per questo, ma +- il suo protocollo è troppo complicato perché non è stato pensato affatto come un protocollo aperto. È stato scritto in JavaScript probabilmente in modo veloce per risolvere un problema specifico e si è sviluppato da lì, quindi ha stranezze e peculiarità inutili come la firma di una stringa JSON che deve seguire rigorosamente le regole del [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); +- Insiste sull'avere una catena di aggiornamenti da un singolo utente, il che mi sembra superfluo e qualcosa che aggiunge gonfiore e rigidità alla cosa - ogni server/utente deve memorizzare tutta la catena di post per essere sicuro che il nuovo sia valido. Perché? (Forse hanno una buona ragione); +- Non è semplice come Nostr, in quanto è stato creato principalmente per la sincronizzazione P2P, con i "pub" come un'aggiunta successiva; +- Tuttavia, potrebbe valere la pena considerare l'utilizzo di SSB invece di questo protocollo personalizzato e adattarlo semplicemente al modello client-relay server, perché riutilizzare uno standard è sempre meglio che cercare di far aderire le persone a uno nuovo. + +### Il problema con altre soluzioni che richiedono a tutti di gestire il proprio server + +- Richiedono a tutti di gestire il proprio server; +- A volte le persone possono comunque essere censurate in queste perché i nomi di dominio possono essere censurati. + +## Come funziona Nostr? + +- Ci sono due componenti: __client__ e __relay__. Ogni utente esegue un client. Chiunque può eseguire un relay. +- Ogni utente è identificato da una chiave pubblica. Ogni post è firmato. Ogni client convalida queste firme. +- I client ottengono dati dai relay a loro scelta e pubblicano dati su altri relay a loro scelta. Un relay non comunica con un altro relay, solo direttamente con gli utenti. +- Ad esempio, per "seguire" qualcuno, un utente dà semplicemente istruzioni al proprio client di interrogare i relay che conosce per i post di quella chiave pubblica. +- All'avvio, un client interroga i dati da tutti i relay che conosce per tutti gli utenti che segue (ad esempio, tutti gli aggiornamenti dell'ultimo giorno), quindi visualizza tali dati all'utente in ordine cronologico. +- Un "post" può contenere qualsiasi tipo di dati strutturati, ma quelli più utilizzati troveranno il loro posto nello standard in modo che tutti i client e i relay possano gestirli senza problemi. + +## Come risolve i problemi che le reti sopra non riescono a risolvere? + +- **Utenti bannati e chiusura dei server** + - Un relay può bloccare un utente dall'inviare qualsiasi cosa lì, ma ciò non ha effetto su di loro in quanto possono ancora pubblicare su altri relay. Poiché gli utenti sono identificati da una chiave pubblica, non perdono le loro identità e la base di follower quando vengono bannati. + - Invece di richiedere agli utenti di digitare manualmente nuovi indirizzi relay (anche se ciò dovrebbe essere supportato), ogni volta che qualcuno che segui pubblica una raccomandazione di server, il client dovrebbe aggiungere automaticamente quella alla lista dei relay che interrogherà. + - Se qualcuno sta utilizzando un relay per pubblicare i propri dati ma desidera migrare su un altro, può pubblicare una raccomandazione del server su quel relay precedente e andarsene; + - Se qualcuno viene bannato da molti relay in modo tale da non poter trasmettere le loro raccomandazioni di server, può comunque far sapere ad alcuni amici stretti tramite altri mezzi con quale relay sta pubblicando ora. Quindi, questi amici stretti possono pubblicare raccomandazioni di server su quel nuovo server e, lentamente, la vecchia base di follower dell'utente bannato inizierà a trovare di nuovo i loro post dal nuovo relay. + - Tutto quanto sopra è valido anche quando un relay cessa le sue operazioni. + From 91f2dd09c1cbdbb4221ac803aab68423624c69e1 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:18:44 +0800 Subject: [PATCH 64/77] Update README.md --- translate/Italiano/README.md | 54 ++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/translate/Italiano/README.md b/translate/Italiano/README.md index ad56b45..13e41f1 100644 --- a/translate/Italiano/README.md +++ b/translate/Italiano/README.md @@ -69,3 +69,57 @@ Tutti eseguono un client. Può essere un client nativo, un client web, ecc. Per - Se qualcuno viene bannato da molti relay in modo tale da non poter trasmettere le loro raccomandazioni di server, può comunque far sapere ad alcuni amici stretti tramite altri mezzi con quale relay sta pubblicando ora. Quindi, questi amici stretti possono pubblicare raccomandazioni di server su quel nuovo server e, lentamente, la vecchia base di follower dell'utente bannato inizierà a trovare di nuovo i loro post dal nuovo relay. - Tutto quanto sopra è valido anche quando un relay cessa le sue operazioni. +- **Resistenza alla censura** + - Ogni utente può pubblicare i propri aggiornamenti su un qualsiasi numero di relay. + - Un relay può richiedere una tariffa (la negoziazione di tale tariffa è al di fuori del protocollo per ora) agli utenti per pubblicare lì, il che garantisce la resistenza alla censura (ci sarà sempre qualche server russo disposto a prendere i tuoi soldi in cambio della pubblicazione dei tuoi post). + +- **Spam** + - Se lo spam è una preoccupazione per un relay, può richiedere un pagamento per la pubblicazione o un'altra forma di autenticazione, come un indirizzo e-mail o telefono, e associare internamente questi ad una pubkey che poi ottiene la pubblicazione su quel relay - o altre tecniche anti-spam, come hashcash o captcha. Se un relay viene utilizzato come vettore di spam, può essere facilmente eliminato dai client, che possono continuare a recuperare aggiornamenti da altri relay. + +- **Archiviazione dati** + - Perché la rete rimanga in salute, non è necessario avere centinaia di relay attivi. Infatti, può funzionare benissimo con solo una manciata, dato il fatto che nuovi relay possono essere creati e diffusi attraverso la rete facilmente nel caso in cui i relay esistenti inizino a comportarsi male. Pertanto, la quantità di archiviazione dati richiesta, in generale, è relativamente inferiore rispetto a Mastodon o software simili. + - Oppure considerando un risultato diverso: uno in cui esistono centinaia di relay di nicchia gestiti da dilettanti, ognuno che trasmette aggiornamenti da un piccolo gruppo di utenti. L'architettura scala altrettanto bene: i dati vengono inviati dagli utenti a un singolo server e da quel server direttamente agli utenti che li consumeranno. Non deve essere memorizzato da nessun altro. In questa situazione, non è un grosso peso per un singolo server elaborare aggiornamenti da altri, e avere server amatoriali non è un problema. + +- **Video e altri contenuti pesanti** + - È facile per un relay rifiutare contenuti di grandi dimensioni o addebitare una tariffa per accettare e ospitare contenuti di grandi dimensioni. Quando le informazioni e gli incentivi sono chiari, è facile per le forze di mercato risolvere il problema. + +- **Tecniche per ingannare l'utente** + - Ogni client può decidere come mostrare al meglio i post agli utenti, quindi c'è sempre l'opzione di consumare ciò che si desidera nel modo desiderato - dall'utilizzare un'intelligenza artificiale per decidere l'ordine degli aggiornamenti che vedrai al semplice leggerli in ordine cronologico. + +## FAQ + +- **Questo è molto semplice. Perché nessuno l'ha fatto prima?** + + Non lo so, ma immagino che abbia a che fare con il fatto che le persone che creano reti sociali sono o aziende che vogliono fare soldi o attivisti P2P che vogliono realizzare qualcosa completamente senza server. Entrambi non riescono a vedere la specifica combinazione di entrambi i mondi che Nostr utilizza. + +- **Come faccio a trovare persone da seguire?** + + Innanzitutto, devi conoscerle e ottenere in qualche modo la loro chiave pubblica, sia chiedendola sia vedendola citata da qualche parte. Una volta che sei all'interno di una rete sociale Nostr, potrai vederle interagire con altre persone e quindi potrai anche iniziare a seguire e interagire con queste altre. + +- **Come faccio a trovare i relay? Cosa succede se non sono connesso agli stessi relay di qualcun altro?** + + Non sarai in grado di comunicare con quella persona. Ma ci sono suggerimenti sugli eventi che possono essere utilizzati in modo che il tuo software client (o tu, manualmente) sappia come connettersi al relay dell'altra persona e interagire con loro. Ci sono altre idee su come risolvere questo problema anche in futuro, ma non possiamo mai promettere una raggiungibilità perfetta, nessun protocollo può. + +- **Posso sapere quante persone mi stanno seguendo?** + + No, ma puoi avere delle stime se i relay cooperano in un modo extra-protocollo. + +- **Qual è l'incentivo per le persone a gestire i relay?** + + La domanda è fuorviante. Presuppone che i relay siano tubi stupidi gratuiti che esistono in modo che le persone possano spostare i dati attraverso di essi. In questo caso sì, gli incentivi non esisterebbero. Questo, infatti, potrebbe essere detto dei nodi DHT in tutte le altre pile di reti p2p: qual è l'incentivo per le persone a gestire i nodi DHT? + +- **Nostr ti permette di spostarti tra i relay server o utilizzare più relay, ma se questi relay sono solo su AWS o Azure qual è la differenza?** + + Ci sono letteralmente migliaia di fornitori di VPS sparsi in tutto il mondo oggi, non ci sono solo AWS o Azure. AWS o Azure sono esattamente i fornitori utilizzati dai singoli fornitori di servizi centralizzati che necessitano di molta scalabilità e, anche in questo caso, non solo questi due. Per i relay server più piccoli, qualsiasi VPS farà molto bene il lavoro. + +## Specifiche del protocollo + +Consulta le [NIPs](https://github.com/nostr-protocol/nips) e in particolare [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) per una spiegazione ragionevolmente dettagliata delle specifiche del protocollo (suggerimento: è molto breve e semplice). + +## Software + +C'è una lista della maggior parte del software in costruzione usando Nostr su https://github.com/aljazceru/awesome-nostr che sembrava essere quasi completa l'ultima volta che ho guardato. + +## Licenza + +Pubblico dominio. From 9e6efda1f6037740f88ff748ddd5f6db585ff37b Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:38:41 +0800 Subject: [PATCH 65/77] Update README.md --- "translate/\330\271\330\261\330\250\331\212/README.md" | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git "a/translate/\330\271\330\261\330\250\331\212/README.md" "b/translate/\330\271\330\261\330\250\331\212/README.md" index 71fa690..a31169c 100644 --- "a/translate/\330\271\330\261\330\250\331\212/README.md" +++ "b/translate/\330\271\330\261\330\250\331\212/README.md" @@ -1,2 +1,3 @@ -# nostr - ملاحظات وأشياء أخرى مرسلة عبر الأرجحية +# nostr - ملاحظات وأشياء أخرى تُبث عبر المُرسِلات > Notes and Other Stuff Transmitted by Relays + From 6e5efa62d6e12d7fa70e2a776f49082553149d6b Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:50:16 +0800 Subject: [PATCH 66/77] Update README.md --- "translate/\330\271\330\261\330\250\331\212/README.md" | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git "a/translate/\330\271\330\261\330\250\331\212/README.md" "b/translate/\330\271\330\261\330\250\331\212/README.md" index a31169c..05333d9 100644 --- "a/translate/\330\271\330\261\330\250\331\212/README.md" +++ "b/translate/\330\271\330\261\330\250\331\212/README.md" @@ -1,3 +1,11 @@ # nostr - ملاحظات وأشياء أخرى تُبث عبر المُرسِلات > Notes and Other Stuff Transmitted by Relays +# nostr - ملاحظات وأشياء أخرى تُبث عبر المُرسِلات + +أبسط بروتوكول مفتوح يتيح إنشاء شبكة "اجتماعية" عالمية مقاومة للرقابة مرة واحدة وإلى الأبد. + +لا يعتمد على أي خادم مركزي موثوق به، وبالتالي فهو مرن؛ يعتمد على المفاتيح والتوقيعات الرقمية، لذلك فهو مقاوم للتزوير؛ لا يعتمد على تقنيات P2P، وبالتالي يعمل. + +هذا عمل قيد التطوير. [انضم إلى مجموعة Telegram!](https://t.me/nostr_protocol) + From f3370330efb87433da292cef0c8c83e746d7316a Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 16:50:40 +0800 Subject: [PATCH 67/77] Update README.md --- "translate/\330\271\330\261\330\250\331\212/README.md" | 2 -- 1 file changed, 2 deletions(-) diff --git "a/translate/\330\271\330\261\330\250\331\212/README.md" "b/translate/\330\271\330\261\330\250\331\212/README.md" index 05333d9..94490c8 100644 --- "a/translate/\330\271\330\261\330\250\331\212/README.md" +++ "b/translate/\330\271\330\261\330\250\331\212/README.md" @@ -1,8 +1,6 @@ # nostr - ملاحظات وأشياء أخرى تُبث عبر المُرسِلات > Notes and Other Stuff Transmitted by Relays -# nostr - ملاحظات وأشياء أخرى تُبث عبر المُرسِلات - أبسط بروتوكول مفتوح يتيح إنشاء شبكة "اجتماعية" عالمية مقاومة للرقابة مرة واحدة وإلى الأبد. لا يعتمد على أي خادم مركزي موثوق به، وبالتالي فهو مرن؛ يعتمد على المفاتيح والتوقيعات الرقمية، لذلك فهو مقاوم للتزوير؛ لا يعتمد على تقنيات P2P، وبالتالي يعمل. From 0b2a634734055558ea0839413569f58cb4af2741 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 17:03:30 +0800 Subject: [PATCH 68/77] Update README.md --- .../README.md" | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git "a/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" index 87e55de..f60e6bb 100644 --- "a/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" +++ "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" @@ -1,2 +1,8 @@ -# nostr - Notes and Other Stuff Transmitted by Relays +\# nostr - रिले द्वारा प्रेषित नोट्स और अन्य सामग्री > Notes and Other Stuff Transmitted by Relays + +सबसे सरल खुला प्रोटोकॉल जो एक बार और सभी के लिए सेंसरशिप-प्रतिरोधी वैश्विक "सामाजिक" नेटवर्क बनाने में सक्षम है। + +इस पर किसी भरोसेमंद केंद्रीय सर्वर पर निर्भर नहीं होता है, इसलिए यह लचीला है; यह क्रिप्टोग्राफ़िक कुंजी और हस्ताक्षरों पर आधारित है, इसलिए इसे बदला नहीं जा सकता है; इसे P2P तकनीकों पर निर्भर नहीं करता है, और इसलिए यह काम करता है। + +यह एक काम प्रगति पर है। [Telegram समूह में शामिल हों!](https://t.me/nostr_protocol) From b3b31df5f7362f49f5a1dcce87268e96ffb3b794 Mon Sep 17 00:00:00 2001 From: Eugene Date: Thu, 23 Mar 2023 17:03:50 +0800 Subject: [PATCH 69/77] Update README.md --- .../README.md" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" index f60e6bb..91e36cf 100644 --- "a/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" +++ "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" @@ -1,4 +1,4 @@ -\# nostr - रिले द्वारा प्रेषित नोट्स और अन्य सामग्री +# nostr - रिले द्वारा प्रेषित नोट्स और अन्य सामग्री > Notes and Other Stuff Transmitted by Relays सबसे सरल खुला प्रोटोकॉल जो एक बार और सभी के लिए सेंसरशिप-प्रतिरोधी वैश्विक "सामाजिक" नेटवर्क बनाने में सक्षम है। From bdfd4d40d4677986b21571c7b0f94caa42e883e2 Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 13:27:13 +0800 Subject: [PATCH 70/77] Update README.md --- .../README.md" | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git "a/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" index 91e36cf..c27e3a9 100644 --- "a/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" +++ "b/translate/\340\244\271\340\244\277\340\244\202\340\244\246\340\245\200/README.md" @@ -6,3 +6,13 @@ इस पर किसी भरोसेमंद केंद्रीय सर्वर पर निर्भर नहीं होता है, इसलिए यह लचीला है; यह क्रिप्टोग्राफ़िक कुंजी और हस्ताक्षरों पर आधारित है, इसलिए इसे बदला नहीं जा सकता है; इसे P2P तकनीकों पर निर्भर नहीं करता है, और इसलिए यह काम करता है। यह एक काम प्रगति पर है। [Telegram समूह में शामिल हों!](https://t.me/nostr_protocol) + +## इसे कैसे काम करता है, इसका संक्षेप में विवरण, यदि आप कुछ और पढ़ने की योजना नहीं बना रहे हैं: + +सभी एक क्लाइंट चलाते हैं। यह एक मूल क्लाइंट, वेब क्लाइंट आदि हो सकता है। किसी चीज़ को प्रकाशित करने के लिए, आप एक पोस्ट लिखते हैं, इसे अपनी कुंजी के साथ हस्ताक्षरित करते हैं और इसे कई रिले (किसी और द्वारा होस्ट किए गए सर्वर या खुद) पर भेजते हैं। दूसरे लोगों से अपडेट प्राप्त करने के लिए, आप कई रिले से पूछते हैं कि क्या वे इन दूसरे लोगों के बारे में कुछ जानते हैं। कोई भी रिले चला सकता है। एक रिले बहुत सरल और मूर्ख होता है। इसके अलावा यह कुछ नहीं करता है, सिवाय कुछ लोगों के पोस्ट स्वीकार करने और दूसरों को फॉरवर्ड करने के। रिले पर विश्वास करने की आवश्यकता नहीं है। हस्ताक्षर क्लाइंट की ओर सत्यापित किए जाते हैं। + +[Nostr का उपयोग कैसे शुरू करें](https://github.com/vishalxl/nostr_console/discussions/31) + +[Nostr क्लाइंट फीचर तुलना](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Nostr पर निर्मित परियोजनाओं की सूची](https://github.com/aljazceru/awesome-nostr) From 5d9236fbed56f09ffd0b5ac7922e50630b029f67 Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 13:39:21 +0800 Subject: [PATCH 71/77] Update README.md --- translate/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/translate/README.md b/translate/README.md index 9f93e1b..b24bcf5 100644 --- a/translate/README.md +++ b/translate/README.md @@ -1,5 +1,5 @@ Content in other languages -| Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Arabic | Hindi | -| -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [عربي](https://github.com/EugeneYip/nostr/tree/master/translate/%D8%B9%D8%B1%D8%A8%D9%8A) | [हिंदी](https://github.com/EugeneYip/nostr/tree/master/translate/%E0%A4%B9%E0%A4%BF%E0%A4%82%E0%A4%A6%E0%A5%80) | +| Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Ukrainian | Arabic | Hindi | +| -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [українська]() | [عربي](https://github.com/EugeneYip/nostr/tree/master/translate/%D8%B9%D8%B1%D8%A8%D9%8A) | [हिंदी](https://github.com/EugeneYip/nostr/tree/master/translate/%E0%A4%B9%E0%A4%BF%E0%A4%82%E0%A4%A6%E0%A5%80) | From 2e59fe39b3c6c9955eb9f15c46c49ac812dccfd3 Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 13:40:40 +0800 Subject: [PATCH 72/77] Create README.md --- .../README.md" | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 "translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" diff --git "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" new file mode 100644 index 0000000..ebff3e8 --- /dev/null +++ "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" @@ -0,0 +1,7 @@ +# nostr - Нотатки та Інше Передане через Реле + +Найпростіший відкритий протокол, який здатний створити стійку до цензури глобальну "соціальну" мережу раз і назавжди. + +Він не залежить від жодного центрального сервера, на якому можна довірятися, тому він стійкий; він базується на криптографічних ключах та підписах, отже, він захищений від змін; він не залежить від P2P-технік, і тому він працює. + +Це робота в процесі. [Приєднуйтесь до групи Telegram!](https://t.me/nostr_protocol) From 1414dcc30ffb3747f0b16a750c30965f5f677907 Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 13:40:57 +0800 Subject: [PATCH 73/77] Update README.md --- translate/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translate/README.md b/translate/README.md index b24bcf5..fdb6a64 100644 --- a/translate/README.md +++ b/translate/README.md @@ -2,4 +2,4 @@ Content in other languages | Japanese | Chinese | Spanish | French | German | Portuguese | Italian | Ukrainian | Arabic | Hindi | | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [українська]() | [عربي](https://github.com/EugeneYip/nostr/tree/master/translate/%D8%B9%D8%B1%D8%A8%D9%8A) | [हिंदी](https://github.com/EugeneYip/nostr/tree/master/translate/%E0%A4%B9%E0%A4%BF%E0%A4%82%E0%A4%A6%E0%A5%80) | +| [日本語](https://github.com/EugeneYip/nostr/tree/master/translate/%E6%97%A5%E6%9C%AC%E8%AA%9E) | [中文](https://github.com/EugeneYip/nostr/tree/master/translate/%E4%B8%AD%E6%96%87) | [Español](https://github.com/EugeneYip/nostr/tree/master/translate/Espa%C3%B1ol) | [Français](https://github.com/EugeneYip/nostr/tree/master/translate/Fran%C3%A7ais) | [Deutsch](https://github.com/EugeneYip/nostr/tree/master/translate/Deutsch) | [Português](https://github.com/EugeneYip/nostr/tree/master/translate/Portugu%C3%AAs) | [Italiano](https://github.com/EugeneYip/nostr/tree/master/translate/Italiano) | [українська](https://github.com/EugeneYip/nostr/tree/master/translate/%D1%83%D0%BA%D1%80%D0%B0%D1%97%D0%BD%D1%81%D1%8C%D0%BA%D0%B0) | [عربي](https://github.com/EugeneYip/nostr/tree/master/translate/%D8%B9%D8%B1%D8%A8%D9%8A) | [हिंदी](https://github.com/EugeneYip/nostr/tree/master/translate/%E0%A4%B9%E0%A4%BF%E0%A4%82%E0%A4%A6%E0%A5%80) | From f50f5b66ac744b24bc1979c03e9fbc9ed5410701 Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 13:42:17 +0800 Subject: [PATCH 74/77] Update README.md --- .../README.md" | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" index ebff3e8..44fad5d 100644 --- "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" +++ "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" @@ -5,3 +5,13 @@ Він не залежить від жодного центрального сервера, на якому можна довірятися, тому він стійкий; він базується на криптографічних ключах та підписах, отже, він захищений від змін; він не залежить від P2P-технік, і тому він працює. Це робота в процесі. [Приєднуйтесь до групи Telegram!](https://t.me/nostr_protocol) + +## Дуже короткий підсумок того, як це працює, якщо ви не плануєте читати щось інше: + +Кожен використовує клієнт. Це може бути рідний клієнт, веб-клієнт тощо. Щоб опублікувати щось, ви пишете повідомлення, підписуєте його своїм ключем та відправляєте на кілька реле (сервери, розміщені кимось іншим або вами самими). Щоб отримати оновлення від інших людей, ви запитуєте кілька реле, чи знають вони щось про цих інших людей. Будь-хто може запустити реле. Реле дуже просте та тупе. Воно нічого не робить, крім прийому повідомлень від деяких людей та пересилання їх іншим. Реле не мають бути довіреними. Підписи перевіряються на стороні клієнта. + +[Як почати використовувати Nostr](https://github.com/vishalxl/nostr_console/discussions/31) + +[Порівняння можливостей клієнтів Nostr](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) + +[Список проектів, заснованих на Nostr](https://github.com/aljazceru/awesome-nostr) From e17d836c9daa16e6a004f8b81ed0f15220081bab Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 13:57:51 +0800 Subject: [PATCH 75/77] Update README.md --- .../README.md" | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" index 44fad5d..b604c2d 100644 --- "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" +++ "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" @@ -15,3 +15,37 @@ [Порівняння можливостей клієнтів Nostr](https://github.com/vishalxl/Nostr-Clients-Features-List/blob/main/Readme.md) [Список проектів, заснованих на Nostr](https://github.com/aljazceru/awesome-nostr) + +## Це потрібно, тому що інші рішення не працюють: + +### Проблема з Twitter + +- У Twitter є реклама; +- Twitter використовує дивні методи, щоб залучити вас; +- Twitter не показує реальний історичний стрічку від людей, яких ви слідкуєте; +- Twitter блокує людей; +- Twitter тіньово блокує людей; +- У Twitter багато спаму. + +### Проблема з Mastodon та схожими програмами + +- Ідентичності користувачів прив'язані до доменних імен, які контролюються третіми сторонами; +- Власники серверів можуть вас заблокувати, так само, як і Twitter; Власники серверів також можуть блокувати інші сервери; +- Міграція між серверами не є важливою та може бути здійснена лише за умови співпраці серверів. Це не працює в конфліктному середовищі (усі читачі втрачаються); +- Немає чітких стимулів для запуску серверів, тому їх зазвичай запускають ентузіасти та люди, які хочуть пов'язати своє ім'я з крутим доменом. В результаті користувачі піддаються деспотії однієї особи, що часто гірше, ніж у великої компанії типу Twitter, і вони не можуть мігрувати; +- Оскільки сервери часто запускаються недосвідчено, вони часто покидаються через певний час, що фактично еквівалентно блокуванню всіх; +- Немає сенсу мати безліч серверів, якщо оновлення з кожного сервера будуть болісно надсилатися (та зберігатися!) на безліч інших серверів. Ця проблема погіршується тим, що сервери мають тенденцію існувати у великій кількості, тому більше даних повинно передаватися більшому числу місць частіше; +- Щодо конкретного прикладу обміну відео, ентузіасти ActivityPub зрозуміли, що передача відео з сервера на сервер буде абсолютно неможливою таким чином, як передача текстових нотаток, тому вони вирішили зберігати відео лише на тому сервері, де воно було опубліковане, що схоже на підхід No + +### Проблема з SSB (Secure Scuttlebutt) + +- У нього немає багатьох проблем. Я вважаю, що він чудовий. Я збирався використовувати його як основу для цього, але +- його протокол занадто складний, тому що він зовсім не розглядався як відкритий протокол. Він просто був написаний на JavaScript, мабуть, швидким способом для вирішення конкретної проблеми, і відтоді розвивався, тому у ньому є дивні та непотрібні штуки, такі як підписання рядка JSON, який повинен строго дотримуватися правил [_ECMA-262 6th Edition_](https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify); +- Він наполягає на наявності ланцюжка оновлень від одного користувача, що, на мою думку, зайве, і це додає непотрібний об'єм і жорсткість до річі — кожен сервер/користувач повинен зберігати весь ланцюжок повідомлень, щоб переконатися, що нове повідомлення дійсне. Навіщо? (Можливо, у них є хороша причина); +- Він не такий простий, як Nostr, оскільки спочатку був створений для P2P-синхронізації, а "паби" були додатковою думкою; +- Проте, може варто розглянути використання SSB замість цього спеціального протоколу і просто адаптувати його до моделі клієнт-релейний сервер, тому що повторне використання стандарту завжди краще, ніж намагатися залучити людей до нового. + +### Проблема з іншими рішеннями, які вимагають, щоб кожен запускав власний сервер + +- Вони вимагають, щоб кожен запускав власний сервер; +- Іноді люди все ще можуть бути піддані цензурі в так From e992d7f765b41309460abd41e64b066ebfa66fe3 Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 14:11:46 +0800 Subject: [PATCH 76/77] Update README.md --- .../README.md" | 50 +++++++++++++++++-- 1 file changed, 47 insertions(+), 3 deletions(-) diff --git "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" index b604c2d..6755b9a 100644 --- "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" +++ "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" @@ -35,7 +35,8 @@ - Немає чітких стимулів для запуску серверів, тому їх зазвичай запускають ентузіасти та люди, які хочуть пов'язати своє ім'я з крутим доменом. В результаті користувачі піддаються деспотії однієї особи, що часто гірше, ніж у великої компанії типу Twitter, і вони не можуть мігрувати; - Оскільки сервери часто запускаються недосвідчено, вони часто покидаються через певний час, що фактично еквівалентно блокуванню всіх; - Немає сенсу мати безліч серверів, якщо оновлення з кожного сервера будуть болісно надсилатися (та зберігатися!) на безліч інших серверів. Ця проблема погіршується тим, що сервери мають тенденцію існувати у великій кількості, тому більше даних повинно передаватися більшому числу місць частіше; -- Щодо конкретного прикладу обміну відео, ентузіасти ActivityPub зрозуміли, що передача відео з сервера на сервер буде абсолютно неможливою таким чином, як передача текстових нотаток, тому вони вирішили зберігати відео лише на тому сервері, де воно було опубліковане, що схоже на підхід No +- Щодо конкретного прикладу обміну відео, ентузіасти ActivityPub зрозуміли, що повністю неможливо передавати відео з сервера на сервер таким чином, як текстові нотатки, тому вони вирішили зберігати відео лише на одному екземплярі, де воно було опубліковано, що схоже на підхід Nostr. + ### Проблема з SSB (Secure Scuttlebutt) @@ -47,5 +48,48 @@ ### Проблема з іншими рішеннями, які вимагають, щоб кожен запускав власний сервер -- Вони вимагають, щоб кожен запускав власний сервер; -- Іноді люди все ще можуть бути піддані цензурі в так +- Вони вимагають від кожного запускати свій власний сервер; +- Іноді люди все ще можуть бути піддані цензурі в таких випадках, оскільки доменні імена можуть бути піддані цензурі. + +## Як працює Nostr? + +- Є дві складові: __клієнти__ та __релейні сервери__. Кожен користувач запускає клієнт. Будь-хто може запустити релейний сервер. +- Кожного користувача ідентифікує відкритий ключ. Кожне повідомлення підписане. Кожен клієнт перевіряє ці підписи. +- Клієнти отримують дані від релейних серверів на свій вибір та публікують дані на інших релейних серверах на свій вибір. Релейний сервер не спілкується з іншим релейним сервером, а лише безпосередньо з користувачами. +- Наприклад, щоб "підписатися" на когось, користувач просто надає своєму клієнту інструкції щодо запитів до релейних серверів, які він знає, про повідомлення від цього відкритого ключа. +- При запуску клієнт запитує дані від усіх відомих релейних серверів для всіх користувачів, на яких він підписаний (наприклад, всі оновлення за останній день), а потім відображає ці дані користувачеві в хронологічному порядку. +- "Повідомлення" може містити будь-які структуровані дані, але найбільш вживані з них потраплять у стандарт, щоб усі клієнти та релейні сервери могли обробляти їх безшовно. + +## Як він вирішує проблеми, які мережі вище не можуть? + +- **Користувачі отримують бан, а сервери закриваються** + - Релейний сервер може заблокувати користувача від публікації будь-чого там, але це не вплине на них, оскільки вони все ще можуть публікувати на інших релейних серверах. Оскільки користувачів ідентифікують за допомогою відкритого ключа, вони не втрачають своїх особистостей та підписників, коли їх забанять. + - Замість того, щоб вимагати від користувачів вручну вводити нові адреси релейних серверів (хоча це також повинно підтримуватися), коли хтось, на кого ви підписані, публікує рекомендацію сервера, клієнт автоматично додає її до списку релейних серверів, які він запитує. + - Якщо хтось використовує релейний сервер для публікації своїх даних, але хоче перейти на інший, він може опублікувати рекомендацію сервера на попередньому релейному сервері та перейти; + - Якщо когось забанять на багатьох релейних серверах таким чином, що вони не можуть розповсюджувати свої рекомендації серверів, вони все ще можуть повідомити деяким близьким друзям через інші засоби з яким релейним сервером вони зараз публікують. Потім ці близькі друзі можуть опублікувати рекомендації сервера на новому сервері, і поступово стара база підписників заблокованого користувача почне знаходити їхні повідомлення знову з нового релейного сервера. + - Все зазначене вище також діє, коли реле припиняє свою роботу. + + +- **Стійкість до цензури** + - Кожен користувач може публікувати свої оновлення на будь-якій кількості релейних серверів. + - Релейний сервер може стягувати плату (переговори про цю плату наразі за межами протоколу) від користувачів за публікацію там, що забезпечує стійкість до цензури (завжди буде деякий російський сервер, який готовий приймати ваші гроші в обмін на розміщення ваших повідомлень). + +- **Спам** + - Якщо спам становить проблему для релейного сервера, він може вимагати оплату за публікацію або якусь іншу форму автентифікації, таку як електронна адреса чи телефон, і пов'язувати їх внутрішньо з відкритим ключем, який потім отримує право публікувати на цьому релейному сервері - або інші анти-спам техніки, як хеш-гроші чи капча. Якщо релейний сервер використовується як вектор спаму, його можна легко виключити зі списку клієнтів, які можуть продовжувати отримувати оновлення з інших релейних серверів. + +- **Зберігання даних** + - Для того, щоб мережа залишалася здоровою, не потрібно сотень активних релейних серверів. Насправді, вона може працювати нормально лише з декількома, враховуючи те, що нові релейні сервери можуть створюватися та поширюватися мережею легко у разі, якщо існуючі релейні сервери починають поводитися неналежним чином. Тому загальний обсяг зберігання даних, який потрібен, є відносно меншим, ніж у Mastodon чи подібному програмному забезпеченні. + - Або розглядаючи інший результат: один, в якому існує сотні нішевих реле, керованих аматорами, кожен з яких передає оновлення від невеликої групи користувачів. Архітектура масштабується так само добре: дані надсилаються від користувачів до одного сервера, а з цього сервера безпосередньо користувачам, які споживатимуть ці дані. Це не повинно зберігатися кимось іншим. В такій ситуації для будь-якого окремого сервера не є великим навантаженням обробляти оновлення від інших, і наявність аматорських серверів не є проблемою. + +- **Відео та інший важкий контент** + - Для реле легко відхилити великий контент або стягувати плату за прийняття та розміщення великого контенту. Коли інформація та стимули ясні, ринкові сили легко вирішують проблему. + +- **Техніки обману користувача** + - Кожен клієнт може вирішити, як найкраще показувати повідомлення користувачам, тому завжди є можливість просто споживати те, що ви хочете, так, як ви хочете - від використання штучного інтелекту для визначення порядку оновлень, які ви побачите, до їх читання в хронологічному порядку. + +## ЧАП + +- **Це дуже просто. Чому ніхто раніше цього не робив?** + + Я не знаю, але я думаю, що це пов'язано з тим, що люди, які створюють соціальні мережі, є або компаніями, які хочуть заробляти гроші, або активістами P2P, які хочуть створити щось повністю без серверів. Вони обидва не бачать специфічного поєднання обох світів, яке використовує Nostr. + From dd659550dcfa7d5cad6b5d4d865cef962c85a284 Mon Sep 17 00:00:00 2001 From: Eugene Date: Mon, 27 Mar 2023 14:18:49 +0800 Subject: [PATCH 77/77] Update README.md --- .../README.md" | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" index 6755b9a..c2a9448 100644 --- "a/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" +++ "b/translate/\321\203\320\272\321\200\320\260\321\227\320\275\321\201\321\214\320\272\320\260/README.md" @@ -93,3 +93,34 @@ Я не знаю, але я думаю, що це пов'язано з тим, що люди, які створюють соціальні мережі, є або компаніями, які хочуть заробляти гроші, або активістами P2P, які хочуть створити щось повністю без серверів. Вони обидва не бачать специфічного поєднання обох світів, яке використовує Nostr. +- **Як знайти людей, яких слідувати?** + + Спочатку вам потрібно знати їх та отримати їх відкритий ключ якимось чином, наприклад, запитавши або побачивши його посилання десь. Коли ви будете всередині соціальної мережі Nostr, ви зможете бачити, як вони взаємодіють з іншими людьми, і тоді ви також зможете почати слідувати та спілкуватися з цими іншими. + +- **Як знайти реле? Що станеться, якщо я не підключений до тих самих реле, що й хтось інший?** + + Ви не зможете спілкуватися з цією людиною. Але є підказки про події, які можна використати, щоб ваше клієнтське програмне забезпечення (або ви, вручну) знало, як підключитися до реле іншої людини та взаємодіяти з ними. В майбутньому є інші ідеї, як це вирішити, але ми не можемо гарантувати ідеальну досяжність, жоден протокол не може. + +- **Чи можу я знати, скільки людей слідують за мною?** + + Ні, але ви можете отримати деякі оцінки, якщо реле співпрацюють у спосіб, що виходить за рамки протоколу. + +- **Яка мотивація для людей запускати реле?** + + Запитання вводить в оману. Воно припускає, що реле - це безкоштовні "тупі труби", які існують для того, щоб люди могли передавати дані через них. В такому випадку, так, мотивація не існувала б. Насправді, це можна сказати про вузли DHT у всіх інших стеках p2p-мереж: яка мотивація для людей запускати вузли DHT? + +- **Nostr дозволяє вам переходити між реле серверами або використовувати кілька реле, але якщо ці реле просто на AWS або Azure, то яка різниця?** + + На сьогоднішній день по всьому світу розкидано буквально тисячі провайдерів VPS, існують не лише AWS та Azure. Саме AWS або Azure є провайдерами, які використовуються централізованими послугами з єдиним сервером, яким потрібно багато масштабів, і навіть тоді не лише ці два. Для менших реле-серверів будь-який VPS добре впорається з роботою. + +## Специфікація протоколу + +Дивіться [NIPs](https://github.com/nostr-protocol/nips) і особливо [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) для розумного детального пояснення специфікації протоколу (підказка: він дуже короткий та простий). + +## Програмне забезпечення + +Список більшості програмного забезпечення, яке створено на основі Nostr, можна знайти на https://github.com/aljazceru/awesome-nostr, що, здавалося б, був майже повним останнім часом, коли я дивився. + +## Ліцензія + +Домен публічний.