news VS neonmodem

I think so. I work with a group that was researching ways to improve the hacker news ranking algorithm. We concluded that there were "false positives" and "false negatives" -- stories often did or did not make the home page based more on timing and luck than the actual content of the story. Read more here: https://github.com/social-protocols/news

However, we concluded that the biggest problem is false negatives -- good stories that never made the home page -- because of submissions to /newest that simply don't get enough *attention*. There are too many stories and not enough eyeballs. As a result, there is not enough data to know if a story would do well if it were shown on the front page or not.

You can see this from the fact that there are many stories that are submitted multiple times, and 4 out of 5 submissions get only 1 or two no upvotes, and then the 5th makes the front page and gets hundreds. Sometimes it's due to timing factors -- the story has become relevant for some reason -- but often its just luck.

It's a short intro to raise awareness for the topic. Earlier, our research group "social protocols" published a new metric for Hacker News, but at that time, people didn't see the problem: https://github.com/social-protocols/news

Yesterday, we published our approach to improve the HN ranking algorithm: https://news.ycombinator.com/item?id=35183317

As a follow-up, we'd like to ask if the community is interested in official experiments with this or similar approaches. We'd suggest having a second, experimental front-page on HN, which applies the upoteRate metric to the HN formula, as described here: https://github.com/social-protocols/news#a-proposed-new-formula

To get a feeling, how stories with a high upvoteRate look like, we prepared a page, where all frontpage stories are sorted by upvoteRate: https://news.social-protocols.org/best-upvoterate.

What do you think?

Great to hear! We're still looking for strategies to cheaply retain more data. If you have any ideas, please jump in: https://github.com/social-protocols/news/issues/54

As a consequence, success on HN depends almost entirely on getting enough upvotes in the first hour or so to make the front page and get caught in this feedback loop. And getting these early upvotes is largely a matter of timing, luck, and moderator decisions. And so the best stories don't always make the front page, and the stories on the front page are not always the best.

Our proposed solution is to use upvoteRate instead of upvotes in the ranking formula. upvoteRate is an estimate of how much more or less likely users are to upvote a story compared to the average story, taking account how much attention the story as received, based on a history of the ranks and times at which it has been shown. You can read about how we calculate this metric in more detail here: https://github.com/social-protocols/news#readme

About 1.5 years ago, we published an article with this basic idea of counteracting the rank-upvotes feedback loop by using attention as negative feedback. We received very valuable input from the HN community (https://news.ycombinator.com/item?id=28391659). Quality News has been created based largely on this feedback.

Currently, Quality News shows the upvoteRate metric for live Hacker News data, as well as charts of the rank and upvote history of each story. We have not yet implemented an alternative ranking algorithm, because we don't have access to data on flags and moderator actions, which are a major component of the HN ranking score.

We'd love to see the Hacker News team experiment with the new formula, perhaps on an alternative front page. This will allow the community to evaluate whether the new ranking formula is an improvement over the current one.

We look forward discussing our approach with you!

Links:

Site: https://news.social-protocols.org/

Readme: https://github.com/social-protocols/news#readme

Previous Blog Post: https://felx.me/2021/08/29/improving-the-hacker-news-ranking...

Previous Discussion: https://news.ycombinator.com/item?id=28391659

They seem to have spent a ton of time on their website, why link to the github with no information? https://neonmodem.com/

Shameless plug: Neon Modem Overdrive [1] supports HN, for anyone looking for a Go single-binary multi-platform TUI.

[1] https://neonmodem.com

Thank you for the detailed description of your idea. Indeed, if you're willing to accept the shortcomings of a dedicated USENET infrastructure, then it is definitely something that could be done. In fact, I did consider NNTP for another project of mine (https://github.com/mrusme/neonmodem), which might eventually swallow up Superhighway84 altogether. If you're interested in actually giving it a try and implement a functional NNTP library for Go I'd be more than happy to make use of it! :-)

> Superhighway84 it was very expensive for me to actually run the software

I agree with you, in terms of efficiency IPFS is still miles away from where it should be. Hence my feedback on Quiet, as I do not perceive IPFS to radically imrpove within the next few months or even years. And as you correctly stated it looks like Quiet uses some workarounds to improve on the overall mediocre efficiency of IPFS, which however lead to shortcomings on other ends:

> Quiet itself notes a limit of 30-100 individuals with its application

However, this is not how P2P should be. I'd be truly curious to hear from someone at OpenSea, or Fleek, or any of the services that offer high volume IPFS hosting about their experience and gut feeling on its future. I personally gave up on hosting my website via IPFS myself -- which I did for a brief period of time -- mainly for these exact reasons.

> but for those of us who are bandwidth-constrained or otherwise limited in our access to those technologies

I believe that quite on the contrary, this might benefit these people the most. Imagine not having to do the roundtrip from your phone, to a server on the internet, back to your computer, just to have a synchronized state of your address book available.

Similarly, imagine writing with someone in your city -- let's say Melbourne, Australia -- without your messages first travelling to Utah, USA, and then back again. My gut feeling is that overall congestion on the internet could even be reduced, by allowing more applications to communicate directly within small meshes rather than travel all the way across the globe and back again. That is, as soon as there are more efficient ways to deal with the overhead that is currently breaking IPFS' neck.

A BBS-style command line client that supports various projects as backends and seamlessly integrates them into a streamlined user interface. (Website, Github).

Besides, have you seen this Lemmy client? Neon Modem Overdrive

Yes, including Neon Modem Overdrive, for a retro BBS experience.

Someone created a Usenet-like thing on IPFS. https://github.com/mrusme/superhighway84

It's kind of dead. IIRC the dev put that on the back burner in favor of a new BBS-like app. https://github.com/mrusme/neonmodem