For me personally, it's NIP-1 that prevents me from making this my home. Building around standards from the browser world is the least cypherpunk shit ever. Retarded.
I'm not sure what would be better. JSON is simple, but its literary-style syntax is more expensive to parse than a format that uses sentinels and terminal markers.
I'm not familiar enough with alternative encoding schemes, but TOML would have been better.
The other issue is the query syntax, which is extremely primitive. Especially for graph-traversal-style queries, it is extremely bandwidth-heavy—and not only that, database-heavy.
In Orly, I have used what I probably incorrectly refer to as "vertex tables," which accelerate `p` and `e` tag queries by a factor of 10–50.
My `_graph` extension would fix a lot of these issues for the emerging number of projects using graph-structured analysis of the event data.
The lack of pagination is another big issue, as the time-series distribution of events can make effective strategies to capture longer time windows of some particular event kind a lot more complex to implement.
Now that I'm thinking about it, I think I could implement pagination without incurring the cost of relays caching query results to fixate the pages in time. This could be done pretty much by encoding the query cache format so that, rather than caching a whole result, it can instead cache the query windows as fixed points in the event timeline—meaning they only have to be computed *if* they are queried, and not before, while still keeping context of the query to enable the standard mechanisms of pagination.
So, yeah—pagination could be added, with the right search/retrieval strategy.
I'm not familiar enough with alternative encoding schemes, but TOML would have been better.
The other issue is the query syntax, which is extremely primitive. Especially for graph-traversal-style queries, it is extremely bandwidth-heavy—and not only that, database-heavy.
In Orly, I have used what I probably incorrectly refer to as "vertex tables," which accelerate `p` and `e` tag queries by a factor of 10–50.
My `_graph` extension would fix a lot of these issues for the emerging number of projects using graph-structured analysis of the event data.
The lack of pagination is another big issue, as the time-series distribution of events can make effective strategies to capture longer time windows of some particular event kind a lot more complex to implement.
Now that I'm thinking about it, I think I could implement pagination without incurring the cost of relays caching query results to fixate the pages in time. This could be done pretty much by encoding the query cache format so that, rather than caching a whole result, it can instead cache the query windows as fixed points in the event timeline—meaning they only have to be computed *if* they are queried, and not before, while still keeping context of the query to enable the standard mechanisms of pagination.
So, yeah—pagination could be added, with the right search/retrieval strategy.
1