Currently when using tlock-js in browser, it fails at runtime with

ReferenceError: Buffer is not defined

It would be great to use something that work for both browser and node env

the previous commit that added the binary encoding said it was necessary for correct enc/dec, but none of the tests failed when removed and I suspect it was added before we sorted the chunking issues

I think there may be some issues running this in pure node due to its use of fetch. There's text in the readme to that effect, but it would be good to actually test it and remedy any issues that arise.

• export Buffer class so that downstream users don't have to pull in a polyfill
• rejigged parcel config so that the built module doesn't use require so that users who don't use a bundler can use it in-browser
• added some advisory text for users of vite.js

• pulled some pieces out of noble
• wrote an implementation of hashToField using https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve-16#section-5.2
• created a patched hashToCurve

due to using a counter size of 32bits in the stream cipher, only up to 256TB may be encrypted before a nonce reuse would occur. This solution checks if the counter has reached the limit on every increment. This may add overhead or may be free on some engines and I haven't benchmarked it

In my use case, the encryptor do not want the decryptor to know when decryption is possible. This is because in my use case, the timing needs to remains secret.

To avoid the decryptor to check the decryption at every epoch, one idea is that encryptor will provide the decryptor the minutes (and seconds) to check but will not tell the day/hour.

See conversation slack :

wighawag:
hey got a question on tlock. Is the decryption time public ?
if it is public by default, is there a way to ensure that only the one encrypting know when decryption will be possible ? (edited) 

Will Scott
you could not include the decryption time with the encrypted blob, but it would be up to recipients to trial-decrypt every epoch

wighawag
Nice, is the tlock-js library supporting that option easily ?

The idea is that for my use case, decryptor will be able  to try every hour

Will Scott
would you know that you are only encrypting at an hour granularity, or could encryption still be at any epoch?

Patrick McClurg (Protocol Labs)
right now tlock-js doesn’t enable this super easily - during encryption, the roundNumber is encoded into the AGE args and then used for retrieving the beacon during decryption time.It wouldn’t be super hard to make a fork though - you could e.g. put a round number of -1 and remove the bounds check, and change decryption to check every hour when the round number is negative

ofc it will not be compatible with the other tlock libs, but it sounds like that’s not a big deal for your use case!

wighawag:
@Will Scott, yes, basically, one idea is that the encryptor will be telling the minute (and seconds) the decryption will be ready but not the hour

@Patrick McClurg (Protocol Labs) I ll create an issue in tlock-js as I think it is a valid use case for it

Will Scott
makes sense. having a coarser quantization seems useful in not making decryptors do way too much work

If tlock-js could left out the decrypting time, application could provide their own mechanism

Hi,

Reading the doc it says about timeForRound:

timeForRound

Given a NetworkInfo object, it calculates the approximate time the given round will be emitted at (approximate because the network must work together to create the randomness).

It would be great if it gave also worst case scenario in both direction or even better a probability distribution on a range of time, so applications can predict accordingly.

I also could not find what to expect on the mainnet, Is it a one minute kind of difference we can expect or a lot more ? Thanks