More efficient or performant way of serializing permission nodes?
As a personal project, I'm designing a chat platform similar to Discord. Discord's permission system uses a simple bitfield, which is great as it's a small size and simply expressed, but terrible as I'm limited to
n-1 possible permission values where n is the bit size of the field (I believe Discord internally uses a 64-bit integer, so 63 total possible permissions). I consider this bad for futureproofing and I would like to make sure I'm not painted into a corner and can have any arbitrary number of permission nodes/values. Anyone have any great ideas for alternative ways to format arbitrary permissions in a JSON-serializable-friendly way?
Right now my only genius idea is still using an enum, but making it essentially an array instead of a bitfield. This would greatly increase the size of the generated JSON most likely, but now I have a massively increased number of permission values. even using just a humble uint, I'd now have billions, which is more than enough for me.
IE:
strings are probably slower, and obviously take up precious bandwidth at the scale of potentially hundreds or thousands of permissions arrays, so I may opt for the less-readable but identical int value format...but I'd like to know if anyone with more experience or knowledge has a brighter idea. Maybe something silly like multiple bitfields across multiple field names?10 Replies
Another option is an array of int bitfields. So a bitfield, but not limited to 64 bits
what would that look like as JSON? How would end-users (or people interfacing with the API) be able to differentiate between them?
I did think about making it a map of bitfields, to group permissions by...area of concern?
So instead of
"permissions": 64-bit-int, you have "permissions": [32-bit-int, 32-bit-int, 32-bit-int, ...]
Just as unreadable as a normal bitfield, but more compact than your other suggestionsyeah, that's what I assumed you meant, but I don't know how I'd communicate which of those bitfields represents which set of permissions
Don't treat it as a number of "sets of bitfields". Treat it as a single bitfield, split into 32-bit ints for transport
So bit 64 means X, bit 65 means Y, bit 1204 means Z
i see, that makes more sense
so a simple bitfield, split into multiple smaller bitfields that consumers would need to combine
(the array of strings is a lot more readable, I'll grant!)
yeah, I'm just trying to find a happy medium between "readable" and "compact". as long as it's documented, I guess it doesn't matter - it's not like bitfields are human-readable anyways
You could have a bitfield that says which permission groups are present, then an array of bitfields for each permission group in a known order lol
So, starting with the bit is fine tbh, it covers you for some amount of time, potentially years, migration to a new permission system later should be more on the trivial side. Not nothing, but doable.