The bugs host and the reportbugs host would have to be considered separately. The bugs host is strictly for viewing text, just like the other onion hosts. The reportbugs host could be abused, but because the Debian project is non-transparent, makes no announcement, we can only guess what’s going on when they silently take a spontaneous action. Only after they express what action they took, and why, can we analyze whether it was sensible and how to move forward. Certainly it would be possible to deploy an onion host that accepts bug reports, and then put the traffic through an appropriate process, such as spamassassin scoring.

My assumption was that it might be due to the modern onslaught of bots creating reports, and if they were on the 🧅 it'd be more difficult to filter/block bot reports. But that may be a complete misunderstanding on my part of how that all works.

Could you please cite your source?

It’s wholly anecdote from decades of experience. AFAIK, there have been no peer reviewed scientific studies about this. But there should be. It would be interesting to research why it is that testers and bug report contributors are generally widely regarded as needy and demanding of favors. That’s not Debian specific. It’s FOSS wide.

The public perception is that devs are the sole contributors and testers are perceived as tasking the devs for their own personal gain. It impacts software quality because I often encounter bug reports that are very old when searching for prior reports of bugs I discover.

A project that effectively promotes good quality makes it very easy to submit bug reports anonymously, without imposing much of an obsticle, so that bug submissions are not disouraged and so everyone has good awareness of the bug history. Debian has been good on this, which is why Debian is a relatively high-quality project. But they are slipping amid the fight against spam and bots.

Where are they saying this?

IRC

Are they actually treating connections from Tor exit nodes or Torbrowser differently?

Yes. It is no longer possible to submit bugs over Tor, and bugs.debian.org quietly drops packets if the user’s user agent is not what they want.

Part of the problem arises from an unhealthy attitude that bug reporting is a service that benefits the tester.

Could you please cite your source? Is there a document or mailing list thread that states that this is the reason that those services do not have onion endpoints?

The Debian project is unapologetically telling testers to switch to clearnet and mainstream browsers when the bug services discriminate against users based on the network or browser version they use.

Where are they saying this? Are they actually treating connections from Tor exit nodes or Torbrowser differently?

If I have not overstated things

.. feels like maybe you have just a bit but that's just my own opinion :P

rant

I was actively tinkering with IPFS a few years back on Windows in a Ubuntu Linux VM running on Windows at the time . The IPFS software never felt stable and had some memory leak that would eventually lead to something crashing, it was kind of a PITA to lose all my pins and then have to reload them all the time. I'd pin content but it would take a while for other peers to find mine.. IPFS content seemed to be easier to access once it's been pinned and online for a while. The available search engines were pretty terrible too, the content I pinned to the network rarely ever showed up on any of them. To be fair people were still figuring out just how to actually crawl the IPFS network to index things into a search engine, maybe that's all better nowadays.

It also didn't help that Protocol Labs seemed to lean into cryptocurrencies with Filecoin (a parallel network to IPFS), for a while it seemed like the only thing IPFS and Filecoin were used for was NFT junk.

A lot of people new to IPFS seem to think IPFS = free file storage but that storage has to come from somewhere. So either you're self-hosting / pinning content to keep it online or relying on cloud storage services to host and pin the content into IPFS for you.. and they usually want to be paid to host your data. In the end it felt like a much more complicated way to pay a file host to serve data for you.

I ended up losing interest in the whole thing but maybe it's gotten better since then.

rant over

That aside, someone is/was attempting to package IPFS for the Debian unstable repos. It does sound like a bit of work since there are a ton of dependencies that also need to be packaged. If you're interested in helping them out you could look into it, see

https://www.debian.org/devel/wnpp/being_packaged

also

https://wiki.debian.org/DebianMentorsFaq

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp%3Bdist%3Dunstable https://www.debian.org/devel/wnpp/being_packaged

EDIT: After commenting remembered my IPFS node was in a Ubuntu Linux VM.. one of my experiments at the time was creating a bash script to generate IPFS and Bittorrent hashes to host online and test how uploading new content to both networks would pan out. It was a good learning experience for sure.

I don’t consider successors to necessarily obsolete their predecessor. People still use and appreciate vinyl records despite having several successors (including magnetic tape which eventually lost ground to vinyl in the end, amid digital successors).

"Protocol to succeed HTTP" "Ben around for ten years"

Given I've never seen IPFS in the wild (I've used it in my own environment), those statements are rather contradictory.

I don't see IPFS replacing HTTP, like ever.

Maybe that's why Debian devs don't care to push it.