- I actually rewrote the entire NIP (while I was at it) for clarity. So a diff would not be as useful as you may think.
- also, the updated spec does allow for the “type” categories (index 1 in the tag) to be any arbitrary value … even if only ONE service provider supports it. These are only intended to hint at the underlying data type returned.
- given this, it does make sense to have a standard “w” label for the tag itself (index 0 in the tag) and also … for indexing purposes.
- give that the arbitrary “context” string will end up being the “d” tag value for (spec TBD) a user published “algo config” event … indexing these “w” tags makes sense for other users to discover each other’s “configured algos” … without necessarily exposing the users actual algo config.
- also, the updated spec does allow for the “type” categories (index 1 in the tag) to be any arbitrary value … even if only ONE service provider supports it. These are only intended to hint at the underlying data type returned.
- given this, it does make sense to have a standard “w” label for the tag itself (index 0 in the tag) and also … for indexing purposes.
- give that the arbitrary “context” string will end up being the “d” tag value for (spec TBD) a user published “algo config” event … indexing these “w” tags makes sense for other users to discover each other’s “configured algos” … without necessarily exposing the users actual algo config.