NOSTR — Notes and Other Stuff Transmitted by Relays
- nostr — Notes and Other Stuff Transmitted by Relays
- very short summary, for grug who already eyeing exit
- why need this?
- problem with Twitter
- problem with Mastodon and similar programs
- problem with SSB (Secure Scuttlebutt)
- problem with solutions requiring everybody run own server
- how does Nostr work?
- how Nostr solve problems others cannot?
- users getting banned and servers being closed
- censorship-resistance
- spam
- data storage
- video and other heavy content
- techniques to trick user
- FAQ
- this is very simple. why has nobody done it before?
- how do grug find people to follow?
- how do grug find relays? what if grug not connected to same relays as somebody else?
- can grug know how many people follow grug?
- what incentive exists for people to run relays?
- Nostr lets users move between relays or use many relays, but what difference if relays all run on AWS or Azure?
nostr — Notes and Other Stuff Transmitted by Relays
nostr is very simple open protocol for make global “social” network that censorship club have hard time smashing.
goal: solve social network problem once and for all.
bold goal. many big brain say such thing before, then build seven committees and login page not work. but nostr idea actually small.
nostr not depend on one trusted central cave server. good. if king of cave go mad, network not immediately die.
nostr use cryptographic keys and signatures. each post carry special math scratch proving who make it. sneaky grug cannot change words later without math scratch becoming wrong and client yelling DANGER, FAKE ROCK.
nostr also not depend on P2P techniques.
therefore, somehow, it work.
very short summary, for grug who already eyeing exit
everybody run client.
client can be native client, web client, or other thing with buttons.
when grug want publish post:
- grug write post.
- grug sign post with key.
- grug throw signed post at several relays.
relay is server run by other grug, or by grug himself if grug enjoy server chores and losing sleep.
when grug want updates from people:
- grug ask several relays, “you see anything from these public keys?”
- relays hand over what they know.
- grug client verify signatures.
- grug read argument about money, politics, and whether pineapple belong on mammoth meat.
anyone can run relay.
relay is simple and dumb. this compliment.
relay mostly accept posts from some grugs and forward posts to other grugs. relay not need understand meaning. relay not need become Ministry of Correct Thought. relay not need be trusted.
client check signatures itself.
simple pipe good. pipe not need philosophy degree.
why need this?
because other solutions broken in many creative ways.
problem with Twitter
Twitter have ads.
Twitter use bizarre mind tricks to keep grug poking glowing rectangle until sun rise and young grugs ask where breakfast is.
Twitter not show actual historical feed from people grug follow. Twitter instead show what invisible engagement shaman think make grug angriest.
Twitter ban people.
Twitter shadowban people, which is ban wearing invisible leaf hat.
Twitter have much spam.
many fake trader grugs offer impossible return on shiny rocks.
very bad.
problem with Mastodon and similar programs
Mastodon better in some ways, but still have cave ownership problem.
user identity attached to domain name controlled by third party.
this mean grug identity live on somebody else’s cave sign.
cave owner can ban grug, same as Twitter.
cave owner can also block whole other cave because cave chiefs have feud, maybe over serious policy matter, maybe because one chief use wrong fork at conference. user still suffer either way.
migration between servers is afterthought.
migration work only when servers cooperate.
in friendly world, perhaps okay.
in adversarial world, no. old server can refuse help, followers disappear, grug carry little cardboard box to new cave and discover tribe no longer know where grug live.
all followers lost.
also no clear incentive to run servers.
therefore servers often run by enthusiasts or grugs who want name attached to cool domain.
enthusiast grug begin with strong spirit:
“grug maintain community forever!”
six months later enthusiast grug tired, bill arrive, database on fire, and enthusiast grug discover pottery hobby.
now users subject to rule of one cave owner. sometimes this despotism worse than large company like Twitter because company at least have lawyers, procedures, and many frightened managers. hobby cave may have one angry grug with root password and no sleep.
users cannot reliably migrate out.
amateur servers often abandoned after while.
this is effectively same as banning everybody, only ban caused by unpaid invoice and forgotten password.
federation also have movement-of-data problem.
having many servers sound nice. but updates from every server must be painfully pushed to, and saved by, many other servers.
more servers mean more data carried to more places more often.
many messenger birds.
many dead messenger birds.
many disks full of posts from person nobody on local server follow.
for video, ActivityPub enthusiasts discover server-to-server copying of large video would be completely impossible unless every server owner possess oil kingdom.
so video stay hosted only on original instance where posted.
this is similar to Nostr approach.
grug look at this and make thinking face.
problem with SSB (Secure Scuttlebutt)
SSB not have many problems.
grug think SSB great.
in fact, original nostr thinker nearly use SSB as base.
but several rocks in path.
first, SSB protocol too complicated because it not originally designed as open protocol.
it was written in JavaScript, probably quickly, to solve specific problem. then it grew.
many software begin as small hut.
then six winters pass and hut have underground railway, ceremonial chimney, seventeen load-bearing callbacks, and nobody remember why west door open only on Tuesday.
SSB therefore have strange unnecessary quirks.
example: signing JSON string that must strictly obey rules of ECMA-262 6th Edition.
grug hear this and hand slowly reach toward club.
grug remain calm.
second, SSB insist each user have chain of updates.
each new update link to earlier update.
this feel unnecessary and add bloat and rigidity.
each server or user must store entire chain of posts to confirm new post valid.
why?
maybe good reason. grug admit uncertainty. grug not know all sacred Scuttlebutt lore.
third, SSB not as simple as Nostr.
SSB mainly made for P2P syncing. “pubs” added later as afterthought.
still, maybe wiser to use SSB instead of new custom protocol and adapt SSB to client-relay server model.
reusing standard usually better than persuading tribe to learn another new rune alphabet.
grug hate unnecessary new standard almost as much as grug enjoy naming new standard.
difficult inner conflict.
problem with solutions requiring everybody run own server
they require everybody run own server.
this sentence appear obvious, but big brains often walk past obvious thing while looking for distributed consensus theorem.
most people not want run server.
most people barely want update phone.
also, domain names can be censored.
so even own-server system may still have choke point wearing DNS hat.
how does Nostr work?
two main pieces:
- clients
- relays
each user run client.
anyone can run relay.
every user identified by public key.
not username owned by one company.
not identity chained to one domain.
public key is identity.
every post signed.
every client validate signature.
relay can say anything, but client check math.
good arrangement. trust math scratch more than random cave landlord.
clients fetch data from relays they choose.
clients publish data to relays they choose.
same relays not required for both.
relay never talk to another relay.
relay talk directly to users only.
no giant federation gossip ritual where ten thousand servers shout every post at one another until network become hot.
to “follow” someone, user tell client:
“ask relays grug know for posts signed by this public key.”
on startup, client query all known relays for data from all followed users.
for example, client request all updates from last day.
client combine results and display chronologically.
simple timeline.
oldest thing first, newest thing later.
no invisible attention goblin rearrange feed because argument post make number go up.
a “post” can contain any kind of structured data.
over time, common post types likely become standards so clients and relays handle them smoothly.
tribe repeatedly use same shape of rock, eventually tribe agree this is bowl.
standard born.
how Nostr solve problems others cannot?
users getting banned and servers being closed
relay can block user from publishing there.
relay owner allowed control own relay.
but ban affect only that relay.
user still publish to other relays.
because user identity is public key, user not lose identity when relay ban them.
user also not lose follower base merely because one server chief throw tantrum and pull lever marked BAN GRUG FOREVER.
followers still follow same public key.
only location of posts change.
clients should support manual relay addresses, but making every user type relay runes is poor plan. most grugs forget password while password still visible.
better method: relay recommendations.
when someone grug follow publish server recommendation, client automatically add recommended relay to list of relays it queries.
so people help clients discover where tribe members now publish.
when user want migrate away from old relay:
- user publish server recommendation to old relay.
- recommendation say where new relay is.
- user leave.
- followers’ clients learn new location.
clean exit, assuming old relay still cooperate.
what if user banned from many relays and cannot broadcast recommendation?
then user tell close friends through another method.
smoke signal.
email.
message.
shouting across conference hall.
close friends then publish recommendations pointing to new relay.
their followers discover it.
some of banned user’s old followers see recommendation and begin finding posts again.
slowly old follower base reconnect.
information spread through social graph like useful cave rumor.
same method work when relay stops operating.
relay die, identity not die.
important difference.
cave collapse. grug still grug.
censorship-resistance
each user can publish updates to any number of relays.
one relay reject post? publish elsewhere.
ten reject? seek eleven.
relay can charge fee for publishing.
how fee negotiated is outside protocol for now.
payment creates incentive for censorship-resistant hosting.
there will always be some Russian server willing to take grug’s money in exchange for serving posts.
perhaps server have alarming control panel and support email answered at 3:17 a.m., but post remain online.
market find path where moral committee not.
spam
relay worried about spam can require payment before publication.
spam grug love free megaphone.
spam grug less enthusiastic when each scream cost shiny rock.
relay could also require some authentication:
- email address
- phone number
- hashcash
- captcha
- other anti-spam technique
relay can associate authentication internally with public key allowed to publish there.
this not need become universal identity rule for whole network. it is local relay policy.
if relay become spam cannon, clients can unlist it.
clients continue fetching useful updates from other relays.
bad relay get ignored.
spam grugs shout into empty cave.
good.
data storage
network not need hundreds of active relays to remain healthy.
handful can work fine.
if existing relays begin misbehaving, new relays can be created and addresses spread through network easily.
therefore overall storage burden can be lower than Mastodon and similar systems.
not every server need store everything from every other server.
another possible future also work:
hundreds of niche relays run by amateurs.
each relay serve small group of users.
architecture still scale.
data travel from user to one server, then from that server directly to users who consume it.
other servers not need store copy.
relay for cave-painting enthusiasts not need archive every argument from mammoth-investment relay.
good separation.
in this world, no single server carry huge burden processing updates from all others.
amateur server not automatically problem because amateur server job remain small.
small cave easier sweep.
video and other heavy content
relay can reject large content.
very reasonable.
relay see 14-gigabyte video of grug opening mystery rock boxes and say, “no.”
relay can also charge money for accepting and hosting large content.
when cost and incentive clear, market can solve problem.
heavy rock cost more to carry.
even young grug understand.
no need invent federation ritual where every village must copy entire boulder.
techniques to trick user
each client decide how posts shown.
client could use AI to choose order.
client could use chronological order.
client could offer filters, rankings, or whatever user choose.
important part: no single network owner decide for everyone.
grug may choose clever feed.
grug may choose plain feed.
grug may choose feed that show only posts containing dinosaur.
freedom sometimes weird, but still freedom.
FAQ
this is very simple. why has nobody done it before?
grug not know.
possible reason: people building social networks usually belong to one of two tribes.
first tribe: company want make money.
company say “engagement” many times, then build slot machine around human friendship.
second tribe: P2P activists want system with absolutely no servers.
server considered impure spirit.
both tribes miss useful mixture.
nostr use clients plus simple relays.
not giant trusted central server.
not pure P2P maze.
middle path.
big brain often dislike middle path because no conference talk title.
but middle path sometimes work.
how do grug find people to follow?
first, grug must know person and obtain public key somehow.
ask them.
see key referenced somewhere.
receive it through another channel.
after grug enter Nostr social network, grug see followed people interacting with others.
then grug discover those others.
grug follow some.
tribe grow through visible interaction.
same as village, except nobody need remember forty-eight-character public key by smell.
client hopefully help.
how do grug find relays? what if grug not connected to same relays as somebody else?
then grug cannot communicate with that person.
this limitation real.
no magic claim.
events can contain hints telling client, or grug manually, which relay other person use.
client can connect there and interact.
there are more ideas for improving discovery in future.
but perfect reachability cannot be promised.
no protocol can promise it.
sometimes messenger bird not know cave.
sometimes cave underwater.
sometimes other grug simply unplug server to run hot-stone cooker.
such is network life.
can grug know how many people follow grug?
no.
not exactly.
grug can estimate if relays cooperate using extra-protocol methods.
but no central follower-counter oracle know absolute truth.
influencer grug may suffer.
perhaps healthy.
what incentive exists for people to run relays?
question assume relays are free dumb pipes existing only to move data.
under that assumption, yes, incentive look missing.
but assumption not required.
relays can charge, serve communities, support organizations, enforce local policies, provide specialized service, or exist for owner’s own use.
same incentive question applies to DHT nodes in other P2P network stacks:
what incentive exist for people to run DHT nodes?
many systems already depend on grugs voluntarily keeping strange boxes humming.
internet built from many such questionable decisions.
Nostr lets users move between relays or use many relays, but what difference if relays all run on AWS or Azure?
there are literally thousands of VPS providers scattered across globe.
not only AWS and Azure.
AWS and Azure are especially common for large centralized service providers needing much scale, and even those providers not necessarily use only these two.
small relay server not need giant cloud kingdom.
almost any VPS can do job well.
one relay on provider A.
another on provider B.
another in basement of determined Finnish grug beside washing machine.
many places.
many operators.
many failure domains.
Nostr not make infrastructure magically immune to pressure, fire, seizure, bad billing card, or grug spilling fermented berry drink on router.
but it remove requirement that whole social network kneel before one central cave.
that is difference.
one king can close one gate.
much harder close every gate.
grug approve.
Write a comment