Skip to content

Conversation

@stenjansarv
Copy link

A plugin designed for the "Reval" OSRS clan to track player progress and share achievements with the community.

Features:

  • Automatically syncs player data including Combat Achievements, Collection Log, Achievement Diaries, and Quest completions
  • Sends real-time notifications to the clan Discord for exciting moments: valuable loot drops, pets, level ups, quest completions, boss kills, clue completions, and more
  • Custom Collection Log sync button for on-demand data capture
  • Clan member validation to ensure only "Reval" clan members can send notifications
  • Configurable toggles for each notification type
  • This plugin helps our clan celebrate achievements together and track community progress. Perfect for clan leaderboards, progress tracking, and sharing moments!

@runelite-github-app
Copy link

runelite-github-app bot commented Nov 2, 2025

@raiyni
Copy link
Member

raiyni commented Nov 2, 2025

Can you just use Dink plugin for your webhook notifiers? Considering you yoinked the code from it anyway.

@runelite-github-app
Copy link

runelite-github-app bot commented Nov 2, 2025

This plugin requires a review from a Plugin Hub maintainer. The reviewer will request any additional changes if needed.


Internal use only: Reviewer details Maintainer details

@stenjansarv
Copy link
Author

stenjansarv commented Nov 2, 2025

Can you just use Dink plugin for your webhook notifiers? Considering you yoinked the code from it anyway.

Yes, heavily took "inspiration" from Dink for many of the notifiers. Unfortunately for my case, the Dink plugin allows the user to modify certain parameters for the notifications, meaning that it's quite out of my control what the user decides to send. And who decides to send. I could filter this on my BE side, but I'd rather not create the situation where it's possible for anyone to potentially bombard my webhook endpoint, or for people to mistakenly send events that shouldn't be sent, simply because they changed the settings.

Additionally, there are some notifiers that are quite specific, and I cannot imagine any general use webhook plugin wanting to implement them. I already implemented a couple more specific ones, but I've got more ideas.

There's also the element of ideally not wanting our clan members to have to setup multiple plugins, when everything could theoretically be done with just one.

I realize this is a rather specific use-case for just our clan.

@riktenx
Copy link
Member

riktenx commented Nov 10, 2025

If you are not willing or otherwise unable to use/contribute to Dink then we can review this as-is.

Be advised that your plugin submission is large and will take a while to review.

@pajlada
Copy link
Contributor

pajlada commented Nov 10, 2025

If you've taken heavy inspiration from Dink, please attribute it in accordance to its license.

Additionally, Dink is looking to potentially allow its notifiers to be re-used through the use of the PluginMessage API (see pajlads/DinkPlugin#826). Would this functionality be useful to you?

@stenjansarv
Copy link
Author

@riktenx Thanks for the clarification! To clarify: I'm happy to contribute improvements back to Dink where appropriate (like bug fixes or general enhancements), but we can't adopt Dink as a dependency or merge our codebase into it. Our plugin is purpose-built for our clan's specific tracking needs with tight backend integration. Ideally I want total control over the events and how they function. Also who they are sent to (clan member validations), and when (dynamic filters from our API). Please proceed with reviewing as-is, if possible. I understand that the review will take time given the plugin's size. It is totally okay :) Did a small update as well with some housekeeping, so should be set for reviewing now 🚀

@pajlada Thanks for the suggestion! That API would definitely be useful, because even though I took inspiration from Dink, my notifiers are still mostly barebones compared to what Dink offers - more fleshed out, covers more edge-cases, etc. So if there was a way in the future to utilize Dink's logic via an API for the main events, then I'd definitely be interested. Also attributed Dink on code, added the license to the repo, and also into the README!

@iProdigy
Copy link
Member

Also attributed Dink on code, added the license to the repo, and also into the README!

You've also adapted code from https://github.com/SMaloney2017/Temple-OSRS-Plugin and should adhere to their license as well regarding attribution/notices

Ideally I want total control over the events and how they function.

This is fine and you're welcome to have your own plugin. AreaEntryNotifier (constantly transmitting location + inventory) and EmoteNotifier (notify upon emoting) are unlikely to make it into Dink

Also who they are sent to (clan member validations)

This isn't unique to your plugin; Dink can also be directed at your server url

and when (dynamic filters from our API)

This can also be achieved with Dink via Dynamic Config URL within the advanced config section

https://github.com/revalOSRS/reval-cc-plugin/blob/d69dec9fffce747bbd324e6c82ffcdc115832d29/src/main/java/com/revalclan/util/WebhookService.java#L88

You should just use enqueue from okhttp to avoid creating a new Thread for every async data push

@iProdigy iProdigy added the waiting for author waiting for the pr author to make changes or respond to questions label Nov 14, 2025
@runelite-github-app runelite-github-app bot removed the waiting for author waiting for the pr author to make changes or respond to questions label Nov 14, 2025
@stenjansarv
Copy link
Author

@iProdigy Thanks for the feedback. I've added the TempleOSRS license just like I did with Dink. Also utilized the enqueue from okhttp. Thanks for the suggestion 💯

AreaEntryNotifier (constantly transmitting location + inventory) and EmoteNotifier (notify upon emoting) are unlikely to make it into Dink

Indeed, AreaEntryNotifier and EmoteNotifier are particularly niche and they will also be turned on mostly for events only on our end. I definitely wouldn't expect any other notification plugin to implement these, yep.

This isn't unique to your plugin; Dink can also be directed at your server url

When you say the Clan validation can be directed at my server URL, you mean that I can filter out the requests in my server to only let specific people's requests pass from there? If I understood you correctly, then this is what we have been doing so far, but I want to avoid a scenario, where someone accidentally or maliciously starts spamming the server with these event webhooks. I'm sure it can be done even with my small clan member validation, but at least it's an additional hurdle.

This can also be achieved with Dink via Dynamic Config URL within the advanced config section

I was actually unaware of this. Definitely a welcome feature, and will keep this in mind, should I need it with Dink in the future again.

@iProdigy
Copy link
Member

you mean that I can filter out the requests in my server to only let specific people's requests pass from there

Yes, Dink for example includes clanName and dinkAccountHash in the notification metadata - you can create an allowlist on these properties to drop notifications from malicious spammers (I noticed you only send the player's account hash on login for your plugin instead of attached to every notification)

authors=Lightroom

for the file in this repo, you want this to be a comma-separated list of github usernames that can edit the plugin.

also you'll need a warning= line similar to

warning=This plugin sends player data, including usernames, screenshots, and IP address to a third-party server not controlled or verified by the RuneLite Developers, for tile verification.

@iProdigy iProdigy added the waiting for author waiting for the pr author to make changes or respond to questions label Nov 15, 2025
Plugin update consists of sending accountHash on webhook notifications & adding additional external filters to detailedKill notifier
@runelite-github-app runelite-github-app bot removed waiting for author waiting for the pr author to make changes or respond to questions non-author plugin change labels Nov 15, 2025
@stenjansarv
Copy link
Author

@iProdigy You've brought up some useful suggestions/comments once again. Added a similar warning line and changed the author name there to my GH username as well. Thought it was just more decorative, since it seems optional.

I noticed you only send the player's account hash on login for your plugin instead of attached to every notification

That's actually a fair catch. Might be useful to send that with every notification. Added that functionality as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants