Hard problem to tell bad from good actors, always was š¶š¾š«”
Discussion
Yes, we're going to have the same problem, but we have the advantage of additional tools and a different architecture.
Not sure Iād call it an advantage, more of a challenge if you ask me š¶š¾š¤·āāļø
it's like i saw written on some nostr information website the other day:
smart clients, dumb relays
move the compute to the edge where the user is in control
Although some relays are just programmable filters or aggregators. There's basically a Layer 2 of relays that act as controllers.
yes, i'm almost finished building a relay that acts like a cache for a bigger database too, similar principle...
and i have ideas about making it so the relay automatically broadcasts notes (using NIP-46 if needed) according to app relays and outbox and polls inbox relays
Yeah, love the Layer2 relay model.
Is the database NoSQL? An object database or...?
it's a key value store based on fiatjaf's eventstore/badger it uses a custom query logic that is based on the design of REQ filters - it's a little complicated to explain it but it fits into about 80 lines of code
they work a bit like graphQL, except there is no negation, something that would be a great innovation... so for example, if ANY event IDs appear in a filter then there is a secondary filter that is applied after the first match... really it should have selectors for each field that add on in a filter chain, and there should be a negation to screen out matches as well as include them
but this is the state of it now... i understand how it works now so i could improve it but this will be something for later
also, i was calling it "2 level caching" but Layer2 has cachet