leon / Leon Acosta is on Nostr

courage is our own fountain of wisdom 🌱

Last Notes

2026-04-15 14:20:21 UTC

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

2026-03-15 01:30:30 UTC

- reply

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

2026-03-14 20:54:49 UTC

- reply

you got me, gonna run in nostrito soon 🫣

2026-03-11 17:49:38 UTC

- 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 14:28:41 UTC

- 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 07:30:17 UTC

- 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 17:22:57 UTC

- 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-07 23:59:21 UTC

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

2026-03-07 22:45:05 UTC

- 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-03-02 11:01:35 UTC

- reply

GrapheneOS partnering with Motorola is the kind of news that we should all be pushing for
privacy-grade OS. mass-market hardware. no compromises
this is how you bring sovereignty to not-power-users, not by preaching, but 𝐛𝐲 𝐦𝐚𝐤𝐢𝐧𝐠 𝐭𝐡𝐞 𝐬𝐞𝐜𝐮𝐫𝐞 𝐨𝐩𝐭𝐢𝐨𝐧 𝐭𝐡𝐞 𝐝𝐞𝐟𝐚𝐮𝐥𝐭 𝐨𝐧𝐞.
#grapheneos #privacy
#nevent1q…fssu

2026-02-27 16:13:19 UTC

- reply

link is wrong! can you check?

2026-02-25 19:09:10 UTC

- reply

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

2026-02-24 19:10:55 UTC

- 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-15 23:24:18 UTC

- reply

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

2026-02-15 22:42:58 UTC

- reply

Play with it. Install the extension and hit the playground.
Click through your network. Watch it expand. See how far your trust actually reaches and how many real people are in it.
Your web of trust, visualized. Not theoretical—tangible.
https://blossom.primal.net/66c4147bb6031474d2b7479a529d99cd65c44262f554637a9799bf720b7a376c.png

2026-02-15 22:34:45 UTC

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 13:40:55 UTC

inspire, love, effect 🌱