leon
Leon Acosta

courage is our own fountain of wisdom 🌱

https://quantakrypto.com

Public Key

npub1gxdhmu9swqduwhr6zptjy4ya693zp3ql28nemy4hd97kuufyrqdqwe5zfk

NIP-05 Address

Profile Code

nprofile1qqsyrxma7zc8qx78t3apq4ez2jwazc3qcs04reuaj2mkjltwwyjpsxspp4mhxue69uhkummn9ekx7mqpzpmhxue69uhkummnw3ezuamfdejs9rjk00

Publishing to

Author Public Key

npub1gxdhmu9swqduwhr6zptjy4ya693zp3ql28nemy4hd97kuufyrqdqwe5zfk

Show more details

Last Notes

2026-08-19 15:32:52 CEST

- reply

obelisk.ar implements post-quantum dms via nostr-wot already
https://primal.net/e/naddr1qvzqqqr4gupzqsvm0hctquqmcaw85yzhyf2fm5tzyrzp7508nkftw6tadecjgxq6qq38qmmnwskhzatpde682mfdv3khxttfdckk7cn9d35hx6edvdkxjetwwsxx2p45

2026-08-19 15:31:14 CEST

- reply

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
#naddr1qv…v2j5

2026-08-11 11:22:09 CEST

- reply

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

2026-04-28 03:45:12 CEST

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
https://npub1gxdhmu9swqduwhr6zptjy4ya693zp3ql28nemy4hd97kuufyrqdqwe5zfk.blossom.band/d4bfd802535a076b9fc3d44f31c65b9bb8420a4e4fa58032fb923d46dc0df9b2.png

2026-04-22 19:57:37 CEST

- reply

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

2026-04-15 16:20:21 CEST

set up your ligthning wallet with 2 clicks
https://nostr-wot.com/guides/lightning-address

2026-03-15 02:30:30 CET

- reply

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

2026-03-14 21:54:49 CET

- reply

you got me, gonna run in nostrito soon 🫣

2026-03-11 18:49:38 CET

- reply

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

2026-03-11 15:28:41 CET

- reply

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 @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

2026-03-10 08:30:17 CET

- reply

hey @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

2026-03-09 18:22:57 CET

- reply

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

2026-03-08 00:59:21 CET

irony: censored in nostr-protocol github 😇
https://blossom.primal.net/927678f028eb2b6489d0f269fa179bbc25b314f4b2a5bf20cf742c03dfab729b.png

2026-03-07 23:45:05 CET

- reply

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!

2026-02-27 17:22:51 CET

- reply

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

2026-02-27 17:13:19 CET

- reply

link is wrong! can you check?

2026-02-25 20:09:10 CET

- reply

tomorrow introducing Nostr WoT at #WoTathon!
https://nostr-wot.com
#NostrBuild #DecentralizedTrust #WebOfTrust #Nostr #Bitcoin
#nevent1q…hev9

2026-02-25 12:07:04 CET

- reply

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.

2026-02-24 20:10:55 CET

- reply

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

2026-02-16 00:24:18 CET

- reply

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

2026-02-15 23:34:45 CET

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

2026-01-30 14:40:55 CET

inspire, love, effect 🌱