Skip to main content

Kinds 1 & 6 special handling

Processing kinds 1 & 6 before displaying​

Side effects​

Every time kind 1 or kind 6 events are requested, the following other kinds are also returned:

  1. kind 0 used to display information about the author
  2. kind 10002 used to display information about reposts/quotes
    • for each:
      • kind 6
        • where the p tag this event = pubkey of kind 10002 event
      • or kind 1 with a q tag
        • the q tag has he same structure as the e tag in the nostr protocol + 1 custom alteration we made, a 4th element, which is the pubkey of the author:
          • ["q", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>, <32-bytes lowercase hex-encoded public key of the event creator>]
          • where this new 4th element = pubkey of kind 10002 event
  3. kind 7 used to display if the logged-in user liked that post
    • matched by its e tag and its pubkey
  4. additional kind 1 with e tag used to display if the logged-in user has a reply to that post
    • matched by its ["e", <post-event-id>, "", "root"] tag and its pubkey
  5. additional kind 1 with q tag used to display if the logged-in user has a quote to that post
    • matched by its q tag and its pubkey
  6. additional kind 6 used to display if the logged-in user has a repost to that post
    • matched by its e tag and its pubkey
  7. multiple kind 6400` used to display various counts
    • matched by its i tag. I.E.: [ "i", "<kind 1 event id>", "event", "", <marker> ], where marker can be one of:
      • reactions
      • replies
      • quotes
      • reposts

Querying the data the reposts/quotes point to​

Achieved by simulating a traditional request-response flow via an ad-hoc subscription to a random r tag of the kind 10002 event associated with the kind 6 or the kind 1+e tag events, with 1 filters JSON:

{"kinds":[1],"ids":["eventId1","eventId2","eventId3",...,"eventIdN"]}
note

Where the ids array is built from the e tag of the kind 6 events or the 2nd element*(event id)* of the q tag array of the kind 1 events that are associated with the kind 10002 event through their author as described above

note

If multiple r tags must be queried (1 for every kind 10002), each of them must be independent and done in parallel

note

This also generates the same side effects mentioned above, but the kind 10002 one should be ignored; we only have 2 levels of depth max