We're removing the identifier

So long, 6-character codes.

First, there were no identifiers. Then, there were identifiers containing the first three initials of the origin server's name. And after that came the 6-character identifier we came to know and (maybe not) love today. But now, we're going back to the time where there were no identifiers.

But why?

We originally added identifiers to help server and Unifier moderators easily figure out exactly where the message came from. We created this identifier by hashing a message's author user ID and origin server ID, then taking the first three characters, then combining them together. For example, in my identifier a28270 in the image cover of the article:

• The a28 is the first three characters of the hash of my user ID, while

• The 270 is the first three characters of the hash of the server ID of the server where I sent the "message" in. It's not really a message, since I just made it in a graphic design tool.

Using these identifiers, Unifier could compare these characters to hashes of its servers and their members, so it could show where the message came from. But this came with some issues:

• If a server ID's hash's first three characters are the same as another server ID's, then this can result in loss of accuracy.

• Same goes for the user ID.

• Identifiers added extra bulk to the username, restricting how long it can be.

We added a solution for the first issue by scanning for server members with the matching user ID hash. If there were no matches, it would try another server with the matching hash. But due to how the Discord library we use works, if a member left the server, we wouldn't be able to identify them.

And for the third issue, although this was merely cosmetic, it stirred up some complaints from our users. In fact, a lot of people thought it was a bug, especially since we went from "via ABC" straight to "1a2b3c". Although they were understanding of why we added it and didn't complain any further, we kept this feedback, because even cosmetic issues can have a negative impact on the user experience, which isn't something we want.

And with Bridge v2 now up and running, identifiers have become redundant, especially due to message cache backups.

A new way of identification

With Bridge v2, we introduced a new OOP-style method of storing message details (we don't store the contents, so don't worry). Everything Unifier needs to know about a message for it to function, including the message author ID, channel ID, and server ID, are all under one UnifierMessage object corresponding to the message now, greatly simplifying the work we have to do to maintain and upgrade the bridge. And with message cache backups, we are able to preserve the message origin details even after restarting without the use of identifiers.

So now, to identify the origin of the message, we look for the UnifierMessage object with the corresponding message ID, then return the details. This way we don't have to deal with mixing and matching hashes, nor do we need to add 9 extra characters at the end of a username. This is helpful for bridging to Guilded, as there's a 25 character limit for messages on there, which contributes to one of many reasons why working with Discord and Revolt is such a breeze compared to Guilded (and not to mention the 1MPS speed while Discord and Revolt can take advantage of the full 12.5MPS speed).

Addressing the shorter ID timeframe

With the identification possibility now being ephemeral, rather than permanent, this would mean that moderators would have a much shorter timeframe to identify the source of the message.

However, Unifier's memory cache is virtually unlimited, so it can store as many messages in its internal cache as the memory allows. On the other hand, backup cache is currently limited to 10,000 messages only, but at the current rate of Unifier usage, moderators will have more than a reasonable timeframe to identify the source of the message using the new ID system before the message is wiped from cache by a reboot. As Unifier's userbase and activity grows, we will scale accordingly and increase the backup cache limit, so more messages are backed up between bot reboots.