also, "would prefer it was in the protocol" is requiring the protocol to not just be a relay protocol but also a consensus
no
just had this conversation with regard to semisol's idea about cursors being jammed into REQ/EOSE envelopes
no, this is a separate protocol, like i said to @semisol - make a new query type that only returns event IDs, problem solved, no state to save, far less data cost, and the client is free to paginate it as they wish
Well, 1984s ARE in the protocol and they do exactly what I need already. Or would, if relay operators could leave the suspect notes on Death Row for a while.
Otherwise, 100% agree
i'm making a mental note about this, that 1984'd events will not be served to the reporter
this will ultimately lead to a concept of "web of distrust" which could be a marketable data set too
Except, its the reporter that most needs that event for training their own filter. Hmmmm...
@Bob_stores_nostr's idea of an "archive relay" solves my data problem. If he doesn't build it I may have to...
Happy to collab or learn about your use case. What subset of Nostr notes specifically would be enabling for your filter training?
Thank you, Bob!
Anything that:
- is a Kind-1984, or
- is the note reported in a Kind-1984
The idea being that client apps can train their own filter models, or at least a marketplace of data vending machines can build them on demand.
Two-tiered access to your archive could work, free access to last month's data, maybe, and paid access to everything...
It would be great if an archive could generate revenue, but honestly, my focus is on building relationships and trust with relay operators to get the data without disrupting their primary function. Once the data is coming in, then it will be down to working with people like yourself to figure out how to serve the data subset you need in the time frame you need it with the resources I have available. And if the resources are lacking, how to get them.
Oddbean new post about login | logout