Post

This feature seems to be a bit buggy. When I opened the page -> npmx.dev/package/svelte a few minutes ago it showed 20 likes. Then I logged in and liked it -> 21 likes. Then I checked with another browser (no login) -> 17 likes. Then I hard reload all pages in all browsers -> 14 likes. ๐Ÿค”

Thinking about this, I also wonder how spam resistant this feature is. E.g. a rogue PDS (or fleet of PDS) sending a few hundred/thousand fake accounts with like records/events out. Of course this is also possible and happening in e.g. GitHub, but maybe at a different scale (relative).

If done right this spam attack will be way below what rate limits enforce and probably also below other automated spam detection mechanisms, as it takes only a comparable very small amount of likes to majorly skew this metric.

Also small update to OG problem: There is a bit of a lag/cache issue. Liking and removing a like seems to work as advertised at least from the PDS point of view (records get created/removed). But the website "jumps" back and forth showing those likes, e.g. a fresh like gets reset and vice versa.

The red indicator if the like is present on the PDS works correctly, this "jitter" only affects the shown like count. I know it's alpha and just a day old etc :)

This may be a hard problem. Even GitHub has solved this only partially. Their like count always drift from what is shown in the header line of repository (likely heavily cached) compared to the like count shown in the right side bar (able to change when the like count with a like).

There's sooo much more that can be done with a social graph. I wrote an npm trust graph PoC once github.com/naugtur/trus... And here's some more on trust graphs and why Eigen Trust might be unnecessary bsky.app/profile/rekm...

github.comGitHub - naugtur/trust-graph: Trust graph implementation for npm package vulnerability and maintenance.Trust graph implementation for npm package vulnerability and maintenance. - naugtur/trust-graph
Erik@rekmarks.com

Wherein we disparage EigenTrust and point to a smaller yet more powerful alternative: rekmarks.com/posts/modeli...

That is exactly what Bluesky / atproto is. The kind of web of trust algorithm I describe in that blog post is made practically feasible by atproto.

You can't just naively use follows, because follows do not necessarily imply trust, but it would be straightforward to present a UI that's like "choose people to trust from your follows".

Any reason npm's native stars weren't used? ie. `npm star <pkg>` / `npm stars <user>` - this count is already available/shows up in Packuments under the top-level key "users" & is tied to npm accounts (so secondary inference/insights are trivial)

Yea... this was/is a thing. It was "removed" on the website at some point before I joined. That said, you can still find references in the website to it (since it was only visually removed) & the endpoints / CLI commands still exist & work.