Another great article by nostr:nprofile1qqst0mtgkp3du662ztj3l4fgts0purksu5fgek5n4vgmg9gt2hkn9lqppemhxue69uhkummn9ekx7mp0qythwumn8ghj7un9d3shjtnp0faxzmt09ehx2ap08pu8g0, this time on the Web of Trust.
Nostr is accomplishing what PGP could never do: establishing and maintaining a network of cryptographic identities that vouch for each other, thereby enabling the development of a reputation system.
This is huge
nostr:naddr1qqgrwd34vvek2wf5ve3nwcmrxycrxq3qklkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qxpqqqp65wrp5t4t
Great food for thought. I would have appreciated more insights, and I think many others would share this belief
GM good year
Badass cypher legionary.
writing a token bucket (no leaky) it's actually pretty simple
Wow, what an interesting and immaculately crafted episode. Your questions and the dialogue that arose as a result of them really crystallized my understanding of reputation and web of trust concepts. Pure Bitcoin. I’d say pure gold but that metaphor is so 2008. This content is fantastic nostr:npub1clk6vc9xhjp8q5cws262wuf2eh4zuvwupft03hy4ttqqnm7e0jrq3upup9
Thank you for the kind words. nostr:npub1clk6vc9xhjp8q5cws262wuf2eh4zuvwupft03hy4ttqqnm7e0jrq3upup9 is a great host
yes this is true.
The UX for builders is not where I want it to be, but there is so much to build and I have to prioritise
Yes, this is a good idea.
You would have to use an API key in the client, which is the same as loading credits on a nostr key and using it in the client. It's basically the same
but what's the difference between signing in and connecting your wallet with NWC?
I argue that the first is even easier, and it's free.
At the moment no queries unless you sign with a nostr key with credits.
At the beginning it was totally open and in 2 weeks since the launch I got people abusing it, so I had to gate it somehow.
Yes it could be zap based but I would still have to check if your key has zapped vertex, so still sign in.
I could accept ecash in the request, but then your user would have to have a wallet, which imo is more selective than a sign in
We added search, finally! You can now search for profiles on relays. Also make custom feeds that does searches. It needs more tweaking and improvements, but we're happy to make it available now! #nostria
https://mibo.eu.nostria.app/868918700a40d90086cb10d98ae9d389f16eeb9058eacb45c8823553ddcbfb65.mp4
the query "max" didn't return great results....
Check out npub.world for a great search experience. That client is powered by nostr:nprofile1qqstq4j6pk2sgaupru6l7ah9nq0dueafq356jllwcy7uzlek9yx7hlspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsnpjku2, which has a free search api
I'm trying to take a different path with my Nostr library stack. So far I've done the consensus layer for the Nostr protocol (roots) and the websocket message schema (roots-ws) in both go and typescript. And I'm working on the basic messaging library (honeybee). And as you need advanced features, the goal is to place them in separate libraries. And then you compose the parts you need into an app.
In the future I'll be looking at replacing go-nostr, and this seems a good library for it.
Just a few comments:
1) ID, Pubkey, Sig imo should be specific types of [32]byte or [64]byte, all represented as string with the method Hex(). This would allow inspections of individual bytes which I think might be useful.
2) Filter.Limit, when unspecified I think it should be MaxInt, because an unspecified limit means "give me everything". Similar to Since and Until, this would allow to avoid pointer checks and simply using comparison operators.
if filter.Limit > 1000 {
filter.Limit = 1000
}
I'm trying to take a different path with my Nostr library stack. So far I've done the consensus layer for the Nostr protocol (roots) and the websocket message schema (roots-ws) in both go and typescript. And I'm working on the basic messaging library (honeybee). And as you need advanced features, the goal is to place them in separate libraries. And then you compose the parts you need into an app.
yeah, I like this approach. It's what I'm following already, but not at the same level of categorization
- library for data structures (now go-nostr, but not for long)
- relay framework = rely (was, messages, relay logic)
- database (nostr-sqlite)
https://git.mleku.dev/mleku/nostr i guess you don't like those binary coded things. i agree they are a little fiddly (must remember to use the helpers to compare/extract them). but anyway, just in case you forgot it exists
I have mixed feelings on it. It's very cool but also it doesn't reach the DX I would love. I'll borrow a few parts and credit your work
yes I don't like go-nostr either. In the future all of my project will migrate to a minimal library.
Where can I check your work?
feedback taken.
How would you do it if you were in me?
you can make whatever database you want and it will fit into rely.
Take a look it's super modular, which I agree it's a very important property of code
Thank you so much for the suggestion. Implemented it, and with a settings option to default keep it expanded or collapsed. When expand, it will show the whole thread, so you won't have to click so many times.
If you don't show the lines, it will still highlight and allow you to click, as demonstrated in this recording.
It might not be optimal UX for mobile devices like this, will do more testing on phone and consider some changes.
https://mibo.eu.nostria.app/eb29874dce1173107e7a6e86ad17fc692b085950696649ca31ca6debafcb0a95.mp4
wow. cc nostr:nprofile1qqs9c5x6zv55073m736eawtc67zdky4645wrukm22a2ppt4k233ekjcpn3xzs take a look at this UX
nerd sniping is coding at the highest level.
If you are interested, you can open a PR to nastro adding your own badger based DB. I would actually really appreciate it.
The prerequisite is just to satisfy the store interface, expose the internals (so people can make queries directly if needed), and allow for customisation.
I think it would be quite beneficial to the ecosystem to move away from the event store fiatjaf packages, which is quite crappy
When I started to work on npubx.cash I thought that this new version would not have a frontend like the old version did. The reason being, that it works best when integrated into a fully persisted and feature complete Cashu wallet. And I did not want to build a full wallet app just for npubx.cash...
Well thanks to coco-cashu this has now become a matter of UI design alone. With coco-cashu-core and coco-cashu-plugin-npc you get a full wallet with npub.cash integration out of the box. All that is left is some UI work.
https://blossom.primal.net/25bc040efda2e1d25eeb23b5d4c8631f8ae583d4e3f683515955b5fa8517b9c5.mp4
lovely idea. Only problem is typescript ahahah
oh fuck, I'm sorry sir
Thanks! Yeah that could be done!
that's impressive. How much would it be if sent over the websocket in the normal way?
man I don't know u at all, but just by watching the video I know you'll get bored AF in an island in a few weeks if not days.
What if you build your own help center? Make it a non-profit, pour your bitcoin there which should count as a donation so you don't have to pay taxes? Just guessing, I'm not an accountant or anything, just food for thought
yeah that's a great suggestion man. Thank you
yeah man, it's very easy to build, just apply Pagerank to it
Yes.
But it doesn't mean clients have to reinvent the wheel.
You can just use nostr:nprofile1qqstq4j6pk2sgaupru6l7ah9nq0dueafq356jllwcy7uzlek9yx7hlspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsnpjku2
yeah, I like consise code as well.
I've been playing with React lately and there is a awful lot of line noise.
Ruby is probably the best as far as code aesthetic, but ofc it's not statically typed, and has worse performance than go. But they are meant to be used in different areas, so they are complementary not competing.
Just tried new version of Iris nostr:nprofile1qqsy2ga7trfetvd3j65m3jptqw9k39wtq2mg85xz2w542p5dhg06e5qpzdmhxue69uhhvct4d36zu6tjd9ejuar0w3mpq9 and it's really good
Conversation about impersonator prevention
https://github.com/nostrability/nostrability/issues/213#issuecomment-3106682968
more like allowing for custom functions to be executed.
e.g. if the relay receives a supported DVM kind, then process in a certain way.
Like, the user provides the function in a certain programming language, and the relay executes it when conditions met.