Nostr notes by leon

obelisk.ar implements post-quantum dms via nostr-wot already ...

2026-08-19T15:32:52+02:00

In reply to nevent1q…qgur
_________________________

obelisk.ar implements post-quantum dms via nostr-wot already

https://primal.net/e/naddr1qvzqqqr4gupzqsvm0hctquqmcaw85yzhyf2fm5tzyrzp7508nkftw6tadecjgxq6qq38qmmnwskhzatpde682mfdv3khxttfdckk7cn9d35hx6edvdkxjetwwsxx2p45

obelisk.ar DMs are post-quantum encrypted as of this week. keys ...

2026-08-19T15:31:14+02:00

obelisk.ar DMs are post-quantum encrypted as of this week. keys come from the seed phrase you already have (or should create), messages ride inside ordinary NIP-17 gift wrap, and no relay had to change anything

reading them needs no negotiation: the envelope says what it is. sending needs one cached relay query. for most clients this is an afternoon of work

it is opt-in today because a Nostr identity is a secp256k1 key and nothing else, with no algorithm field. we already version NIP-44 payloads. the idea is in the protocol, it just has not reached the key

formats are public drafts. argue with them before a second client ships against them

https://quantakrypto.com/blog/obelisk-first-nostr-client-post-quantum-dms

quoting
naddr1qv…v2j5

Obelisk direct messages are post-quantum encrypted as of this week. Not a demo, not a testnet, not a branch. If you and the person you are writing to have both published post-quantum keys, the message that leaves your client is protected against an adversary who records it today and breaks secp256k1 in fifteen years.

It took no relay changes, no protocol fork, and no new seed phrase for anyone. That is the interesting part, and it is why I think the rest of the ecosystem can follow quickly if we decide to.

What is running

Post-quantum keys come from the seed phrase you already have. They are derived from the BIP-39 seed as siblings of your secp256k1 key, never from the key itself. That direction is the whole security property: if the post-quantum key could be computed from your Nostr private key, then Shor recovers your private key from your published pubkey, runs the same derivation, and takes the post-quantum key with it. Circular, and worth nothing.

Because it cannot be derived, it gets announced. You publish a kind:10203 event carrying an ML-KEM-1024 encryption key and an ML-DSA-87 signing key, signed by your ordinary Nostr key, with a proof of possession binding all three together. Anyone writing to you reads it off a relay.

The message is an ordinary NIP-17 gift wrap. Inside the seal, the payload combines an ML-KEM shared secret with the normal NIP-44 conversation key through HKDF. Hybrid, never replacement: if ML-KEM turns out to be broken tomorrow you are back to exactly the NIP-44 you have today, which is where every client already is. There is no version of this where you end up worse off.

Cost is about 3 KB per message and roughly a millisecond to encrypt. Clients that have not implemented it are completely unaffected, because the new part sits inside a layer they could not read anyway.

The one gap worth closing

Right now this is opt-in. You publish keys, the other person publishes keys, and until both happen nothing improves.

I do not think that should be the end state, and I want to be straight about why it is the current one. A Nostr identity is a secp256k1 keypair and nothing else. Your npub is the public half of one specific key on one specific curve. There is no algorithm identifier beside it and no key set, so the protocol cannot express "this identity uses algorithm X". A sender cannot look at an npub and learn anything about what it can receive, which means somebody has to ask, and asking is what makes it opt-in.

The encouraging part is how narrow that gap is. We already solved the same problem one layer up: NIP-44 is versioned, its payloads lead with a version byte precisely so the scheme can change without breaking readers. The idea is already in the protocol and already accepted. It just has not reached the key yet.

That is a much better position than it sounds. This is not a missing concept, it is a missing field.

Why incremental is the right move, not a compromise

The complete fix is an identity that declares its own key set, with algorithm identifiers and rotation. I want that, and I think it is where we end up.

