NIP-116: Event paths#1266
Conversation
But if you want interoperability, don't you need to reserve the |
We do not have a scaling problem in numeric kinds. Pretending there is one is not helpful. But I am not opposed to creating a directory structure on an event kind. It's just not solving what you think it is solving. Either way, directories are very similar to #784, you can just use
This is dumb. It's just going to create a ton of empty events that client's don't need to download. It's better to have proper deletions than an empty event. See #1263 |
Sometimes you want interoperability, sometimes not. When you do, human-readable indexing is still better than numeric. There's much less risk of colliding with a number picked by someone else. You can get an intuition of what the event is for: e.g.
We will run out of unused 30000 <= n < 40000 event kinds before long. Even if we increase the range, it makes more sense to have human readable directory names which we will never run out of. There's probably a reason why we have filesystems with nested human-readable directory names instead of having to index every file by some random number only.
We could use "n" tag instead of "f". The events could reside in multiple directories. Why not.
With the delete event pattern you need to trust that all your relays are up-to-date and supportive of delete events (which will probably not be the case in a decentralized network) or subscribe to delete events on the client side. The need for "tombstoning" with empty values is unfortunate, but it's the only reliable way to delete a value in a decentralized system. However, it avoids the situation where a user toggles e.g. "like" button on and off, creating lots of "like" and "delete like" events that relays have to store. |
I don't get this. Relays don't have to store these likes and deletions in the same way they don't have to store the history of replaceables (which are also going back and forth on toggles). They can just delete them forever. It's up to them. |
I worked for 3 years with Verifiable Credentials where schemas and types are strings with "infinite" scaling as you said. There is no real interoperability between Verifiable Credentials. Everyone just creates their own names/types and fuck everybody else. There is no effort to reuse names somebody else is already using and/or to standardize what values those names take. Strings create the false impression of documenting what the type is without having to write it down somewhere else. Nostr's integer kinds require you to explain what you are doing in some other place than the type name itself. And that creates a possibility to explain the entire sematics of what your type is doing. It's just a better "system" for real interoperability. |
|
If the interoperability is not required, I think #995 will help. |
|
Yes, that was the entire point of NIP-78. I had previously done some experimental apps using remoteStorage.io, which uses a "path-like" namespace for storing app data. The result is that, of the few apps that exist in that ecosystem, most are "note-taking" apps and each of the note-taking uses a different path and is not compatible with each other. So the thing is really just meant for specific application data, not for interoperability, and all that is written in NIP-78. |
If the deletion events are not stored, the deleted events can reappear from a relay or client that doesn't support deletions or just hasn't received the deletion. |
|
I could use the existing event kind Then the only relay side change in this NIP would be this:
But it can be done later if this arrangement becomes popular. Avoids a little bit of redundancy. Replaceable events for lists and reactions is more of a client side suggestion. It could be done parallel to current follow lists and profiles. You could restore your follow list or profile from the replaceable event side even if there's a kind 0 or 3 overwrite. "Directory names" and numeric kinds are both possible on Nostr, so we can see which one works better, and maybe they have different purposes. |
What does this mean? What do they actually have to do to support it? Is it a filter with |
startsWith for d-tags. It would just save the redundancy in tags: instead of |
We have been requesting this for months (for geotags), but I don't think it's going to happen :( |
|
Actually not exactly startsWith: "#f": ['user'] should return an event with ["d", "user/profile"] but not ["d", "user/profile/name"]. So it requires a custom index for "f" to be efficient.
Link? Sounds like this should be an efficient startsWith lookup if just "d" is indexed on the relay. |
It was def in this repo, but I am unable to find it :( FYI, pubkey prefixes were also removed for the same reason: #703 |
5 participants
Event kind
30079denotes an event defined by its event path rather than its event kind. Event paths are a scalable alternative to numeric event kinds, and help make Nostr a true "everything app".