Gossip does not use pocket. I built things in this order: nostr-types, gossip, chorus, pocket. I backported pocket into chorus so now chorus uses pocket. But pocket only has a very simple interface, just enough for a relay, not nearly good enough for a client to use. That may change but I'm not working on such.
Gossip uses it's own LMDB storage which is a tad less efficient but much more fully fleshed out for client usage.
Also Gossip isn't interacting with it's local database in the same manner it would with a relay. I know that some other clients create a local relay style cache, but that is not what we are doing. We have a custom internal API that is nothing like querying a remote relay.
Do you think the custom internal API makes more sense than the relay interface and people should stop talking about embedding relays in clients?
I think a client has more things to store than just events that came from relays. So it makes sense to store those in something that doesn't reflect a relay's storage system. But when it comes to fetching events from local storage, I think having a similar interface to fetching events from a relay makes sense. Pocket-db provides sucn an interface where you pass in a Filter (like you would in a REQ) and it returns the matching events. At some point gossip's internal database changed its interface over to the same kind of thing.
But we also extract data out of events and store it into faster access structures. If we had to parse events every time we wanted to know who you follow, or what somebody's metadata says, etc, that would be too costly. You can think of this local storage like a cache, but the interface looks like a custom set of tables.
Oddbean new post about login | logout