An update to Honeypot 3.0 plans

honeypot-3.0-update.md

A little while ago I announced plans for Honeypot 3.0. A couple weeks after, I announced how Behavior Providers worked.

After a ton of thinking and work, I am updating my plans for Honeypot 3.0. There are a few reasons for this:

1. Ultimately, it boils down to time. I don't have much of it at the moment, and while I'd love to see these features come to life, I don't think I can successfully implement the features I wanted to with my current knowledge level and available time.
2. It was too ambitious. I am a single developer, not that skilled in Java, trying to implement features that require some crazy things like dynamic class loaders, for example. That's something I know I can't do currently with my skill level, let alone make it secure. Dynamically loading untrusted, unreviewed code? No way.
3. It didn't make sense. Some of the features I announced just didn't make sense. Like, the Pub/Sub model, for example. Why would I need that, since the plugin is already functioning like that? That was just me using buzzwords. Spigot already uses a "Pub/Sub" model of sorts with events. Honeypot, for example, contains nine custom actions, and each time an action is triggered, the plugin just tells Bukkit to call the event (Publish) and any @EventListeners listening to that event (subscribers) run. There was no need to say it wasn't already doing this.

Don't get me wrong, Honeypot 3.0 will still be an amazing update! It'll just take me time to get the features I want added, and I decided that some things needed to be removed entirely

Scrapped ideas

First of all, Asynchronous DB Calls are not happening yet. Yeah...that sucks. Async DB calls are pretty much a requirement for preventing locking code, but I can't figure out how to do it successfully. I'm going to do a bunch of research on this topic, but for now it's on pause. It'll happen soon, though!!

Second, I'm scratching the idea of "plugins" altogether. I don't trust myself to create a plugin system that is capable of being secure and protecting users, that's Spigot's job. My ideology has always been security first, and that'll take priority over any "cool" features. Any future integrations will be programmed directly into the plugin. As well, I'm not quite sure how that would work, because the custom behavior would need to be loaded into Honeypot, and then somehow other plugins would need to know about it. That doesn't really jive. So, the idea was scrapped.

Behavior Providers

Behavior Providers are getting some added functionality prior to release. I noticed while I was converting the Notify action that behavior providers were severely lacking with what they provide. Specifically, they only gave access to the player when an action was triggered, and not the block that triggered it. Therefore, behavior providers now allow a block to be processed! Here's how it works. I'll demo with the Notify Honeypot type

package org.reprogle.honeypot.providers.included;

import org.bukkit.Bukkit;
import org.bukkit.ChatColor;
import org.bukkit.block.Block;
import org.bukkit.entity.Player;
import org.reprogle.honeypot.Honeypot;
import org.reprogle.honeypot.commands.CommandFeedback;
import org.reprogle.honeypot.providers.Behavior;
import org.reprogle.honeypot.providers.BehaviorProvider;
import org.reprogle.honeypot.providers.BehaviorType;

import javax.annotation.Nullable;

@Behavior(type = BehaviorType.NOTIFY, name = "notify")
public class Notify extends BehaviorProvider {

	@Override
	public boolean process(Player p, @Nullable Block block) {

		if (block == null) return false;

		String chatPrefix = CommandFeedback.getChatPrefix();

		for (Player player : Bukkit.getOnlinePlayers()) {
			if (player.hasPermission("honeypot.notify") || player.hasPermission("honeypot.*")
					|| player.isOp()) {
				player.sendMessage(chatPrefix + " " + ChatColor.RED + p.getName()
						+ " was caught breaking a Honeypot block at x=" + block.getX() + ", y="
						+ block.getY()
						+ ", z=" + block.getZ() + " in world " + block.getWorld().getName());
			}
		}

		Honeypot.plugin.getServer().getConsoleSender().sendMessage(chatPrefix + " " + ChatColor.RED
				+ p.getName() + " was caught breaking a Honeypot block");

		return true;
	}
}

First, you'll notice a new @Nullable parameter, block. This is for developers who may not need that parameter. This also means that you should do null safety checks prior to processing your action. This should never be null except for internally registered actions, but nonetheless you should always check. After you've done your type safety checks, you can use it as normal! Not much to it, but adding the block in question makes it that much more powerful.

---

Aaaand that's all! Not much to it, but I wanted to be transparent with the people who use my plugin. All built-in functions have been converted to behavior providers, and the re-write is underway. I'm actually going to pause on that and start working on a Kotlin rewrite, but I'm not quite sure how I'll do that. IntelliJ can auto-convert files to Kotlin, so we'll see how that works ;)

Can't wait for 1.20! Until then :)

-Nate (TerrorByte)