JavaScript developer working on some nostr stuff - noStrudel https://nostrudel.ninja - Blossom https://github.com/hzrd149/blossom - Applesauce https://hzrd149.github.io/applesauce
hzrd149 @hzrd149 - 4d
This seems true although I can't prove it... So add it to the list
Yeah, the content policies, hide or mute events based on the social graph. Ideally, you'd want to have it at the 4th or 5th. Changing them won't effect performance though, the real issue is how the social graph is being loaded in the background. I'm out if town at the moment to but I'll try to get a patch release out next week to either improve the performance or disable the social graph
Seemed to work, at least it said it sent a message
hzrd149 @hzrd149 - 5d
https://nsite.run
nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk is there any creative way we could make the nostr-social-graph library serialize or deserialize faster? that or maybe it would make sense to offload it into a web worker so it wouldn't effect the main thread?
What your looking for is the automatic social graph updates option. limit that to only the first degree and it will only load your friends contact lists https://cdn.hzrd149.com/fad85b73136650df0ecb636b9ecff7c0da8b9450da6644cfbc03e160f34f81ef.webp I had it set to 2nd degree by default which ends up loading ~180k to ~200k users for the average nostr user. normally thats not an unreasonable amount of data but loading for saving that large of a social graph can really lag the app I'm trying to think of a fix for this while still keeping the WoT filtering but for the time being I might just add an option to disable the social graph
hzrd149 @hzrd149 - 6d
Great explanation. Now scale that up to an entire social network and you get the idea.
Your right the possibilities with key delegation (and by extention rotation) are very powerful however as you mentioned it gets complex and the complexity IS the issue because it scales exponentially and not linearly Generally speaking complexity is bad because it slows adoption and introduces bugs. But its even worse when complexity is required on the edges (clients) because that means that for every user who uses key delegation every other user needs to check the validity of the delegation along with and possible revocatiotion. This would quickly become unmanageable or would cause the network to centralize because of the sheer number of checks required for clients to do. Also having complexity on the edges introduces new attack vectors like users rotating keys every minute or creating more delegations than a client could easily check. I haven't read the link you sent so I don't know if you've made any improves. but in my opinion Nostr succeeded because it did not key delegation or rotation, it was stupid simple which made it get quickly adopted by devs
Yes, and then they need to keep up-to-date with the delegations which is an even more complex process. That or you need key revocations and then we are back to PGP
Good idea, the NIP-05 check does not really mean much
hzrd149 @hzrd149 - 7d
The biggest drawback I've found so far with using it with Claude is that it Claude defaults to using "useState" and async/await for everything and doesn't understand how to use the observables and subscriptions Which means the vibe coded apps are pretty clunky and don't take advantage of the powerful reactivity that the library offers I've manged to get it to write decent code once I had a few examples to use as context
Stable and almost bug free. but lacking documentation for the advanced features There are a bunch of examples though that might help an AI to understand how to use the features https://github.com/hzrd149/applesauce/tree/master/packages/examples/src/examples https://hzrd149.github.io/applesauce/examples/
Everyone: what is 1+1 JavaScript: yes nostr:nevent1qvzqqqqqqypzplc6drzzpqsstkzjcsjmedurex0rer7v47n2jw3z7wpfurkfsvw0qy88wumn8ghj7mn0wvhxcmmv9uqzpu72gkd990uswpyeuansxlhtrmmhvfdd8tfh4yanxse9kmrz55gf2wtst3
Only if there aren't any bugs :)
#noStrudel now supports NIP-17 messages. It took a bit of work for me to implement them In the way that I prefer but now any other client that is built using applesauce can support them in the same way :) nostr:naddr1qvzqqqr4gupzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qyf8wumn8ghj7mn0wd68yat99e3k7mf0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qqsdeh4xarjw4jx2mpdxqkngdfdxqtn2yvk
I saw your note popup in my timeline :)
hzrd149 @hzrd149 - 10d
wow... and phone number is required too
Anything you can do to improve the performance will be awesome but if its not possible to make it faster then I'll look into wrapping it up in a worker so it at least does not block the thread
Thank you for working on this. specifically making sure its optimized. I'm using social-social-graph in noStrudel to build and cache the users social graph. I was just looking into the code this morning to figure out if it was possible to make the de-serialize / recalculate methods faster so they don't freeze the app. (right now it freezes ~4s when loading a graph of 160k users)
are you signing up for classes or just trying to use an app?
