feat(kad): retrieve & display Kad notes (ratings/comments) with eMule parity (#434) - #462
Conversation
… parity (amule-project#434) aMule already publishes notes to Kad (STORENOTES) and answers other clients' note lookups, but nothing triggered a retrieval and the results were never surfaced. This wires the read side end to end and fixes two rating-encoding divergences from eMule 0.70b. Scope is the download side; shared-file parity is a planned follow-up. Core: - CKnownFile::RequestKadNoteSearch() fires an on-demand NOTES lookup, guarded to files in the shared list / download queue. A per-file running flag is set on start and cleared in ~CSearch; both edges, and each note arrival, call MarkECChanged() so the partfile is re-emitted in the next incremental EC update - this is how amulegui / amuleapi learn the lookup started, stream in results live, and see it finish (GET_UPDATE otherwise skips an unchanged partfile). When the lookup can't start, the specific reason (Kad down, a search already using this hash, file not shared/queued, ...) is logged at notice level so it is visible in release builds. - Kad search-result rating: decode raw 0-5 for Kad keyword hits instead of the ed2k server-packed (x&0xF)/3 formula. (Kad keyword results carry no rating tag in practice - ratings live in NOTES - but the decode is now correct if one is present. ed2k results are unchanged.) - ed2k client-write: send the rating packed (x51) to a peer client, raw to a server, matching eMule (remote clients previously decoded aMule's as 0). GUI (monolithic + amulegui): - "Get from Kad" button in the download comments dialog; retrieved notes merge into the existing comments list. A timer auto-refreshes while the lookup runs and stops when the daemon reports it finished (60s safety cap). "Show all comments" is enabled when Kad is connected (not only when source comments already exist), so the button is reachable for a file with no comments yet. - amulegui triggers over EC (EC_OP_SHARED_FILE_SEARCH_KAD_NOTES); notes ride the existing partfile-comments channel; the running flag is surfaced via a new EC_TAG_PARTFILE_KAD_COMMENT_SEARCHING so the remote dialog is stateful. REST (amuleapi): - POST /downloads/{hash}/comments triggers the lookup (202 Accepted). - kad_search_running exposed on the download object (list, detail, GET .../comments) and on the download_added/_updated SSE event, so clients can watch the start -> finish edge. - New comments_updated SSE event carries a download's full comment list (retrieved Kad notes + ed2k source comments) whenever it changes, so web clients get live comments without polling. - curl tests (04, 22) + REFERENCE.md / EVENTS.md updated.
8454396 to
0845b3a
Compare
|
Correct me if I'm wrong, but the first point of the request from #434 is not implemented:
We can now get Kad notes from the comments dialog once the file is being downloaded. But we cannot get those comments from Kad in the Search window, before the download is initiated. Am I missing something? I tested amulegui, and i don't find the option (I guess same applies to monolithic) |
|
@danim7 the shared-file / search-result parity you flagged is now wired up in #500. It turned out less trivial than "just call the same lookup", for a few reasons. The comments dialog and the Kad-note machinery were all bound to Net result in #500: "Show all comments" now works from search results and shared files across the monolithic GUI, amulegui, and the REST API, reusing the same dialog and a single comment cache. |
|
Thanks for your continuous work to improve aMule, got3nks! And very interesting technical explanation on why it was now wired in the first pass. |
2 participants
Implements #434 — retrieving and displaying Kad notes (per-file community ratings/comments) across the native GUI, the remote GUI, and the REST/SSE API, matching eMule 0.70b on the wire. Scope is the download side; shared-file parity is a planned follow-up.
aMule already publishes notes to Kad (STORENOTES) and answers other clients' note lookups, but nothing ever triggered a retrieval and the results were never surfaced. This wires the read side end to end and fixes two rating-encoding divergences from eMule.
Core
CKnownFile::RequestKadNoteSearch()firesPrepareLookup(NOTES), guarded to files in the shared list / download queue. A per-file running flag is set on start and cleared in~CSearch; both edges and each note arrival callMarkECChanged(), so amulegui/amuleapi learn the lookup started, stream results in live, and see it finish (a plainGET_UPDATEskips an unchanged partfile). When it can't start, the specific reason is logged at notice level (visible in release).(x&0xF)/3(which mangled them). ed2k unchanged.×51) to a peer client, raw to a server, matching eMule (remote clients previously read aMule's as 0).GUI (monolithic + amulegui)
EC_OP_SHARED_FILE_SEARCH_KAD_NOTES); notes ride the existing partfile-comments channel; a newEC_TAG_PARTFILE_KAD_COMMENT_SEARCHINGmakes the remote dialog stateful.REST (amuleapi)
POST /downloads/{hash}/commentstriggers the lookup (202); notes then appear onGET.kad_search_runningon the download object (list/detail/comments) and on thedownload_updatedSSE event.comments_updatedSSE event carries a download's full comment list (Kad notes + ed2k source comments) whenever it changes — live comments without polling.REFERENCE.md/EVENTS.mdupdated. (Also fixes a pre-existing test gap: the download-status allowlist now accepts the documentedstoppedvalue.)Testing
Automated: full amuleapi curl suite, clang-format v18, clang-tidy Tier-1 + Tier-2, app catalogs in sync, all six binaries. Live-validated on macOS against the live Kad network: real notes retrieved (rating 5) on two annotated files; the running-flag lifecycle
false → true → falsereaching amuleapi; SSEdownload_updated(flag edges) andcomments_updated(note payload) firing correctly; ed2k ratings render.