browser ed2k link handlers

[Stoatwblr]

Chrome's latest update has borked the only remaining ed2k handler in the web store - it gets autodisabled and enabling it will result in a hard wedge of the entire browser when you try to use it

As chrome is the engine behind a number of browsers this is a problem that needs resolution :(

[Stoatwblr]

and to that end:

https://github.com/Stoatwblr/amule-chrome-extension

thanks Gemini

We looked at tweaking the existing extension but it was a mess of NPM with broken sources to produce what is very simple javascript. It was easier to start over.

[got3nks]

Thanks for jumping on this so fast, Stoat — and for publishing the replacement publicly. Had a look over the repo and the design seems sound: Manifest v3, activeTab + scripting only, content script for clickable single-link behaviour plus multi-select queuing, with watcher.sh as the browser↔aMule bridge.

One direction worth the team considering: since you're already on the team, an amule-org/amule-chrome-extension repo with you as the maintainer could give the extension an official home and let us reference it from the GitHub docs / website as the recommended Chromium-family handler. Not a decision any of us can make in isolation — flagging it for the wider group to weigh in on. Linking from our docs to a repo on your own account is also a perfectly valid shape — that's how we already reference ngosang's maintained Docker images, for example.

Two related notes regardless of the hosting question:

• The README scopes it to Linux (the watcher.sh + /usr/bin/ed2k bridge is POSIX-only). The extension itself should work on any Chromium-family browser, but Mac and Windows users would need an equivalent host-side bridge. Any plans / interest in porting?
• Edge / Brave / Vivaldi / Opera all share the Chromium engine, so the extension covers them on Linux today — worth a one-line note in the README if it isn't already.

[Stoatwblr]

I like the idea.

After a couple minutes it's already clear it needs a directory structure but it's a first pass - and as always "It works for me, your milage may vary"

Re: porting: definitely. The thing is the thread was already getting long (and laggy) so I didn't want to set Gemini off on doing that when new session would be better

[got3nks]

Just realised I overlooked the bigger picture in my previous comment: the proper long-term fix for "Chrome broke ed2k links" probably isn't a browser extension at all — it's amule-project#793 (ngosang's open feature request). That asks aMule itself to register ed2k:// and magnet: as OS-level handlers with a Preferences toggle, mirroring how AutostartManager was made cross-platform in amule-project#744. Once that's in, any Chromium browser just hands the click straight to aMule and the about:blank#blocked situation goes away by default — no extension required.

Your extension stays useful as a stopgap right now, and the multi-select bulk-queue UX would remain a genuine value-add even after amule-project#793 lands. But probably worth migrating amule-project#793 to this org so it's actually trackable (amule-project is frozen) and prioritising it.

Given your momentum on the Chrome side — challenge accepted on amule-project#793? :D Reference implementation pattern is already there in AutostartManager (amule-project#744), so the scaffolding to mirror is well-defined.

[Stoatwblr]

Fully agree, assuming Amule can actually do it. Chrome's latest version has gone to a lot of trouble to lock just about everything down. There were about 30 iterations of trying to add link handling using direct editing of CHrome's internals and Tampermonkey before I gave up and went down the extension route

[Stoatwblr]

One point: the extension is relatively fragile inasmuch as it relies on the download directory being ~/Downloads/ and that will break as soon as someone saves elsewhere. This is a 0.01alpha version at best, born out of frustration at the alternatives (crawling the html by hand and copy/pasting the links)

[got3nks]

Real concern, but I think the worry is narrower than it looks. What Chrome has locked down hard is programmatic / bulk navigation to custom protocols — JS-triggered window.location = "ed2k://...", rapid navigations without a user gesture — that's where about:blank#blocked reliably fires.

What still works in stock modern Chrome is a direct user click on an ed2k:// anchor when the OS has registered a handler. Chrome shows the "Open aMule?" prompt with the "Always allow [site] to open links of this type…" checkbox, and after a single accept the click-through works silently. That's exactly the path magnet: takes for BitTorrent clients today — Chrome doesn't fight you, it just gates the first occurrence.

So amule-project#793 covers the single-click case for any browser, no extra moving parts. Worth verifying empirically with a draft implementation against current Chrome, but the magnet-link precedent is strong evidence the OS-handler path remains viable.

[mrjimenez]

One direction worth the team considering: since you're already on the team, an amule-org/amule-chrome-extension repo with you as the maintainer could give the extension an official home and let us reference it from the GitHub docs / website as the recommended Chromium-family handler. Not a decision any of us can make in isolation — flagging it for the wider group to weigh in on. Linking from our docs to a repo on your own account is also a perfectly valid shape — that's how we already reference ngosang's maintained Docker images, for example.

I have nothing against it, in fact I am totally in favor. aMule has traditionally incorporated lots of utilities, see all the alc, alcc, cas, wxcas, etc..