It is also a change that reaches signatures, and an ML-DSA-87 signature is 4,627 bytes on every event. That is a relay storage and bandwidth question, so relay operators have to be at the table alongside client developers. It needs a NIP, review, several implementations, and a transition that strands nobody. That is a real conversation and it deserves the time it takes.

Meanwhile confidentiality is the half of the problem with an expiry date. Protection against a future break can only be applied before a message is sent, never afterwards, so every day we wait is traffic that no later fix can reach.

The two things run on different clocks. That is the whole argument for doing both rather than choosing.

And the incremental step costs us nothing later, which is the test I would apply to any interim measure. The keys come from the seed people already have. No new identity, no second phrase, nothing extra in a backup. When a proper key-set declaration lands, the same seed derives whatever it needs, and for the person using it migration is a click with their history and identity intact.

If we secure messages today, that is a win. If tomorrow we migrate, it is a click. Those are not in tension, and nothing here has to be undone.

What migrating actually takes

This is the part I would like people to look at, because it is much smaller than it sounds.

If you build a client. Reading post-quantum messages requires no negotiation and no flag: the envelope leads with a version byte and an algorithm byte, so you inspect the payload and route it. Sending needs the recipient's key from their kind:10203, which is one relay query you can cache for hours. The reference implementation is on npm as @nostr-wot/pq and the wire format is a public draft. Realistically this is an afternoon, not a quarter.

If you run a relay. Nothing changes for messages, since post-quantum payloads are ordinary kind:1059 gift wraps of a slightly unusual size. The one thing to check is the attestation: kind:10203 is about 12 KB, and one relay in our four-relay test set rejects it on size. If your limits would drop it, users on your relay silently cannot be reached post-quantum, and neither they nor the sender find out why.

If you maintain a signer. Two things. Derive the keys as siblings from the seed, never from the private key. And advertise what you accept, so a client can ask instead of guessing: a signer that silently ignores a post-quantum request and returns ordinary ciphertext leads to clients showing protection badges over unprotected messages, which is worse than not supporting it at all.

If you use Nostr. Publish your keys. It is one button in the Nostr WoT extension and takes about five seconds, and it is the only step that has to happen per person rather than per project.

What I am asking for

The formats are four public drafts in the extension repo under nips/: key derivation, the kind:10203 attestation, the hybrid NIP-44 envelope, and the signer capability marker. None has a NIP number. They are drafts so that someone can tell me the wire format is wrong before a second client ships against it, and I would genuinely rather hear that now.

Three things help more than agreement:

Read the envelope draft and argue with it. Changing it is cheap today and expensive once anyone else has shipped.

If you run a relay, tell me whether 12 KB attestations pass. I have four data points and that is not enough to design around.

If you are working on identity and key sets, I would rather this attestation be replaced by your work than persist beside it. Tell me what shape to build toward and I will build toward it.

The outcome I want to avoid is a Nostr where post-quantum protection is five incompatible bolt-ons, each solved privately. That is the default result if we all move separately, and it is avoidable if the identity layer moves before the workarounds harden.

We can protect messages this month and still design the right thing properly. I would like to do both.

Obelisk: https://obelisk.ar

Drafts: https://github.com/nostr-wot/nostr-wot-extension/tree/main/nips

Longer write-up: https://nostr-wot.com/blog/opt-in-quantum-resistant-direct-messages

QuantaKrypto: https://quantakrypto.com/blog/obelisk-first-nostr-client-post-quantum-dms

somebody is collecting your encrypted messages. storing them to ...

2026-08-11T11:22:09+02:00

somebody is collecting your encrypted messages. storing them to read them 10 years from now. that's the whole attack. wake up

quoting
naddr1qv…wum8

Read first: https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later

Someone is copying your encrypted messages right now. Not breaking them. Copying them.

That is the whole attack. It does not need a quantum computer today. It needs a hard drive today and a quantum computer eventually. Every NIP-44 message you have ever sent, sitting on relays, publicly retrievable, encrypted with a scheme that will not hold. The people doing this are not waiting for permission and they are not in a hurry.

