Oddbean new post about | logout
▲ ▼
mister_monster | 3 months ago (raw) | root | parent | reply | flag 
 So if I'm following, I should prioritize kind 10002 events, then content of kind 3, then p tags in kind 3. I won't be doing any complex scoring I don't think.

So on the hypothetical side of this, I think, if the relays in p tags were lists, and they were only used to fetch a user's kind 0 event and it contained a list of relays that were updated every time a client added or removed a relay, that should prevent rot while keeping all the extra complexity out of this, no?
▲ ▼
Little Mikey D | 3 months ago (raw) | root | parent | reply | flag +1 
 I'm not sure I follow
▲ ▼
mister_monster | 3 months ago (raw) | root | parent | reply | flag 
 So, suppose the p tags on *my* kind 3 could each have multiple relays like you said you tried for that I quite like. And suppose your kind 0 event had a list of relays that was updated by your client every time you added or removed a relay, just like if you changed your avatar or something. Could be kind 10002 as well, but I'm trying to simplify the protocol in my mind, rolling the contents of kind 10002 onto kind 0. If the relays in your p tag in my kind 3 were updated by my client when they don't match your kind 0 (or 10002), then we don't really have a rot problem or a bootstrapping problem, right? The likelihood that your followers' p tag for you in their kind 3 are out of date is very low, the likelihood that nobody can find your list of relays from just a couple of your followers' kind 3 events is extremely low, and if clients MUST update their kind 3 p tags from your 10002 or 0 in my hypothetical idea, then it looks like those two problems are practically solved, though I know not perfectly solved since there is a small chance that none of your followers have a single relay for you that you still broadcast to and therefore that will have an up to date kind 0 or 10002 event for you. To me this seems much more robust and less dirty than the brute force hack you just told me about.
▲ ▼
Little Mikey D | 3 months ago (raw) | root | parent | reply | flag +2 
 Well you are just copying from my kind 0 when my kind 0 updates. And that is a lot of copying and republishing overhead. And yet you still have to find my kind 0 to do that, which was the original problem.  So I don't think you've solved anything.  Unless you are saying that you would look into a bunch of other people's kind 3 lists to see if any of them know where I have moved to.  So what you are doing is creating a bunch of redundancy of my kind 0 information distributed all around the place.  We could achieve the same thing more simply by just having relays copy/push people's kind 0 (or 10002) information to all the other relays they know about once they first discover a new version... a kind of relay-to-relay propagation... or even have clients blastr the thing in the same way.
▲ ▼
mister_monster | 3 months ago (raw) | root | parent | reply | flag 
 >Well you are just copying from my kind 0 when my kind 0 updates. And that is a lot of copying and republishing overhead.

Yes, but its not really more overhead than the original NIP-02 spec had (besides p tag relays being more than one), if you don't want the relays in kind 3 p tags to rot you have to update them frequently, it solves the bootstrapping as well.

> And yet you still have to find my kind 0 to do that, which was the original problem.

Yes, but it's much less likely I will fail to be able to now that I know that your p tag in my kind 3 will very likely have at least one valid relay.

> Unless you are saying that you would look into a bunch of other people's kind 3 lists to see if any of them know where I have moved to.  

Yes, if you can't find a valid relay that has my kind 0 or 10002 from my p tag in your kind 3, then try from one of my followers' kind 3, move on to the next one and check relays you didn't see before and so on, that is of course in the event that your list of my relays has rotted into oblivion, it's a last resort. If you *never* find a valid relay that has my kind 0 or 10002 then the network is almost certainly completely split somehow.

> So what you are doing is creating a bunch of redundancy of my kind 0 information distributed all around the place.  We could achieve the same thing more simply by just having relays copy/push people's kind 0 (or 10002) information to all the other relays they know about once they first discover a new version... a kind of relay-to-relay propagation... or even have clients blastr the thing in the same way.

But there's no method to that, you just hope the network is not fragmented, that approach is less robust, and youre burdening relays that have nothing to do with the people involved, hoping they won't just drop these events. It seems to me that this is way more duplication overhead because even relays that don't care otherwise still have to be trusted to participate in storing and relaying kind 10002 events for (I don't know how much) less robustness. This way, you only publish your kind 0 or 10002 to your relays, no blastring required. Just changing the kind 3 p tags to have multiple relays would make this work, everything else is just client behavior, if you use kind 10002 instead of changing kind 0 to have that information inside, although that seems maybe like a slightly better idea.

Anyway I just like chewing on ideas, it seems like a good idea to me and seems more robust and "correct". I don't expect it to be implemented and I'm not picking fights in the nostr world shouting about how everything should be done my way, but it's fun to think about different ways to solve different problems and ponder on how a protocol could work differently and how those differences might make things better and/or worse on different ways. Maybe you're right, maybe blasting your 10002 is practically always sufficient, isn't that much of a bother to relays who already are tasked with relaying messages from every direction, maybe it's highly improbable that the network will fragment enough to make it a concern that needs to be addressed more elegantly, maybe the bootstrapping issue isn't really much of a centralizing force at all.