Please add a sentence that the .content can have a tag list structure just like NIP-51. We can copy-paste that and use it here. :)
Discussion
I would except that these things need to be spread far and wide. So they need to be as small as possible and not have content that needs moderation, because we want relay operators to accept and serve them for non-paying customers.
> I would except that these things need to be spread far and wide
Then delete 95% of that text (especially all the why's) :) And just keep it simple with what to mark as read, and what to mark as write.
> Private part
Do you think relays will block it just because there is an encrypted part? I am not sure if I have seen people blocking NIP51s because of that yet.
I dunno about other people, but I would. If there is an unlimited-length encrypted data, then I've just created a free online hard drive for randos.
Is this all that is?
When looking for an event:
- User events will be available for download in his/her WRITE relays.
- Events that cite/tag the user will be available for download in his/her READ relays.
When sending an event:
- Broadcast the new event to the list of READ relays from all `p` tags.
- Broadcast the new event to the author's WRITE relays.
Slight improvement:
When looking for an event:
- Events will be available for download in the author's WRITE relays.
- Events that cite/tag a user will be available for download the user's READ relays.
When sending an event:
- Broadcast the new event to the list of READ relays from all `p` tags.
- Broadcast the new event to the author's WRITE relays.
I just realized that a private list of relays don't make much sense if this kind is just for other folks.
Also a private list of relays is probably woefully insufficient for configuring a client.
There is more per-relay data clients are going to need. Where do you go to discover 10002 events for somebody? Which relays do you post your own on (all of them?) Do you want to also write to an archive somewhere that you don't advertise (because it is tiny and would get overloaded)? Also, stats about how successful a relay is, whether you want to downrank it (don't connect there it sux) or prefer it, when did you get a last EOSE (so next time you only fetch events since that EOSE happened), etc.
This stuff doesn't *have* to be client-specific, but for now NIP-78 App Specific Data (kind 30078) makes sense for that kind of thing, and a new NIP could be proposed to standardize this stuff that many clients would be doing similarly.