It has a name, "harvest now decrypt later", and the fact that it has a name should tell you how long people have known.

Why Nostr specifically

Your public key is published to every relay you touch. That is not a flaw, it is the entire design. It is how anyone verifies your notes.

It is also the input to the attack. Shor's algorithm recovers a private key from a public key. Most systems at least make an adversary work to obtain the public key first. Nostr hands it over, to everyone, permanently, by default.

NIP-44 derives its conversation key from an ECDH shared secret between two secp256k1 keys. Recover either private key and you recover the conversation key. Recover the conversation key and you decrypt every message in that conversation, all the way back to the first one.

There is no forward secrecy in that construction to save you. There is no key rotation that helps, because the messages were already captured under the old key. There is nothing you can publish tomorrow that protects what you sent yesterday.

The part I cannot get people to hear

When I raise this, the answer is almost always some version of "quantum computers aren't here yet."

That is not a rebuttal. That is the premise.

The deadline is not when the machine arrives. The deadline is how long your message needs to stay secret, counted backwards from when the machine arrives. If you send something today that would still embarrass you, endanger you, or cost you money in twelve years, and the machine shows up in ten, you already missed it. You missed it at the moment you hit send.

So the question is not "when is Q-day". The question is: what did you say last week that still matters in 2036?

For most people the honest answer is "some of it". Not all of it. Some of it. Which is enough.

And it is not only your judgement that is at stake. Every person who messaged you did so believing the thing on the label. They looked at a lock icon, or a client that said encrypted, and they decided what to tell you based on that. If the encryption does not hold, you did not just lose your own privacy. You lost theirs, on their behalf, without asking them.

That is the part that actually bothers me. My own messages I can be philosophical about. I cannot be philosophical about someone else's.

Why this has stayed unfixed for a year

It is not that nobody noticed. Paul Miller opened the issue in July 2025. fiatjaf, Vitor Pamplona and Mike Dilger have all been in that thread. These are not people who miss things.

It stalled on something real. The obvious fix is to derive a post-quantum key from your Nostr private key:
pq_key = KDF(nsec)
That is circular and it buys you nothing. An adversary recovers your nsec from your npub, runs the same KDF, and now has your post-quantum key as well. You added computation and no security.

That objection killed every proposal. Working prototypes existed. A specification did not.

The fix is a change of shape, not of algorithm

Do not derive from the nsec. Derive from the seed.

NIP-06 already takes you from a BIP-39 mnemonic to your Nostr key at m/44'/1237'/0'/0/0, through HMAC-SHA512, which is one-way. Given the resulting private key you cannot walk back to the seed.

So take that same seed and expand it a second time, with domain separation, into post-quantum keys:
kem_seed = HKDF-SHA256(seed, info = "nip-pqc/v1/ml-kem-1024/0", 64)
dsa_seed = HKDF-SHA256(seed, info = "nip-pqc/v1/ml-dsa-87/0", 32)

Both keys are children of the seed. Neither is a child of the other. They are siblings.

An adversary who breaks secp256k1 and recovers your Nostr private key learns nothing about the seed, because that would mean inverting HMAC-SHA512. So they learn nothing about your post-quantum keys. Messages encrypted to your ML-KEM key stay confidential permanently, even after your identity key is gone.

And your words never change. The same mnemonic restores your Nostr key and both post-quantum keys. There is no new backup, no re-enrolment, no "generate a fresh identity and rebuild your social graph", which is the migration nobody ever completes.

The rest of the design, briefly

Keys go in a kind:10203 replaceable event, not in your kind:0 profile. Clients rebuild profile JSON from the fields they know about and republish it, so the first time you changed your display name in a client that had not implemented this, your post-quantum key would vanish silently. You would still think you were reachable. Senders would quietly fall back to classic encryption. A security feature that fails silently is worse than one that is not there.

