By @AtropineTears with NightshadeLabs | 2 April 2022
We live in a period of time where security and privacy are slowly eroding while censorship is becoming increasingly more prevalent. We live in a time where social media spies on us, selling our information to the world and top-bidding advertisers. We live in a time where you may get banned on twitter for just stating your beliefs. We already know the power of the internet and how much of an effect it can have on the world around us, but many of us are blissfully unaware of the problems inherent in the internet and social media as a whole.
Introducing nostr, a simple and easy to use platform for decentralized, censorship-resistant communications similar to twitter but with privacy, security, and censorship-resistant properties.
Censorship-Resistant
Decentralized
No Ads
No Banning of Accounts
User Identity Tied To Public Key As Opposed To Username
Chronological Ordering of Posts
Incentive To Run Relay
Does Not Use Predatory Social Media Techniques To Keep You Addicted To It
"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." - 1
Basically, every relay is independent and makes choices by itself. A relay can choose to block someone but then that person can easily just go to another relay that will not block them. Relays do not speak to each other. Instead, they only speak to users.
"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." - 1
No comment.
Nostr works by using cryptographic keys and digital signatures so that posts are tamperproof and their integrity is intact. It uses two types of software, client and relay. The client is used to send events while the relay is used to get updates from other people. To publish something, you write the post, sign it with your key, and send it to multiple relays.
Every user is identified by their public key as opposed to usernames. Clients validate signatures for themselves as opposed to having relays verify them.
Clients fetch data from a relay of their choosing and publish data to the relay(s) of their choosing.
The interesting part about nostr is that any relay can choose how to best serve content to the user like using AI to better serve content in a more personalized manner.
"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." - 1
A client is used to get resources from a relay.
Anyone can run a relay. - 1
A relay is very simple and dumb - 1
Relays expose a websocket endpoint to which clients can connect (using wss://). They can send three types of messages (but must be JSON Arrays).
A relay only talks to a user, not other relays.
Event.idThe Event ID is the SHA256 serialized event over UTF-8 JSON-serialized string
The only object type that exists is the event. It contains:
id: 32-byte SHA256 of serialized event data
pubkey: 32-byte hex-encoded (lowercase) public key of event creator
created_at: unix-timestamp in seconds (as a number)
kind: <insert integer> (as a number)
tags: (as an array of arrays of strings)
content: <arbitrary string> (as a string)
sig: 64-byte signature of the SHA256 hash of the serialized event data ("id" field)
Nostr uses Schnorr Signatures over secp256k1 curve using SHA256 hash function.[3] This is the same algorithm used by Bitcoin.
Schnorr signatures are provably secure, non-malleable, and linear.
Nostr uses UTF-8 JSON for serialization.
There are two types of software.
The client is run by everyone. The client can be a native client, web client, or other.
The relay is used to get updates from other people and is simplistic in design. In other word
A Client can send 3 types of messages (must be JSON arrays) as specified in NIP-01 and which is extendable by other NIPS. The following 3 types of messages are:
[EVENT, <event JSON as defined below at '[Message] Event'>]
[REQ, <subscription_id>, <filters JSON>...]
[CLOSE, <subscription_id>]
"The only object type that exists is the
event" - 2
The event contains the following:
{ "id": <32-bytes sha256 of the the serialized event data>, "pubkey": <32-bytes hex-encoded public key of the event creator>, "created_at": <unix timestamp in seconds>, "kind": <integer>, "tags": [ ["e", <32-bytes hex of the id of another event>, <recommended relay URL>], ["p", <32-bytes hex of the key>, <recommended relay URL>], // other kinds of tags may be included later ] "content": <arbitrary string>, "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>,}wss://)Components:
Type Of Events:
EVENT
["EVENT", <event JSON as defined in '[Message] Event'>]REQ
["REQ", <subscription_id>, <filters JSON>...]CLOSE
["CLOSE", <subscription_id>]Type of Events:
EVENT
["EVENT", <subscription_id>, <event JSON as defined in '[Message] Event'>]NOTICE
NOTICE messages should be sent or treated (as of NIP-01)["NOTICE", <message>]