Now entering: Unifier v3
Featuring NUPS, Private rooms, and a lot more.
After months of hard work and a slightly delayed release due to a v2 bug we had to fix, we'd like to introduce Unifier v3, our biggest release yet.
For this release, we've focused on bringing more customization, refining the cross-platform bridging experience, and making other minor updates to make your Unifier experience a lot better.
What's changed
We've brought a LOT of new features for this release of Unifier.
Universal platform support (NUPS)
Unifier already supports two external platforms: Revolt and Guilded. If you wanted to, you could install community-made plugins to extend the support even further. But this wouldn't really be the best thing to do.
Some of the code for Revolt and Guilded support are baked right into Unifier Bridge itself, and this code allows Unifier to natively support the two platforms. But for other platforms, we don't provide this native support, meaning you can't use Unifier Bridge to bridge a message to other platforms. Bridging without native support would lead to Bridge slowdowns (assuming the plugin uses something like Content Stylizing service to detect incoming messages then bridge them) and very limited integration with Bridge.
So with Bridge v3, we're solving this problem. Instead of providing the support code for platforms in Bridge, we're now relying on Plugins to bring their own native support code for the platforms of their choice. Developers will need to build a wrapper for the platform of their choice, so Unifier can get server IDs, send messages, etc. without having to play some kind of guessing game of figuring out which field is the server and which isn't.
All the functions Unifier Bridge will need to function are available in utils/platform_base.py. We'll release documentation on working with Unifier Bridge and NUPS soon!
Private Rooms and better Room customization
Private Rooms are currently experimental, and are thus disabled by default. We cannot guarantee privacy or stability, so please use this at your own risk.
We're introducing Private Rooms to Unifier!
Right now, all Rooms are public. This means that if you wanted to send something to a specific server, you'd need to connect to a room, but any server can connect to this room so they can listen in to whatever you wanted to say. We're solving this issue with the introduction of Private Rooms, where you can limit who can connect to the rooms.
To join a Private Room, your server's admins (if your server created the room) must first create an invite using u!create-invite. You can also specify the duration of the invite and the maximum usage allowed, so they auto-expire if they're too old or if enough servers have accepted the invite. Once a server accepts the invite, they can always bind to and unbind from the rooms anytime, unless you kick or ban them from the room by using u!roomkick or u!roomban. If a server is removed from the room this way, they'll need a new invite to regain access.
Disclaimer: Instance moderators will be able to connect to Private Rooms and view contents of reported messages sent in Private Rooms, regardless of if the server is in the allowlist or not. This is so that moderators can ensure safe and civil conversation.
If you do not feel comfortable with this, please host your own instance.
Multi-core on Bridge v3
We're finally bringing multi-core support to Bridge v3!
We had plans to introduce multi-core for Unifier v1.2, but we dropped this plan after testing showed little to no performance difference on a small-scale deployment. However, people have shown interest in hosting large-scale deployments of Unifier, and our current single-core approach would probably not work for these small-scale deployments.
Multi-core bridging for external platforms will be supported in the near future.
Under Attack mode
We've noticed that a lot of servers connected to our official Unifier instance have been affected by raids or raid threats. To help servers minimize the impact on other connected servers during a raid, we're introducing something called Under Attack mode.
When Under Attack mode is enabled, all messages sent in Unifier rooms from the server will not be sent to other connected servers. This is like an emergency stop button, but for Unifier - instead of running u!unbind for every connected channel, you can just run u!under-attack to lock those channels down. Once it's enabled, you'll see that whatever the raider sends in your server can't get bridged to other servers, like in this (actually realistic, iykyk) example I made in just 10 minutes on Canva:
Messages from other servers will still be sent to your server if Under Attack mode is enabled, so you don't stay out of the loop even during a raid. Once the threats are over, you can just disable Under Attack mode and get right back to chatting without having to asking others what happened while you were gone.
For the safety of all Unifier instances out there, we've brought this feature to all three currently supported series. This includes v1.2, v2, and v3.
Safety Alerts
Like we said earlier, raids and raid threats have become more common among our community. We wanted to create a way to alert servers more quickly and effectively, so if there was a raid, servers can take action even faster.
Safety Alerts have four levels: Emergency, Warning, Advisory, and All Clear (shortened to Clear in some cases). Emergency, Warning, and All Clear alerts will mention all users with the Ban Members permission
Safety Alerts are only available on Discord at the moment. We plan to add support for other platforms for Unifier v4.
Bootloader and integrated installer
To make managing and installing Unifier even easier, we've added a new "bootloader" and also replaced Unifier Installer with an integrated installer!
With the new bootloader, we've added the ability to choose the Python binary you use to run Unifier. So if you want to run Unifier in a Python virtualenv, you can configure the binary to use the virtualenv binary, and it'll automatically use that.
We've also added the option to restart Unifier! Previously, you'd need to shut the bot down, then start it back up using the console. Now, once you run the new restart command, Unifier will shut itself down, but the bootloader will start it back up.
To run Unifier v3, you will need to run ./run.sh on Linux/macOS/any system that uses bash or ./run.bat on Windows, instead of python3 unifier.py. This starts the bootloader instead of Unifier core, which lets you take advantage of all the changes we've mentioned.
Under-the-hood changes
We've of course added the usual performance improvements and bug fixes to Unifier, as we do with each release (unless we get lucky and there's no bugs to fix). For example, if you're using Guilded Support, you should see improved performance if you use the Unifier v3 + Guilded Support v1.1.0 combo for bridging to Guilded, thanks to Threaded Bridge and webhook caching.
We've also decided to follow Semantic Versioning for all releases after v2.0.6-patch5. Releases in the v1.2.x series will not follow this system.
Changes for Plugin developers
To accommodate for the addition of Private Rooms, we have heavily changed Unifier's data structure for Rooms.
Previously, Room data was separated in different keys. For example, connected servers would be listed under rooms, Room rules would be available under rules, and so on. We have decided to unify the key this data is stored in, and they are now all available in dict objects stored under rooms.
We will publish documentation on the new structure soon on the Wiki.
How to upgrade to v3
Due to a bug with Unifier v2.0.0 to v2.1.6, we had to delay the release of v3 to the stable channel. To release v3, please open config.json then set the branch value to "dev".
After upgrading, you can open config.toml then set the branch value back to "main".
You can upgrade to v3 using the built-in upgrader. Run u!upgrade, select v3.0.0 (or a newer version if there is one), then press Upgrade.
Unifier Micro v3 is in development and we expect to release this
Not ready yet?
Unifier v2 will continue to receive bug fixes and security patches until at least March 2025, and v1.2 until December 2024.
You can always stay on legacy versions as long as you want, but we strongly recommend you upgrade to a newer version before support ends, so you'll be able to make the upgrade process as smooth as possible.
And as always, thank you for your support 😊
Honestly, when I first started Unifier, I never knew it would grow to such a scale.
The Unifier project has gone from a simple bridge bot written in just two hours (yes, v0.1 was written in just two hours, that's how simple it was) to one of the most versatile and flexible bridge bots out there. This would not have been possible without the support from everyone, including developers, moderators, friends and best friends, and community members, in the Unifier community, and we at UnifierHQ would like to personally thank everyone that's been along on this journey. It's all thanks to your support we've been able to grow this much as a community.
So thank you for supporting us so far, and we hope you continue to enjoy what we make! 🚀
Last updated
