NIP-10: pubkey-stub

[v0l]

trafficstars

I have found that sometimes relay hints are not enough, and it would be much easier to find replies in a thread if that thread added the pubkey of the author as an additional argument to the e tag

[vitorpamplona]

+1

Relay urls hints are terrible in the long term and we should get rid of it.

But partial pubkeys might not help much since relays don't do partial filters anymore.

I do wonder if we shouldn't just go for better addressable standards for e-tags, like: kind:pubkey:eventid and leapfrog the intermediate solutions to this problem.

[v0l]

I do wonder if we shouldn't just go for better addressable standards for e-tags, like: kind:pubkey:eventid and leapfrog the ntermediate solutions to this problem.

Yea i was considering this too, it would be nicer to use nevent in e tags but it would require relay changes

[fiatjaf]

But partial pubkeys might not help much since relays don't do partial filters anymore.

From what I understood the partial pubkeys are just because the full pubkey might already be in a p tag in the same event, so you just use that to match. Good idea.

[pablof7z]

this is a really good idea and the pubkey prefix of an existing p-tag.

Maybe we can suggest that N should be the smallest length that disambiguates the p-tags in the event (e.g. if there are two p tags ["abc1..", "abd1..."] → N = 3 ("abc")

[arthurfranca]

I prefer using the whole pubkey cause although it would add a few more bytes it would be easier to implement by just requiring client to look at the e tag at hand without looping over the p tags.

[staab]

kind:pubkey:eventid

This would be ambiguous, because you don't know if the event id is a d tag or an id. I also don't like putting nevent in tags. Another option would just be to use a tags. The kind is embedded in the a tag, so you know whether the event is replaceable or not, so it wouldn't change anything in terms of semantics, although it would probably introduce some ambiguity in how to handle tags. So I think this PR is the best approach, although I do think we should just use the full pubkey.

[alexgleason]

Agreed that relay hints are useless because you can't really trust them. It's a good idea to put the author in there so you can do an outbox lookup. It's a bit unfortunate that we're at the 5th positional argument. But I agree with this concept.

I probably shouldn't say this, but the devil on my shoulder says to just deprecate the relay URL and switch it out with the pubkey. Clients should be doing validation anyway, and it's easy to tell the difference between a pubkey and a URI. Then new client devs don't have to wonder why there are 5 positional arguments and at least 2 of them are useless.

[vitorpamplona]

deprecate the relay URL and switch it out with the pubkey

It's a breaking change, but I would go for this.

[staab]

the devil on my shoulder

Mine says the same thing. It's sort of a breaking change, but in reality it won't break anything. I say we YOLO into it.

[fiatjaf]

Relay hints are good and useful. Their usefulness is yet to be manifested. Nostr is not only microblogging and NIP-65 doesn't contain all the answers. If you don't like them just use an empty string -- not a big space loss for people who want to include 64 characters of pubkey anyway.

If you replace the relay hints you'll just create another if/else clause on clients that want to handle both (or protect themselves from trying to connect to non-URLs) -- while an empty string is unambiguous, easy to detect and already expected.

[vitorpamplona]

Nostr is not only microblogging

This is true. But I implement most NIPs and I frankly don't remember using relay hints in any of them.

If you replace the relay hints you'll just create another if/else clause

The if/else is already there because there is so much trash in that relay hint field: markers/non-URL stuff or real urls without schema or with ?filters in the URL already, local relays, onion addresses, and private relays that require AUTH of the owner of the event, etc. They all need to be filtered out by the client. It's a huge if/else already. Adding a pubkey option (or frankly any other information to find the event) won't really change that much.

[pablof7z]

Nostr is not only microblogging

This is true. But I implement most NIPs and I frankly don't remember using relay hints in any of them.

You don't follow relay hints?

If you replace the relay hints you'll just create another if/else clause

The if/else is already there because there is so much trash in that relay hint field: markers/non-URL stuff or real urls without schema or with ?filters in the URL already, local relays, onion addresses, and private relays that require AUTH of the owner of the event, etc. They all need to be filtered out by the client. It's a huge if/else already. Adding a pubkey option (or frankly any other information to find the event) won't really change that much.

I agree that the conditionals are already kinda necessary, but that's not the important part; you are proposing sunsetting relay hints in favor of relying fully on the outbox model. The relay hint, as the happy path, is immediately available and has a good chance of having the event.

Doing outbox on the author's pubkey is a fallback when there is nothing to go for if the hint goes cold, but it's no replacement for it!

[vitorpamplona]

You don't follow relay hints?

Never did. It was never stable enough to justify basing the event search on it. From the event signer side, it's also clear to me that the choice of which relay to put into these hints is very complicated and a problem that, in the end, should not be solved by the singing client. If Amethyst added it, the majority of the posts would be filled with something like nostr.band, nos.lol, etc which, if hints are used as intended, significantly worsens Nostr's decentralization. Yes, Amethyst could open the author's Kind 3 or NIP-65 records and only use those relays as hints, but then it's the same as putting the author's key on the e-tag as proposed here.

And let's not forget that if the hint is an outbox relay, you might find the post, but not the reactions to it. If the relay hint is an inbox relay, you might find the replies but not the event itself. Because of that, to me, the relay URL hint never made any sense. It is just a hack to solve the indexing problem we have had since the beginning and never really tried to tackle head-on.

[vitorpamplona]

Either way, I am fine with this PR or with the use of pubkeys directly into the hint position. But here's my preference in order:

1. Never use URLs to reference anything inside of Nostr. Deprecate e-tags and change all references to something like kind:pubkey:event_id
2. Change the 3rd param to be a general hint: they can be a relay URL, a pubkey, or any other future structure that can help find the event.
3. Use the complete pubkey as the 5th parameter as recommended by comments here.
4. Use the partial pubkey as defined in the PR.
5. Give up and don't change anything. The current solution doesn't work. Relay hints must be at least 2 URLs, one for the outbox relay to find the event and another for the inbox relay to find all replies/reactions/zaps to that event.

Virtually anything is better than the current status of relay hints and I will be supportive on whatever folks here decide.

[mikedilger]

I'm in favor of this. I remember prior discussions we were just going to swap out the relay url for a pubkey and clients could figure out what it was that was in that slot. I don't care either way.

[v0l]

Ok so we mostly agree that the full pubkey can be added to the e tags. I will add this to snort soon.

It's a breaking change, but I would go for this.

I dont think its really an option to introduce breaking changes at this stage, i want to extend NIP-10 to make it easier for outbox model, if there is an alternative to NIP-10 then it should be proposed as a new NIP and should mark this one as deprecated.

Upgrades should and must keep happening for nostr to grow and improve, but that doesnt mean stomping on all the work of all the other devs who already implemented NIP-10. I think the correct trade off is for devs to continue investing time in development of their clients if they want to support new features or improvements, NIP-10 will never fully die because some clients will not implement a new version. It SHOULD take a very long time to replace them.

Take HTTP for example, HTTP/3 is the latest and greatest, but all webservers must still support HTTP/1, this is just how protocols develop.

[v0l]

Implemented in snort

https://njump.me/nevent1qqsxaxhk0r59fxn62wc2a4rv7cstnzu9wvue2sh6hhdk2exr2lafjagzyp3lucccm3v9s087z6qslpkap8schltk427zfgqgrn3g2menq5zw6qcyqqqqqqg0y9eej

[staab]

Added to Coracle (not released yet)

https://njump.me/nevent1qyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyz49z2052kxmf8ml5wqmt4ftvuctj0kgsc74rjyud3nqh9xgyhpesp9zpkk

[fiatjaf]

So you're not doing the stub thing? Sad.

[staab]

I'm including the full pubkey if that's what you mean. I think the partial pubkey just makes for more complexity in tag parsing for not much benefit.

[fiatjaf]

Can someone rewrite this to get rid of the stub thing then so we can merge it?