missing general functionality for updating events based on `d` tag

[anasfik]

Hey @UTXOnly

When a certain event is created whatever its kind, whenever it contains a d tag like this event:

{
	"content": "...",
	"created_at": 1735485203,
	"id": "...",
	"kind": 1,
	"pubkey": "userPubkey",
	"sig": "...",
	"tags": [
		[
			"d",
			"uniqueId"
		]
	]
}

Updating functionality should happen to that event if a newer modified event was sent to the relay with the same kind (in this case 1), d tag id (in this case uniqueId), by the same user pubkey (in this case userPubkey) and if its created_at is greater than existent one(s), of course after the id and sig is validated as well.

As example, if we try to load posts with:

[
	"REQ",
	"quer",
	{
		"kinds": [
			1
		]
	}
]

let's say they will get us posts with these event contents:

• "hello world 1"
• "hello world 2"
• "hello world 3"

Then let's say we updated the fist one's event content, when we request again it should return:

• "hello world 1 (updated)"
• "hello world 2"
• "hello world 3"

An event changes should be based on its content, tags (addition/removal) and tags values

Would be nice to have:

it would be better I say if we can even retrieve all event updates/changes on a specific request, like if we want to get previous changes of an event, we would do:

[
	"REQ",
	"querrr",
	{
		"#d": [
			"uniqueId"
		],
		"limit": 50
	}
]

an it should list them, so basically what I say here is that the Postgres database should store all events, but only returns the only the newest one by id until we ask it to get them all.

Thank you and we appreciate it.

[UTXOnly]

I think this is doable. As I see it, there are two possible approaches:

If a pubkey, kind, and d-tag combination comes in that conflicts with an existing event, update the event so only the latest version is stored. This would be the simpler fix.

If you want to store past versions of an event but only return the latest version under certain query conditions, that’s also possible. I’d just need to think through how to implement it in a way that doesn't add complexity to every other query the relay is handling—specifically, avoiding the need to tack on extra conditions to every query.

I’ll update this issue as things progress.

[anasfik]

We appreciate taling care for this issue.

Yes, the combination of the kind, pubkey, d-tag is what should be used to ensure the original event owner is who will update it only.

For the option to be able to get previous events of the same id-combination (event history), would be helpful if it functions only when the limit field is included in the filter:

{
"limit": 10 // gets latest 10 event updates including the very newest one
}

if this helps, maybe having a new events table without the updating functionality (like what exists currently on the relay) and then querying from it based on the d tag if that limit is in the filters.

Thank you very much!!