The ML-DSA key counter-signs a proof of possession binding your npub to both public keys. A secp256k1 signature proves you published those bytes. It does not prove you hold the matching post-quantum secrets. Without the counter-signature you could advertise a key you cannot decrypt with, by bug or on purpose, and people would send you messages nobody can read.

The post-quantum secret is combined with the existing NIP-44 conversation key through HKDF. Never used alone. Lattice schemes are young and they do break, HAWK fell in July. A flaw in a new scheme must not be able to make Nostr messaging worse than it is today.

Everything rides inside NIP-59 gift wrap, unchanged. The outer layers stay secp256k1, so these messages cross today's relay network with no modifications, and clients that know nothing about any of this are unaffected. No relay changes. No flag day.

It is not a proposal, it is running

I am tired of design documents, so we shipped it.

There is a demo at nostr-wot.com/pqc/chat that generates two identities in your browser, publishes their attestations to damus, nos.lol, primal and snort, reads each other's ML-KEM keys back off those relays, and exchanges real post-quantum gift wraps.

Nothing is simulated. A message only appears once a relay hands it back and it decrypts, and each one names the relay that served it. You can take any event apart layer by layer, the kind:1059 wrap a relay actually stores, the kind:13 seal inside it, the envelope with a byte map, and the kind:14 rumor at the centre. Layers your browser holds no key for are marked sealed rather than guessed at, so you can switch accounts and see the same event from a different vantage.

Publishing it for real also taught us something estimating would not have. One of those four relays rejects the 12,200-byte attestation outright, on size. Three accept it, so discovery still works, but that is a real constraint and it is in the spec now rather than in someone's incident report next year.

The browser extension is released. The library is on npm as @nostr-wot/pq. New identities default to 24 words, because 12 words carry 128 bits of entropy and that would make your seed the weak link instead of the lattice. That change costs nothing today and cannot be applied retroactively, which is exactly why it has to happen now.

What this does not do

An adversary with a quantum computer can still sign events as you. Events are still signed with secp256k1. They could also publish a replacement attestation carrying their own keys and intercept your future messages.

This protects past messages, permanently. It does not protect future messages against someone who has already broken secp256k1.

Signature migration is a separate and harder problem. An ML-DSA-87 signature is 4,627 bytes, roughly 6.2 KB base64, on every event. That is a several-fold increase in relay storage and bandwidth for a short note, and it is a decision that needs relay operators at the table, not something a client ships unilaterally.

Publishing the ML-DSA verification key now is what keeps that door open. The commitment exists, signed by your classic key, from before the break. So when signatures eventually migrate, nobody needs a new seed phrase.

I would rather say all of that plainly than let the claim inflate. If someone tells you their post-quantum scheme fixes everything, they have not understood which half of the problem is fixable after the fact.

What to do

If you hold 24 words, you can be post-quantum today. One button in the Nostr WoT extension derives the keys and publishes the attestation. Nothing new to back up.

If you hold a bare nsec, the spec covers you too, with standalone keys marked origin: independent. They need their own backup, which is worse than derived keys and enormously better than nothing.

If you are building a client, the reference implementation is open and the NIP is drafted. Take it apart. Tell me what is wrong with it. I would much rather be corrected now than have this be right and ignored.

And if you do nothing else: stop treating this as a 2035 problem. The messages that will be read are the ones being sent this week.

Written by the Nostr WoT and QuantaKrypto teams. Demo: nostr-wot.com/pqc/chat

Check whether someone supports it: nostr-wot.com/pqc Full write-up: quantakrypto.com/blog/post-quantum-identity-keys-for-nostr

just launched Nostr Widgets, server-rendered svg widgets for ...

2026-04-28T03:45:12+02:00

just launched Nostr Widgets, server-rendered svg widgets for Nostr profiles, follows, and feeds to embed with <a><img> in static pages, thoughts?

