History

After discovering nostr, i became interested in exploring a different approach to write a client. Clients typically use a (JSON) events store and make queries on it to find the content the user wants to see. Example: find the notes written by a person, then find the metadata of this person, then for each note find the reactions for this note, etc ...

This approach works perfectly but there is no "unified" view of the events and how they relate to each other. Also, the content of many events needs to be deserialized to extract their information. This is the case of metadata events (kind 0) and a few others.

Therefore my motivation was to write a different kind of events store that would transform events into triples (RDF), so that it would be possible to make complex queries on all events in the store, and access all the "embedded" information in events. SparQL (a query language for linked data) makes this possible.

Another interesting benefit of transforming nostr events to RDF is that we can embed JSON-LD in the event's payload. Semantic events with an evolvable vocabulary could have some interesting applications.

There are benefits to this approach, but there are some drawbacks as well, and the main one is performance. Query performance on a small store is ok, but as the store size grows, queries can become really slow. One of the reasons is that currently, the RDF URIs of events (which must be unique) are derived from the event id, which are long hashes. This uses a lot of space in the store, and makes queries slower (this could be changed though).

So until a solution can be found to optimize the events store, it's best to keep the store size small by regularly purging old content.