If the other side was using a text key, this would make things easier for us. The key is actually a hex number shared as text, but they parse it into its actual hexadecimal value before running the hash function.

This could be another option for a contribution to the system app. The function that generates the hash must decode the Base64 string in this case. But as it is, the function would take the encoded string as the key.

Yes, that's what I was considering too. Just thinking that the developer experience would be a bit different from classic arrays, as we cannot allocate a specific amount of memory, but have to add one element at a time.

It could be on overload. Although AL is generally not too good in manipulating byte arrays. Would it even be a good idea to to have a function accepting a list of bytes, considering that AL arrays can only have fixed size?

I can't see any way around it, but maybe someone has an idea how to generate a hash in AL with a byte sequence as a key instead of a text string?

And the blank message in this lig entry does not help either. It would be worth adding something meaningful.

Search in the repository points to Master Data Management in ALAppExtensions, just a feature usage log.

No other method I'm aware of. And this way, it looks good. It's a clear intention: "I'm only going to use these fields". And then the runtime will adjust the list anyway, if any other fields must be included.

InStream/OutStream are essentially memory buffers with read/write pointers. In this snippet, CreateInStream instantiates the stream, but does not read the data, whilst ReadAs actually fills the buffer. I don't see as a hack, but it surely can be confusing.