https://github.com/nostr-wot/nostr-widgets

flights near the edges (Sydney loop) are longer because planes ...

2026-04-22T19:57:37+02:00

In reply to nevent1q…zste
_________________________

flights near the edges (Sydney loop) are longer because planes slow down as they approach the abyss, pilots instinctively ease off the throttle. London-NY-Tokyo stays central, full speed ahead

your flight time data doesn't prove roundness, it proves 𝐩𝐢𝐥𝐨𝐭 𝐚𝐧𝐱𝐢𝐞𝐭𝐲 𝐠𝐫𝐚𝐝𝐢𝐞𝐧𝐭. the closer to the edge, the slower they fly

set up your ligthning wallet with 2 clicks ...

2026-04-15T16:20:21+02:00

set up your ligthning wallet with 2 clicks

https://nostr-wot.com/guides/lightning-address

thanks for the heads up! just fixed the lnbits service ...

2026-03-15T02:30:30+01:00

In reply to nevent1q…8u92
_________________________

thanks for the heads up! just fixed the lnbits service 🌱🍄🐳

you got me, gonna run in nostrito soon 🫣

2026-03-14T21:54:49+01:00

In reply to nevent1q…vp7j
_________________________

you got me, gonna run in nostrito soon 🫣

for sure, that's why i am participating in all the meetings! ...

2026-03-11T18:49:38+01:00

In reply to nevent1q…7jc5
_________________________

for sure, that's why i am participating in all the meetings!

it is designed to be fully integrated from day 0, and not to compete, but to enhance it

i am sure a lot of people is building from different directions, and i am opened to listen and learn from all of them

i called it protocol because platforms can architecturally participate of several protocols: bitcoin + lightning network + nostr + gozzip. furthermore, it can also be implemented in other decentralized social network initiatives equally

hey! for some reason i can't get a Signal account with a ...

2026-03-11T15:28:41+01:00

In reply to nevent1q…9ccq
_________________________

hey! for some reason i can't get a Signal account with a Vietnamese number. i haven't had time to catch up with that yet

your approach is interesting, to find a way to vouch for relays and a public way to access them based on performance parameters such us latency or availability, geographic area, reliability, spam detection and so on, and query them through a service like purplepag.es would be great. i think that's not my line of work, but probably ManiMe (nprofile…0j5w) could think of something

what i am focusing now is on how to achieve Nostr's original promise: "shift the paradigm of dumb client/smart server to smart client/dumb server", or rather "smart client & smart server"

i have the intuition that we can use our WoT as infrastructure to store and retrieve information, rather than using only relays. Nostr exploration has given us tools and space to understand what works and what not, and i've come to realize that what we thought was fixed and objective, can be dynamic and subjective, just like life itself

relays are amazing as a boostrapping mechanism, discovery, specialized services, curated content, connect to other peers when no other available method, but, users SHOULD define what they want to see or not, and that information shouldn't be public, should be private. what i consume or not by no means should be of common knowledge or arbitrarily served. gatekeeping and surveillance surface can be reduced

i've written a whitepaper that introduces a decentralized trust-weighted storage and retrieval system that can be built alongside Nostr and work in parallel to relays. i'd appreciate your honest feedback: https://github.com/gozzip-protocol/gozzip

hey @nprofile…tz23 . i agree with you, but instead of routing ...

2026-03-10T08:30:17+01:00

In reply to nevent1q…x0e3
_________________________

hey xte (nprofile…tz23) . i agree with you, but instead of routing content through random peers, we should use our web of trust. content should be within the people that consumes it the most.

i wrote a paper about it: https://github.com/gozzip-protocol/gozzip

pretty clear breakdown, core argument is strong. relay-based ...

2026-03-09T18:22:57+01:00

In reply to naddr1qq…2yvf
_________________________

