Appearance
Tag: previous
Overview
The previous
tag is used in relay-based groups to reference previous events seen from the same relay. It helps prevent events from being used out of context when shared across different relays.
Specification
Property | Value |
---|---|
Tag Name | previous |
Defined in | NIP-29 |
Required for | Events sent to relay-based groups (kinds 9000-9022 and any user-created content within groups) |
Format
["previous", "<first-8-chars-of-event-id>", ...]
Usage Description
The previous
tag contains references to previously seen events in a group. These references are made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves.
This mechanism serves as a "hack" to prevent messages from being broadcasted to external relays that have forks of one group out of context. It helps maintain context and conversation integrity within group discussions.
There can be any number of references (including zero), but it's recommended that clients include at least 3 references, and relays may enforce this requirement.
Examples
Basic Example
json
["previous", "f7e8d9c0"]
Multiple References Example
json
["previous", "f7e8d9c0", "a1b2c3d4", "5e6f7g8h"]
Client Behavior
Clients should:
- Track the last 50 events seen in a group.
- When sending a new event to the group, include references to at least 3 previous events (excluding their own).
- Select the first 8 characters of event IDs for these references.
- Check that events from other users include valid timeline references to maintain relay honesty.
Relay Behavior
Relays should:
- Reject events that contain timeline references to events not found in their own database.
- Optionally enforce that events include a minimum number of valid references (typically 3).
- Use these references to help prevent event context loss when groups are forked or moved between relays.
References
Related Tags
- Tag: h - Used to identify the group in which the events occur
Notes
The previous
tag mechanism is primarily intended for managed groups, but can also be useful in unmanaged groups. In unmanaged groups, clients should also consider including the NIP-70 -
tag, as just the previous
tag won't be checked by other unmanaged relays.