IngwiePhoenix on Nostr: High 80s. It'd technically be possible to pull them... but the compute to calc ...
High 80s.
It'd technically be possible to pull them... but the compute to calc through it would be insane. Basically:
- Use fiatjaf/nak's --from and --untill
- Query a HUGE list of relays - possibly in parallel
- Feed the resulting JSON into a local database, use the ID as PK to avoid dupes. You may as well make both .content and .id unique...but that might stretch too far. So stick to .id, it's safer.
- Now, with all those events in, run text indexing on the database and finally: SELECT COUNT(id) FROM notes WHERE content LIKE "%bitcoin%" OR WHERE content LIKE "%btc %"; (obviously a rough sketch, but you get the idea).
Storing those notes is not the problem, <100GB would be my estimate, if you straight up filter kind 1 (-k 1). Probably less...
The compute of indexing is the harder part and might take a hot minute...or, multiple. o.o
So, yes, you can totally do it. Nostr do be open like that =)
It'd technically be possible to pull them... but the compute to calc through it would be insane. Basically:
- Use fiatjaf/nak's --from and --untill
- Query a HUGE list of relays - possibly in parallel
- Feed the resulting JSON into a local database, use the ID as PK to avoid dupes. You may as well make both .content and .id unique...but that might stretch too far. So stick to .id, it's safer.
- Now, with all those events in, run text indexing on the database and finally: SELECT COUNT(id) FROM notes WHERE content LIKE "%bitcoin%" OR WHERE content LIKE "%btc %"; (obviously a rough sketch, but you get the idea).
Storing those notes is not the problem, <100GB would be my estimate, if you straight up filter kind 1 (-k 1). Probably less...
The compute of indexing is the harder part and might take a hot minute...or, multiple. o.o
So, yes, you can totally do it. Nostr do be open like that =)