Maybe you could return just the latest event by default and only return the history when asked for with a limit > 1 or some other criteria.

Reply to this note

Please Login to reply.

Discussion

yup, this is what I had in mind too, but mainly to avoid sending more data than most clients will probably use

Hmm, but it doesn't make sense to specify a limit when you want (the latest version of) multiple replaceable events.

Nostr's crappy querying language fails again. We need JOINs.

It's probably better to have a special relay or a special subdomain just for the relay that archives stuff though. And then clients should know to use that when they want old stuff.

Yeah, I wanted to set up the archive, but I need someone more familiar with relays and archiving to do it, as that isn't really our area of expertise. And blows up our meagre budget. 😬

Would be good to have at least one public archive relay, in addition to the couple of public "other stuff" relays we now have.

yeah, I think the only moment where you would return multiple versions is when you're being queried for something in particular

kinds: [30818], pubkey: [fiatjaf], #d: ["ipfs"], limit: 10

perhaps this warrants adding a new filter?

kinds: [30818], pubkey: [fiatjaf], #d: ["ipfs"], revisions: 10

Indeed, that solves it.

Not the new filter, I don't think it's necessary at least for now.

This would be great for contact list recovery on metadata.nostr.com