riverfinancial / nostrex Goto Github PK

I have been thinking about how we might implement NIP-2.

One thing I noticed is the tag schema only accounts for two fields, but for NIP-2 we need 3 fields.

I am curious your thoughts on this. It seems that future NIPs could have more fields later, so we probably want a way to handle n number of fields in tags, where n could be dynamic based off the event and tag. Unless I miss understand the NIP.

One solution is to removed fields from the schema and just use the raw tags?

I have a few thoughts how we store the contact list and would be curious to hear anything you had in mind while you were building the initial support.

One solution is to just query the right even and join on the tags, I am curious as what an update does. As I understand it, its more of a replace than an update. We can just store the event and tags and when we query for event kind 3 we just get the latest one? However, that means we will be expanding the DB even more for every contact list update.

Another solution is separate DB table(s) for the contact list that included an event_id. I am still thinking through the pros and cons of this solution, but it did pop into my head when I was thinking about this.

Lastly, a solution that might be interesting is another ETS table, separate from the filter ETS tables, but we can leverage ETS to provide fast reads and updates. Also, ETS does have update functions so updates are quick and we can form the data in application structures rather than DB structures, so it could literally be the event's pubkey pointing to an list. In the DB we will store the events and tags as we do for every other event and we don't really worry about handling the contact list updates at the DB level, we only have to update the ETS table for the person's pubkey (and broadcast the changes to subscribers) to point to a new list.

One thing to flag, is we ever want to run a relay at scale ETS does not work by default in distributed Erlang. Not that we should worry about that now, but thinking about how relays could need to scale as adoption grows and how BEAM has awesome distributed systems support is a fun mental activity.