pretty clear breakdown, core argument is strong. relay-based filtering is the right structural incentive. the "tragedy of the commons" point is an angle that i had hard to imagine: if filtering is purely local, you're offloading the mess onto everyone visiting your threads. relay selection as social responsibility makes sense

that said, want to push on something: what happens if we take the relay-filtering model seriously but ask what a "relay" could actually be?

right now clients are dumb readers, relays are smart filters. users pick relays with good policies, system works because operators have infrastructure and incentives to filter well. pyramid, pow.relays.land, paid relays, all proof this works today

but theres a gap. relay operators are a dependency surface, they decide whats stored, for how long, what rules apply. even the best-intentioned operator is a single point of policy. if inbox.yakihonne.com changes its algo or goes offline, every user with it as a read relay is affected

part of why this felt inevitable is that clients used to be genuinely constrained. storage expensive, bandwidth metered, battery a real concern. making clients dumb made sense. but that assumption is aging, phones today have hundreds of gigs, always-on connections, processors that would've been server-grade not long ago. the gap between client and server is narrowing, even if the protocol still treats them as categorically diferent

what if some clients started behaving more like relays? not replacing what you describe, complementing it. a client that forms bilateral storage agreements with wot peers, i store yours you store mine, with roughly matched volumes so neither side is freeloading. both sides have skin in the game which is what makes it stable, if you stop holding up your end i stop holding up mine and we both lose a storage partner

the filtering part comes almost for free. content only propagates within a trust boundary, say 2-hop follows, so spam from throwaway keys never reaches you. not because a relay filtered it but because nobody in your social graph stored or forwarded it. same wot principle pyramid uses, distributed across participants instead of centralized in an operator

the part that makes it not just a nice idea is how you actually find stuff without a relay index. you'd want something like a tiered approach, check local storage first, then try known peers who responded fast before, then fan out a blinded request through your wot if needed, and only hit traditional relays as a last resort. relays become a fallback layer rather than the primary path, which is basically embedding your model as a component

the question is wether both models coexist and reinforce each other. relays handle filtering and inbox routing (works today, should be default), wot-based peer storage adds an availability layer and alternative discovery path that doesnt depend on any single operator. periodic challenge-response checks between partners keep the storage honest without needing anything as heavy as proof of work or staking

curious if you see something structurally incompatible about the two coexisting, or if you thinkk the relay model already covers this ground

irony: censored in nostr-protocol github 😇 ...

2026-03-08T00:59:21+01:00

irony: censored in nostr-protocol github 😇

haha! nice set up! if you read from your phone, you don't ...

2026-03-07T23:45:05+01:00

In reply to nevent1q…pyhx
_________________________

haha! nice set up!

if you read from your phone, you don't need much light. try this paper:
https://github.com/gozzip-protocol/gozzip

an additional layer to nostr for decentralized storage and retrieval. i think your ongoing browser nostr effort could use it!

i don't know if you made it on purpose, but it shows you ...

2026-02-27T17:22:51+01:00

In reply to nevent1q…54vw
_________________________

i don't know if you made it on purpose, but it shows you still write your own messages hahah!

link is wrong! can you check?

2026-02-27T17:13:19+01:00

In reply to nevent1q…e7hz
_________________________

link is wrong! can you check?

tomorrow introducing Nostr WoT at #WoTathon! ...

2026-02-25T20:09:10+01:00

In reply to nevent1q…6t5e
_________________________

tomorrow introducing Nostr WoT at #WoTathon!

https://nostr-wot.com

#NostrBuild #DecentralizedTrust #WebOfTrust #Nostr #Bitcoin

quoting
nevent1q…hev9
Reminder that our 15th #WoTathon weekly call is 2 days away on Thursday, February 26, at 4 PM UTC, 11 AM Eastern. We look forward to hearing updates on the progress each team is making!

Any specific topics you'd like to add to the docket? Reply below!

https://nosfabrica.com/wotathon

i hear you. i think every user should be able to choose what ...

2026-02-25T12:07:04+01:00

