Nostr Web Client

defensive coding makes sense, but only so far. the user is still going to be very disappointed when their feed only works on a single client.

I think I can work around the DVM type, and it doesn't seem too difficult to support. I just question if there are any DVMs still running that users actually use.

For the WOT type, I cant think of any way to calculate a range. it could be a percentage of contacts that follow x key, but that's not really WOT. a true social graph has an arbitrary "score" that cant be capped to range without calculating the whole graph.

Either way my point is it doesn't make any sense to me. and if was implemented in 2-3 more clients it would be completely different. resulting in the users feed be different depending on the client which seems to contradict the goal of saving feeds as nostr events

hodlbod 5mo ago

> cant be capped to range without calculating the whole graph.

Yeah, this is fair. Coracle does this, but it is expensive. It did end up being less useful than I anticipated, I will think about removing it.

Kind 5300 DVMs are pretty useful and well-supported, so we should at least keep those, but I'll update the spec to narrow the dvm feed kind down to just 5300.

Differences in interpretation are pretty unavoidable, since loading feeds involves all kinds of heuristics anyhow. But I get what you're saying.

Reply to this note

Please Login to reply.

Discussion

hodlbod 5mo ago

Actually, looking at the spec again, subjectivity is built into the spec. Relay selections at least are going to vary by client, and stuff like `scope` will depend on the user executing the feed. So I don't know that we have much choice but to embrace the chaos.

hzrd149 5mo ago

I haven't see the "scope" type yet, still need to do a deep dive on it. just been thinking about what it would take and wanted to provide feedback, not sure if I will go through with building an implementation (maybe more pressing bugs to work on)