Update 94 add a d tag to event

nostr-protocol / nips

Nostr Implementation Possibilities

2.39k stars 582 forks source link

Update 94 add a d tag to event #1532

Open haorendashu opened 1 month ago

haorendashu commented 1 month ago

Add a d tag to file metadata event and it will make this event replacable. It means that the file can moving between media services.

You can vist updates easy from here: https://github.com/haorendashu/nips/blob/Replacable-File-Metadata/94.md

use cases

Use as a movable media for notes.
1. Clients upload a file to media service and get a file link and other file infomations.
2. Clients send a File Metadata event and this event must contain a d tag, it means that this event is addressable.
3. If a client want to sends notes with this file, it should imports this event with nostr:naddr style uri.
4. When other clients vist a note with kind 1063 naddr style uri, it should find this event and display it like a normal media file.
5. If this file's owner want to change the media service, he can upload this file to other media service and resend a File Metadata event with the same d tag.

bezysoftware commented 1 month ago

Adding a d tag to event does not make it replaceable (you actually mean addressable). Only changing the kind number to an addressable range does that, see https://github.com/nostr-protocol/nips/blob/master/01.md#kinds

haorendashu commented 1 month ago

Thanks @bezysoftware , replaceable had change to addressable. But, should i change the event kind too ? This kind had used for a long time. Maybe i should add a new kind event ?

vitorpamplona commented 1 month ago

You can simply send a deletion request to the old event id and republish a new kind 1063.

No changes are needed for the NIP

arthurfranca commented 1 month ago

The idea is great and it was proposed before by the strfry creator.

The idea is for relays to treat ANY event kind (on this PR it is just for kind:1063) as addressable as long as the event has a d tag.

Note: Unlike what others readily think, it would NOT make kind:1 editable and break nostr simplicity, because clients would still fetch kind:1 events by id (instead of by kind+author+d-tag).

Bonus (from the old proposal): Tell relays to treat received expired events (expiration tag < created_at||now) as ephemeral then we can get rid of the event ranges definitions.

haorendashu commented 1 month ago

@vitorpamplona If i only simply delete the old event and resend one. Those notes which imported this event will can't visit this media file.

But if this event contains a d tag and clients searching this event by d tag. When i move this file from one service to another service, i only need to send a new event with the same d tag and the new link.

Those events which had imported this event can still visit this media file.