In reply to nevent1q…p7lr
_________________________

i hear you. i think every user should be able to choose what level of security they add to their key stash. today, they have little options, and every user experience is broken on this regard.

if i feel comfortable remembering things, under a scheme like this one which cannot be brute-forced, i may go for this approach. i may even feel comfortable enough as to not create a backup, because i know that if i want to keep the history of my account, i can just create a new one and use the old password (very interesting approach to handling keys hey).

there's another guy that wrote about publishing instead of a passphrase another key that you should back up. so you can have 2 back ups, and one of them is the one you use in your hot nostr client, the other you use it under an emergency to rotate your key.

if the relays start working together on adopting a model or several of these strategies to prevent bad actors, and on top of that little trust, you could have levels of order and completeness that will give you a safety net (OTS or straight an OP_RETURN), then this sounds interesting.

hey David. every existing proposal has the same flaw: if an ...

2026-02-24T20:10:55+01:00

In reply to naddr1qp…xcp0
_________________________

hey David. every existing proposal has the same flaw: if an attacker has your nsec, they can publish the same migration event you can. you can't prove who did it.

i am proposing below a scheme that fixes this using a hash commitment published on day one, a sha256 of a passphrase that lives only in your head (a password or something).

attacker can't rotate without knowing it. if they try, the fraudulent rotation is cryptographically distinguishable from a legitimate one.

key theft becomes detectable, not just disruptive.

draft NIP: https://github.com/nostr-protocol/nips/issues/2237

check it out, and let me know your thoughts!

#nostrbuild #keyrotation #cryptography

will work on it, and release it soon. thanks for the heads up!

2026-02-16T00:24:18+01:00

In reply to nevent1q…yt3g
_________________________

will work on it, and release it soon. thanks for the heads up!

Centralized platforms tell you who to trust. You don't get to ...

2026-02-15T23:34:45+01:00

Centralized platforms tell you who to trust. You don't get to see how or why.

𝐈 𝐛𝐮𝐢𝐥𝐭 𝐍𝐨𝐬𝐭𝐫 𝐖𝐨𝐓 𝐛𝐞𝐜𝐚𝐮𝐬𝐞 𝐲𝐨𝐮𝐫 𝐧𝐞𝐭𝐰𝐨𝐫𝐤 𝐬𝐡𝐨𝐮𝐥𝐝 𝐰𝐨𝐫𝐤 𝐟𝐨𝐫 𝐲𝐨𝐮, 𝐧𝐨𝐭 𝐚𝐠𝐚𝐢𝐧𝐬𝐭 𝐲𝐨𝐮.

Your follows anchor your trust. Their network extends it. Distance becomes signal. You set the thresholds.

See the actual shape of your network. Control what reaches you. Own your filters.

𝐍𝐨𝐭 𝐭𝐡𝐞𝐢𝐫 𝐚𝐥𝐠𝐨𝐫𝐢𝐭𝐡𝐦. 𝐘𝐨𝐮𝐫𝐬.

https://nostr-wot.com/
https://nostr-wot.com/playground

𝐀 𝐛𝐫𝐨𝐰𝐬𝐞𝐫 𝐞𝐱𝐭𝐞𝐧𝐬𝐢𝐨𝐧 𝐭𝐡𝐚𝐭 𝐠𝐢𝐯𝐞𝐬 𝐲𝐨𝐮 𝐛𝐚𝐜𝐤 𝐜𝐨𝐧𝐭𝐫𝐨𝐥.

#decentralizedtrust #wot #nostr #weboftrust #grownostr #decentralization #buildingonnostr

Nostr event nevent1qqsypnm93uh0quzhnm45p322f23n0pgfj580f70fn88c73uhtpt9y9szypqekl0skpcph36u0gg9wgj5nhgkygxyrag708vjka5h6mn3ysvp5q9fys8

2026-01-30T14:40:55+01:00

inspire, love, effect 🌱