nostr:npub1kmwdmhuxvafg05dyap3qmy42jpwztrv9p0uvey3a8803ahlwtmnsnhxqk9 your lightning addresses have been broken for a few months now. They don't publish nostr zaps that are sent to them despite the fact that they say they support zaps
I've been using the geyser LN address for the nostr:npub1wyuh3scfgzqmxn709a2fzuemps389rxnk7nfgege6s847zze3tuqfl87ez account and zaps have not been showing for donations for a few months now
I'm too lazy to switch to another lightning address provider and I liked how the donations and zaps where synced before so Id rather complain than switch providers
LNURL in question: https://geyser.fund/.well-known/lnurlp/nostrudel
It publishes it to the "app relays" which are a local list of relays the app uses for everything and your outbox relays
The app relays are only thing because I still haven't built an outbox system for the main feed
I feel like every time I see someone complain about nostr I need a quick "view feed" button that will show me what they are seeing 🤔
Great idea, I like building charts too so this might be fun to hack out
Something like the examples here but more of a standalone app https://hzrd149.github.io/applesauce/examples/
a list management app is a little tricky since its more complicated. Id like to build an example app that no one is going to use but demonstrates how the applesauce SDK can be used
Looking for some ideas here, I want to build a simple nostr app using applesauce and write a tutorial article for it. Ideally the app should be really simple and focused on a single aspect of nostr like displaying calendar events or showing user statuses etc
#asknostr and nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424 because you have to many ideas
Thats a cool picture. seems like a view you normally shouldn't see
What do you mean by garbage? Sending tons of messages by making tons if REQs?
Maybe your GMing at the wrong time? :D
Im in. Damn nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr really making it hard to stay on iOS as a daily driver.
Id like to publish it to IOS but its almost impossible to get through the app stores KYC and approval process
currently fighting the other 10 nostr users to download nostr:npub1wyuh3scfgzqmxn709a2fzuemps389rxnk7nfgege6s847zze3tuqfl87ez on nostr:npub10r8xl2njyepcw2zwv3a6dyufj4e4ajx86hz6v4ehu4gnpupxxp7stjt2p8
I didn't think anyone would notice so quickly...
Wait, so storing strings is faster than objects? Did you test this anywhere and is that the reason your implementation is faster?
Also how many events did you test it with. The most I was able to get with my implementation was 100k
Have you seen this? nostr:nevent1qqsww099lapu2wauztfg97nv7selgvgalqcxn3xn5k8gq4dh6p5xxfcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqsj6gjek
If you end up trying it please let me know how it goes.
No but it looks a lot like another package I made last year :)
https://github.com/hzrd149/nostr-idb
Ill give it a try and I hope its faster, but it wont make me stop hating indexeddb
Found this article after digging around a lot https://jlongster.com/future-sql-web
It shows its faster ( for 100k+ entries ) to load a wasm of sqlite into memory and then run it off an in-memory file system than it is to use indexeddb
I've managed to make it work and it can hold about 10k events without freezing the browser. but it just bugs me that its taken so long for web apps to get a decent database implementation
I'm using it now and it sucks, indexeddb is so slow it somehow manages to fail to be a key value store
sqlite anything is 100x times faster than indexeddb. I don't think anyone could build a database slower than indexeddb...
That said kierans worker relay package is really great for web apps https://www.npmjs.com/package/@snort/worker-relay
What could help, but I'm just a lowly client dev :)
If there aren't any better options Ill probably go take apart nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49's @snort/worker-relay package
#asknostr does anyone know of a generic collection of pre-built SQL queries that can be used to store events in a SQLite database? I'm not looking for an implementation I just want the queries or ways of building the queries.
I'm trying to figure out the best way for noStrudel to use sqlite-wasm in the web and then native sqlite on mobile and possibly better-sqlite3 for node.js. all of these implementations are different and Id like to avoid having to re-write all the SQL myself
bonus points if it supports FTS5
Awesome, I've heard great things about events on orange pill app and now I can build my own calendar view :)
I notice an issue with the events structure though. Its not mentioned in the NIP (for some reason) but commonly there are multiple "g" tags. one for each level of the geohash. that way its possible to lookup events by a wider area
For example a geohash of "dntp5s" would be 6 tags:
- ["g", "d"]
- ["g", "dn"]
- ["g", "dnt"]
- etc...
Its an annoying side effect of how relays index tags and events and I'm not sure why its not mentioned in the NIP
The react documentation is lacking, but generally you want to use the model for everything since they act like react-query and deduplicate subscription.
The loaders are confusing, but they are used to request new events from relays. integrating them into the models is a pain right now because I haven't found a way to make them plug together cleanly without turning applesauce into a monolith / black box
The cleanest way I've found so far is to create a custom `ProfileQuery` model that will request the event from the default relays if its not present in the event store
I made recalculateFollowDistances async, it now processes in batches of 1000 and uses queueMicrotask
The only thing thats still causing the page to freeze is deserializing the graph. it takes about 3s on my machine
I haven't looked into it too much, but it looks like its the follow distance calculation that is taking the longest. do you think it would make sense to store the distance in the serialized graph in order to speed up load times?
I made recalculateFollowDistances async, it now processes in batches of 1000 and uses queueMicrotask
Looks like that helped a lot. also I was calling the recalculate method every few seconds and it looks like thats not nessisary... so thats a x2 improvement right there :)
nostr:nprofile1qqs8t4ehcdrjgugzn3zgw6enp53gg2y2gfmekkg69m2d4gwxcpl04ac04xqkm test npub. Hit me up.
npub1rqdslx2fdllq32a2r0hyp3cwpm0mfmrvgmwr2kyj25ydsgrwur4qecvgxd
Seemed to work, at least it said it sent a message
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
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?
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
Binary serialization reduced nostr-social-graph filesize by 56%. Public keys, timestamps and small integers (condensed representation of follow relationships).
Probably all socially connected Nostr users and their follow lists fit in under 20 MB. Iris uses the graph for spam filtering, and it works nicely.
Maybe nostr social graph will be used in the future by robots and drones that need to identify each other and know friend from foe.
https://github.com/mmalmi/nostr-social-graph
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)
Glad your maintaining your own blossom server. It's better if there are lots of implementations
#asknostr can someone spam me with NIP-59 gift wrap events. preferably ones that fail to decrypt.
I need to make sure that my NIP-17 implementation can deal with spam
nostr:npub1v0tfjv5ahr3c260jtzdk5w48krerrnkg8fmcnc5lpguk0qda04eqzm3m3e why all the AI generated images recently? I don't really like them and they are filling up my feed
Is it tied to react is any way or are these just react hooks you made for it? If we can get NIP-60 support id like to be able to run it in a backend like bun or deno
some of the messiest projects I've seen, markdown files everywhere. outdated tests, docs, and cli tools everywhere and no indication of what is what works and what was left by the AI as a one-off test
#asknostr where was that NIP that added custom fields for kind 0 profiles? I forget what its use was but I like the idea
I've been using this library by nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk https://github.com/mmalmi/nostr-social-graph
Its nice how it has an export and import format. and it looks like there is also a server that could be used to provide pre-built graphs for bootstrapping https://github.com/mmalmi/nostr-social-graph/tree/master/server