nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn thoughts on removing the DVM and WOT type feeds in your NIP-FE? https://github.com/nostr-protocol/nips/pull/1554
I've been thinking about what it would take to make my own implementation of it in applesauce and those two types are the only thing that wouldn't translate well. DVM type because most DVMs don't speak the same language anymore and WOT type because applesauce has no concept of a WOT score between 0 and 1
Since there's no way to keep anyone from adding new verbs or creating malformed feeds, I think this is just another defensive coding thing. Clients that don't support a given verb should report the error to the user and maybe offer to "repair" the feed by removing the unrecognized stuff.
That said, DVMs are a pretty important out for requesting arbitrary data. They could be replaced by feed-type relays, but it's a neat architecture. Maybe we could split DVM feeds into different kinds? That's probably a good idea.
WOT feeds seem simple enough to implement, even if your wot calculation is naive it should be fine right? Whatever score range you use you can always scale to to 0-1.
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
> 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.
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.
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)
